| Message ID | CAMuHMdWTiurUSacddYXgW69=QwOrZDV3Zt2DezJauPy8j-GMHw@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Arnd, > > On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> Based on what I found so far, gcc-4 can be pretty much ruled out from >> being the minimum version based on the number of failures I got. >> It's much better than 3.4 but much worse than 4.1 or 4.2 which seem >> fixable on MIPS and x86 at least, and may or may not work depending >> on configuration. So the best two possible (but conflicting) answers I >> have are >> >> a) There are known users on gcc-4.1, and we never break things that >> work for users, so gcc-4.1 (or possibly 4.0 if a user shows up) would >> be the minimum version. >> b) gcc-4.1 and 4.2 have too many problems, so users are better off >> when we tell them to upgrade to something newer, and a minimum >> version of gcc-4.3 has fewer surprises. We should remove all >> workarounds for pre-gcc-4.3 compilers and just force a build error >> message. > > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would not > do it.I guess most people using old compilers know what they're doing. What I'm trying to find out first is whether "people regularly using 10+ year old compilers for the latest kernels" is a strict subset of "people in Geert's household". Given that none of the three architectures I looked at (arm, mips, x86) has successfully built any defconfig for a few years, it's quite possible that it's just you ;-) The other architectures that were around 10 years ago (so they might have someone who still has old toolchain binaries) and that still exist today are alpha, cris, frv, ia64, m32r, parisc, powerpc, s390, sh, sparc and xtensa. The first six are similar to m68k in that the hardware is mostly obsolete and the ports are kept around to support those old systems that might also use ancient toolchains, or new toolchains may be unmaintained or buggy, which could be a reason to keep 4.1 supported or at least try to find out if 4.1 (or even any other version) still works at all. > My main motivation for keep on using gcc-4.1 is that it gives many warnings > that were disabled in later gcc versions. I do look at all new warnings, and > send patches when they are real bugs, or are trivial to silence. What kind of warnings do you see that disappeared with later versions? Do you know what caused them to disappear in later versions (different optimization decisions, warning getting disabled by default but still available for turning on manually, ...)? Do you know if the disabled warnings are still there in gcc-4.3 (I can try it out if you give me examples)? > Lately the usefulness has been decreasing, as you've been too aggressively > killing compiler warnings with recent gcc versions (which became better) ;-) > Hence if I detected a new warning with a point or an rc release, it usually > means the code was never in nex (ugh)t, or the maintainer ignored your patch. > > I could easily switch to v4.9 from kernel.org crosstool, though, but then I > would loose all those warnings. If gcc-4.3 produces similarly useful warnings, we could think about integrating gcc-4.3 into kernelci.org build reports as an option, and fix up all the existing warnings we get with that. I wouldn't want to do that with gcc-4.1 though as the older versions have relatively random behavior. One particular feature I'd like to use that requires a newer compiler is being able to control warnings per function liker glibc does, using e.g. '_Pragma("GCC diagnostic disable \"-Woverride-init\"")'. Once we have that, we could turn on a couple of additional warnings that are generally useful but also warn about code that intentionally does something that would trigger the warning. > BTW, below is the diff I use to avoid an ICE. > After that, it builds and (test)boots fine on ARAnyM ;-) I guess this means that even your builds require extra patches and you can't strictly build a defconfig and expect that to work ;-) Arnd
Hi Arnd, On Mon, Apr 24, 2017 at 11:44 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven > <geert@linux-m68k.org> wrote: >> On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: >>> Based on what I found so far, gcc-4 can be pretty much ruled out from >>> being the minimum version based on the number of failures I got. >>> It's much better than 3.4 but much worse than 4.1 or 4.2 which seem >>> fixable on MIPS and x86 at least, and may or may not work depending >>> on configuration. So the best two possible (but conflicting) answers I >>> have are >>> >>> a) There are known users on gcc-4.1, and we never break things that >>> work for users, so gcc-4.1 (or possibly 4.0 if a user shows up) would >>> be the minimum version. >>> b) gcc-4.1 and 4.2 have too many problems, so users are better off >>> when we tell them to upgrade to something newer, and a minimum >>> version of gcc-4.3 has fewer surprises. We should remove all >>> workarounds for pre-gcc-4.3 compilers and just force a build error >>> message. >> >> If there's no real good reason (brokenness) to deprecate gcc-4.1, I would not >> do it.I guess most people using old compilers know what they're doing. > > What I'm trying to find out first is whether "people regularly using 10+ > year old compilers for the latest kernels" is a strict subset of "people in > Geert's household". Fair enough. >> My main motivation for keep on using gcc-4.1 is that it gives many warnings >> that were disabled in later gcc versions. I do look at all new warnings, and >> send patches when they are real bugs, or are trivial to silence. > > What kind of warnings do you see that disappeared with later versions? > Do you know what caused them to disappear in later versions (different > optimization decisions, warning getting disabled by default but still available > for turning on manually, ...)? Do you know if the disabled warnings are > still there in gcc-4.3 (I can try it out if you give me examples)? Mostly the "may be used uninitialized" warnings. I believe they were disabled in gcc-4.3 (4.2?) and later due to too many false positives, which is not an issue for me, as I look at differences. They were re-enabled lately (with much less false-positives), that's why you see them, and fix them. For example, do you see the warning fixed by commit 1b8c1012142d8322 ("drivers: net: xgene: Simplify xgene_enet_setup_mss() to kill warning") with gcc-4.3? Yes, that was a false positive. Or see commit cc4a7ffe02c95f53 ("spi: fsl-lpspi: Pre-initialize ret in fsl_lpspi_transfer_one_msg()"). That one was a real bug. I don't see that in any of the kisskb build logs, and they use gcc-4.2.4 for avr32. So having gcc-4.2 or gcc-4.3 in a farm won't help. And as long as I find real bugs this way, I'd like to continue doing it. >> BTW, below is the diff I use to avoid an ICE. >> After that, it builds and (test)boots fine on ARAnyM ;-) > > I guess this means that even your builds require extra patches and you > can't strictly build a defconfig and expect that to work ;-) No sane people enable GFS in defconfig, so it's not affected. Oh wait, some mips, powerpc, s390, and tile do ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Mon, Apr 24, 2017 at 12:17 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Mon, Apr 24, 2017 at 11:44 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven >> <geert@linux-m68k.org> wrote: >>> On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: >>> My main motivation for keep on using gcc-4.1 is that it gives many warnings >>> that were disabled in later gcc versions. I do look at all new warnings, and >>> send patches when they are real bugs, or are trivial to silence. >> >> What kind of warnings do you see that disappeared with later versions? >> Do you know what caused them to disappear in later versions (different >> optimization decisions, warning getting disabled by default but still available >> for turning on manually, ...)? Do you know if the disabled warnings are >> still there in gcc-4.3 (I can try it out if you give me examples)? > > Mostly the "may be used uninitialized" warnings. I believe they were disabled > in gcc-4.3 (4.2?) and later due to too many false positives, which is not an > issue for me, as I look at differences. > They were re-enabled lately (with much less false-positives), that's why you > see them, and fix them. Linus added -Wno-maybe-uninitialized a while ago, and I think only gcc-4.8 and higher were affected by that, as earlier versions only understand -Wuninitialized (meaning both "definitely uninitialized" and "might be uninitialized". The latest state is that gcc-4.9 enables all uninitialized warnings and I try to fix them for all known compilers, gcc-4.8 disables -Wmaybe-uninitialized unless you build with "make W=2". On gcc-4.9 and higher, we also don't enable -Wmaybe-unintialized when certain configuration options are set that cause extra false positives, but it's still enabled with W=2. I actually think it would be a good idea to also disable -Wuninitialized for gcc-4.7 and earlier unless you ask for W2. That would get us much closer to a clean build, but still give you the chance to see the warnings if you really want to. > For example, do you see the warning fixed by commit 1b8c1012142d8322 > ("drivers: net: xgene: Simplify xgene_enet_setup_mss() to kill warning") > with gcc-4.3? Yes, that was a false positive. I see this one until gcc-4.8 if I build with W=2 to turn the warning back on. > Or see commit cc4a7ffe02c95f53 ("spi: fsl-lpspi: Pre-initialize ret in > fsl_lpspi_transfer_one_msg()"). That one was a real bug. > > I don't see that in any of the kisskb build logs, and they use gcc-4.2.4 for > avr32. So having gcc-4.2 or gcc-4.3 in a farm won't help. Also here: I see the warning on ARM with all versions from gcc-4.1 through 4.8 (with W=1), but not any higher versions including 7.0.1. If I mark fsl_lpspi_transfer_one as 'noinline', I see it on all versions, which is a bit odd. It might be worth opening a gcc bug report for that. I tried the 'noinline' as I suspected gcc might be smart enough to figure out that the list is never empty, but I later noticed that it has no way of knowing that even without the 'noinline' flag. > And as long as I find real bugs this way, I'd like to continue doing it. I've tested all the architectures I mentioned earlier that were around 10 years ago (aside from ia64, I could not build gcc successfully) with linux-4.3 (arbitrarily picked, this was the version in which x86 and mips no longer built with gcc-4.1), and built a defconfig with both gcc-4.9 (which I had around from earlier testing) and with gcc-4.1/4.3: gcc-4.1 gcc-4.3 gcc-4.9 alpha failed success success arm failed success success cris failed success success frv failed failed success m32r success success success m68k success success success mips failed failed success parisc success success success powerpc failed failed success s390 failed failed success sh failed success success x86 failed success success I'd conclude that nobody aside from you sends bugfixes for 4.1, or has done so in a while. I have the logs available if you want, but there isn't really much surprising: we get the same link error as on mips and x86 on some additional architectures, powerpc and s390 use features that weren't available and frv hits an ICE. We could define the minimum compiler to be gcc-4.3 on all architectures except m68k (and possibly parisc, certainly nobody cares about m32r enough), where it would be gcc-4.1, to reflect what is actually already the case. Arnd
On Mon, 24 Apr 2017, Arnd Bergmann wrote: > > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would not > > do it.I guess most people using old compilers know what they're doing. > > What I'm trying to find out first is whether "people regularly using 10+ > year old compilers for the latest kernels" is a strict subset of "people in > Geert's household". Well I do not live with Geert TBH. > Given that none of the three architectures I looked at (arm, mips, x86) > has successfully built any defconfig for a few years, it's quite possible > that it's just you ;-) The other architectures that were around 10 years > ago (so they might have someone who still has old toolchain binaries) > and that still exist today are alpha, cris, frv, ia64, m32r, parisc, powerpc, > s390, sh, sparc and xtensa. The first six are similar to m68k in that the > hardware is mostly obsolete and the ports are kept around to support > those old systems that might also use ancient toolchains, or new > toolchains may be unmaintained or buggy, which could be a reason > to keep 4.1 supported or at least try to find out if 4.1 (or even any other > version) still works at all. Huh? $ git log -1 commit 5a7ad1146caa895ad718a534399e38bd2ba721b7 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Sun Apr 23 16:53:00 2017 -0700 Linux 4.11-rc8 $ /usr/bin/time make ARCH=mips CROSS_COMPILE=mipsel-linux- decstation_defconfig vmlinux >/dev/null 2>&1 1014.19user 71.47system 19:33.24elapsed 92%CPU (0avgtext+0avgdata 0maxresident)k18764inputs+242504outputs (704major+9549837minor)pagefaults 0swaps $ mipsel-linux-gcc --version gcc (GCC) 4.1.2 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ Methinks it builds just fine. Maciej
On Mon, Apr 24, 2017 at 6:53 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote: > On Mon, 24 Apr 2017, Arnd Bergmann wrote: > >> > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would not >> > do it.I guess most people using old compilers know what they're doing. >> >> What I'm trying to find out first is whether "people regularly using 10+ >> year old compilers for the latest kernels" is a strict subset of "people in >> Geert's household". > > Well I do not live with Geert TBH. Sorry about that, you had mentioned that you had used it recently, which should have weighed more than my own results. > Linux 4.11-rc8 > $ /usr/bin/time make ARCH=mips CROSS_COMPILE=mipsel-linux- decstation_defconfig vmlinux >/dev/null 2>&1 > 1014.19user 71.47system 19:33.24elapsed 92%CPU (0avgtext+0avgdata > 0maxresident)k18764inputs+242504outputs (704major+9549837minor)pagefaults 0swaps > $ mipsel-linux-gcc --version > gcc (GCC) 4.1.2 > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > $ > > Methinks it builds just fine. I must have done something wrong: I tried a few defconfigs with a latest kernel and compiler and they all failed, found linux-4.3 to be the first version that was broken for all of them (most with a link time error, some with missing gcc features) I later tried all mips defconfigs with linux-4.3 and they all failed with gcc-4.1.3 but built fine with gcc-4.9. I've now tried decstation_defconfig in 4.8-rc11, and this is what I see for gcc-4.1.3 make O=build/mips/decstation_defconfig/ -skj30 CC=/home/arnd/cross-gcc/bin/mips-linux-gcc-4.1.3\ ARCH=mips -f Makefile CROSS_COMPILE=/home/arnd/cross-gcc/bin/mips-linux- /git/arm-soc/fs/dcache.c: In function '__d_move': /git/arm-soc/fs/dcache.c:2773: warning: 'n' may be used uninitialized in this function /git/arm-soc/fs/dcache.c: In function 'd_splice_alias': /git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized in this function /git/arm-soc/fs/dcache.c: In function 'd_add': /git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized in this function /git/arm-soc/mm/page-writeback.c: In function 'balance_dirty_pages_ratelimited': /git/arm-soc/mm/page-writeback.c:1627: warning: 'writeback' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c:1628: warning: 'filepages' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c:1628: warning: 'headroom' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c: In function 'wb_over_bg_thresh': /git/arm-soc/mm/page-writeback.c:1956: warning: 'filepages' is used uninitialized in this function /git/arm-soc/mm/page-writeback.c:1956: warning: 'headroom' is used uninitialized in this function /git/arm-soc/net/core/flow_dissector.c: In function '__skb_flow_dissect': /git/arm-soc/net/core/flow_dissector.c:272: warning: 'vlan' may be used uninitialized in this function /git/arm-soc/fs/splice.c: In function 'iter_file_splice_write': /git/arm-soc/fs/splice.c:716: warning: 'ret' may be used uninitialized in this function /git/arm-soc/net/core/dev.c: In function 'validate_xmit_skb_list': /git/arm-soc/net/core/dev.c:3003: warning: 'tail' may be used uninitialized in this function /git/arm-soc/kernel/printk/printk.c: In function 'devkmsg_sysctl_set_loglvl': /git/arm-soc/kernel/printk/printk.c:161: warning: 'old' may be used uninitialized in this function /git/arm-soc/kernel/time/ntp.c: In function 'ntp_validate_timex': /git/arm-soc/kernel/time/ntp.c:707: warning: comparison is always false due to limited range of data type /git/arm-soc/kernel/time/ntp.c:709: warning: comparison is always false due to limited range of data type /git/arm-soc/kernel/time/timekeeping.c: In function 'get_device_system_crosststamp': /git/arm-soc/kernel/time/timekeeping.c:1084: warning: 'cs_was_changed_seq' may be used uninitialized in this function /git/arm-soc/net/sunrpc/xdr.c: In function 'xdr_stream_decode_string_dup': /git/arm-soc/include/linux/sunrpc/xdr.h:409: warning: 'len' may be used uninitialized in this function /git/arm-soc/crypto/drbg.c: In function 'drbg_kcapi_random': /git/arm-soc/crypto/drbg.c:1865: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. /git/arm-soc/scripts/Makefile.build:300: recipe for target 'crypto/drbg.o' failed So it still fails, but only because of one compiler error that I can avoid by disabling that driver, and you probably use a slightly patched compiler version that doesn't have this particular bug, or it was a regression between gcc-4.1.2 and 4.1.3. Arnd
Hi Arnd, On Mon, Apr 24, 2017 at 7:29 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Mon, Apr 24, 2017 at 6:53 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote: >> On Mon, 24 Apr 2017, Arnd Bergmann wrote: >>> > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would not >>> > do it.I guess most people using old compilers know what they're doing. >>> >>> What I'm trying to find out first is whether "people regularly using 10+ >>> year old compilers for the latest kernels" is a strict subset of "people in >>> Geert's household". >> >> Well I do not live with Geert TBH. > > Sorry about that, you had mentioned that you had used it recently, which should > have weighed more than my own results. If you prefer to consider everyone who's been sleeping in the same room at one of the Oldenburg Linux meetings as part of my household, that's fine for me ;-) > So it still fails, but only because of one compiler error that I can avoid by > disabling that driver, and you probably use a slightly patched compiler > version that doesn't have this particular bug, or it was a regression between > gcc-4.1.2 and 4.1.3. Mine is also some patched version of 4.1.1, built from Ubuntu sources: gcc version 4.1.2 20061115 (prerelease) (Ubuntu 4.1.1-21) These sources probably even contained the fixes to make gcc-4.1.1 usable on CELL. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Mon, 24 Apr 2017, Arnd Bergmann wrote: > I later tried all mips defconfigs with linux-4.3 and they all failed > with gcc-4.1.3 > but built fine with gcc-4.9. I've now tried decstation_defconfig in 4.8-rc11, > and this is what I see for gcc-4.1.3 > > make O=build/mips/decstation_defconfig/ -skj30 > CC=/home/arnd/cross-gcc/bin/mips-linux-gcc-4.1.3\ ARCH=mips -f > Makefile CROSS_COMPILE=/home/arnd/cross-gcc/bin/mips-linux- > /git/arm-soc/fs/dcache.c: In function '__d_move': > /git/arm-soc/fs/dcache.c:2773: warning: 'n' may be used uninitialized > in this function > /git/arm-soc/fs/dcache.c: In function 'd_splice_alias': > /git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized > in this function > /git/arm-soc/fs/dcache.c: In function 'd_add': > /git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized > in this function > /git/arm-soc/mm/page-writeback.c: In function 'balance_dirty_pages_ratelimited': > /git/arm-soc/mm/page-writeback.c:1627: warning: 'writeback' is used > uninitialized in this function > /git/arm-soc/mm/page-writeback.c:1628: warning: 'filepages' is used > uninitialized in this function > /git/arm-soc/mm/page-writeback.c:1628: warning: 'headroom' is used > uninitialized in this function > /git/arm-soc/mm/page-writeback.c: In function 'wb_over_bg_thresh': > /git/arm-soc/mm/page-writeback.c:1956: warning: 'filepages' is used > uninitialized in this function > /git/arm-soc/mm/page-writeback.c:1956: warning: 'headroom' is used > uninitialized in this function > /git/arm-soc/net/core/flow_dissector.c: In function '__skb_flow_dissect': > /git/arm-soc/net/core/flow_dissector.c:272: warning: 'vlan' may be > used uninitialized in this function > /git/arm-soc/fs/splice.c: In function 'iter_file_splice_write': > /git/arm-soc/fs/splice.c:716: warning: 'ret' may be used uninitialized > in this function > /git/arm-soc/net/core/dev.c: In function 'validate_xmit_skb_list': > /git/arm-soc/net/core/dev.c:3003: warning: 'tail' may be used > uninitialized in this function > /git/arm-soc/kernel/printk/printk.c: In function 'devkmsg_sysctl_set_loglvl': > /git/arm-soc/kernel/printk/printk.c:161: warning: 'old' may be used > uninitialized in this function > /git/arm-soc/kernel/time/ntp.c: In function 'ntp_validate_timex': > /git/arm-soc/kernel/time/ntp.c:707: warning: comparison is always > false due to limited range of data type > /git/arm-soc/kernel/time/ntp.c:709: warning: comparison is always > false due to limited range of data type > /git/arm-soc/kernel/time/timekeeping.c: In function > 'get_device_system_crosststamp': > /git/arm-soc/kernel/time/timekeeping.c:1084: warning: > 'cs_was_changed_seq' may be used uninitialized in this function > /git/arm-soc/net/sunrpc/xdr.c: In function 'xdr_stream_decode_string_dup': > /git/arm-soc/include/linux/sunrpc/xdr.h:409: warning: 'len' may be > used uninitialized in this function > /git/arm-soc/crypto/drbg.c: In function 'drbg_kcapi_random': > /git/arm-soc/crypto/drbg.c:1865: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://gcc.gnu.org/bugs.html> for instructions. > /git/arm-soc/scripts/Makefile.build:300: recipe for target > 'crypto/drbg.o' failed > > So it still fails, but only because of one compiler error that I can avoid by > disabling that driver, and you probably use a slightly patched compiler > version that doesn't have this particular bug, or it was a regression between > gcc-4.1.2 and 4.1.3. Umm, I didn't build modules, sorry, because I don't usually use them with those systems. However I have completed this step now and it also worked just fine: $ ls -la crypto/drbg.o -rw-r--r-- 1 macro macro 14096 Apr 24 18:59 crypto/drbg.o $ file crypto/drbg.o crypto/drbg.o: ELF 32-bit LSB MIPS-I relocatable, MIPS, version 1 (SYSV), not stripped $ so you are likely right that either I have a patch applied to my 4.1.2 build that has somehow fixed the ICE or it is a 4.1.3 regression (or a bad patch in your 4.1.3 build). BTW I do see these `may be used uninitialized' warnings just as Geert does and even have a local patch, which I have neglected to submit, for a 64-bit configuration (`decstation_defconfig' is 32-bit) where in a single place -Werror turns it into a build failure. I do not consider it a big issue though, and might even wrap that patch up and submit sometime. Maciej
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c index ec0848fcca02d896..eb75b324ac0ac53d 100644 --- a/fs/gfs2/glock.c +++ b/fs/gfs2/glock.c @@ -650,13 +650,16 @@ int gfs2_glock_get(struct gfs2_sbd *sdp, u64 number, struct gfs2_glock **glp) { struct super_block *s = sdp->sd_vfs; - struct lm_lockname name = { .ln_number = number, + // FIXME Avoid gcc 4.1.2 20061115 (prerelease) (Ubuntu 4.1.1-21) ICE + //struct lm_lockname name = { .ln_number = number, + struct lm_lockname name = { .ln_type = glops->go_type, .ln_sbd = sdp }; struct gfs2_glock *gl, *tmp = NULL; struct address_space *mapping; struct kmem_cache *cachep; int ret, tries = 0; + name.ln_number = number; rcu_read_lock(); gl = rhashtable_lookup_fast(&gl_hash_table, &name, ht_parms); diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c index 86ccc01593937d93..8783b72df5fa3d0c 100644 --- a/fs/gfs2/rgrp.c +++ b/fs/gfs2/rgrp.c @@ -1767,7 +1767,11 @@ static void try_rgrp_unlink(struct gfs2_rgrpd *rgd, u64 *last_unlinked, u64 skip struct gfs2_inode *ip; int error; int found = 0; - struct gfs2_rbm rbm = { .rgd = rgd, .bii = 0, .offset = 0 }; + // FIXME Avoid gcc 4.1.2 20061115 (prerelease) (Ubuntu 4.1.1-21) ICE + // struct gfs2_rbm rbm = { .rgd = rgd, .bii = 0, .offset = 0 }; + struct gfs2_rbm rbm = { .bii = 0, .offset = 0 }; + rbm.rgd = rgd; + while (1) {