Re: GCC4 Util-linux sed [Was: Re: r6800]

On Sat, Sep 03, 2005 at 08:36:40PM -0400, Jeremy Huntwork wrote: > > Well, does anyone have a recent build of trunk with a reiser* partition? > Perhaps we could check to see if cfdisk bombs there too? Anyway, > recalling Matt's previous email, gcc4 was slated to move to trunk in a > matter of a

Re: GCC4 Util-linux sed [Was: Re: r6800]

Archaic wrote: Even though this bug seems to be tickled by gcc-4, would it be prudent to add this to trunk as well since it's running the same version of util-linux? Well, does anyone have a recent build of trunk with a reiser* partition? Perhaps we could check to see if cfdisk bombs there to

Re: GCC4 Util-linux sed [Was: Re: r6800]

On Sat, Sep 03, 2005 at 08:24:23PM -0400, Jeremy Huntwork wrote: > Greg Schafer wrote: > >very often. So in summary, if type 83 partitions exist and they have > >reiserfs OR if they don't have any filesystem on them whatsoever, the > >problematic code path is taken and the crash is likely to occur.

Re: GCC4 Util-linux sed [Was: Re: r6800]

Jürg Billeter wrote: > The patch speaks for itself, BTW, changing the problematic line to: && read(fd, &reiserfsb, sizeof(reiserfsb)) == sizeof(reiserfsb) seems to also fix the problem. It's simpler and is more in line with the other filesystem checks in that function. Maybe the above variant

Re: GCC4 Util-linux sed [Was: Re: r6800]

Greg Schafer wrote: very often. So in summary, if type 83 partitions exist and they have reiserfs OR if they don't have any filesystem on them whatsoever, the problematic code path is taken and the crash is likely to occur. Hope this makes sense. Yes, very much. Thanks. And of course, now that

Re: GCC4 Util-linux sed [Was: Re: r6800]

Jeremy Huntwork wrote: > Jürg Billeter wrote: >> Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some >> debug info on the stack and that's the reason gdb didn't help. The >> problem occured on all systems with linux partitions that don't have a >> ext2/ext3, xfs, or jfs filesyst

Re: Expected glibc test failures with gcc4 ?

On Sun, 4 Sep 2005, Greg Schafer wrote: There is a patch available to fix most of the failures, but not all: http://sources.redhat.com/ml/libc-hacker/2005-03/msg00067.html http://sources.redhat.com/ml/glibc-cvs/2005-q2/msg00239.html There is also available a dubious workaround: http://www.d

Re: cannot boot

On Sat, 3 Sep 2005, David Ciecierski wrote: It most certainly does have to be selected. Yeah, my sys runs like a charm with it :-) Just a small question: with grsec every mount and unmount produces a few lines of text saying who is {,u}mounting something. Can that be turned off? I mean, it's

Re: GCC4 Util-linux sed [Was: Re: r6800]

Jürg Billeter wrote: Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some debug info on the stack and that's the reason gdb didn't help. The problem occured on all systems with linux partitions that don't have a ext2/ext3, xfs, or jfs filesystem as the crash happens during the r

Re: Expected glibc test failures with gcc4 ?

Ken Moffat wrote: > A question for all of the people champing at the bit to get gcc4 into > the mainline book - does *anybody* see glibc passing the maths tests > (float, double, ifloat, idouble) in chapter 6 ? If they pass for you, > what CPU ? There is a patch available to fix most of the

Re: Expected glibc test failures with gcc4 ?

On Sat, 3 Sep 2005, Randy McMurchy wrote: [EMAIL PROTECTED]: ~/build > grep Error Build-System/Installed-System/glibc*/check.log make[2]: *** [/build/glibc-build/math/test-float.out] Error 1 make[2]: *** [/build/glibc-build/math/test-double.out] Error 1 make[2]: *** [/build/glibc-build/math/te

Re: Expected glibc test failures with gcc4 ?

Ken Moffat wrote these words on 09/03/05 15:58 CST: > A question for all of the people champing at the bit to get gcc4 into > the mainline book - does *anybody* see glibc passing the maths tests > (float, double, ifloat, idouble) in chapter 6 ? If they pass for you, > what CPU ? [EMAIL PROTE

Expected glibc test failures with gcc4 ?

A question for all of the people champing at the bit to get gcc4 into the mainline book - does *anybody* see glibc passing the maths tests (float, double, ifloat, idouble) in chapter 6 ? If they pass for you, what CPU ? I've got a reasonably new AMD processor (San Diego athlon64, slumming

Re: optimization for lfs-book (6.5 Creating Directories)

On Sat, 3 Sep 2005, Archaic wrote: On Fri, Sep 02, 2005 at 04:13:24PM +0200, Tobias Stoeckmann wrote: Just a little change that is easier to type and also shows a new feature in bash-3.0 (so I think it would be nice to use it): In "6.5. Creating Directories

Re: optimization for lfs-book (6.5 Creating Directories)

On Fri, Sep 02, 2005 at 04:13:24PM +0200, Tobias Stoeckmann wrote: > Just a little change that is easier > to type and also shows a new > feature in bash-3.0 (so I think it would be nice to use it): > > In "6.5. Creating Directories": > > Instead of typing "i

Re: Successful First Install - GCC-4.0.1

Dex wrote: Went pretty smoothly and completed in less than 24 hours despite recompiling gcc a number of times to play with different C/CXX flag settings. No matter what I tried I got errors on the math tests and ended up with -march=ahtIon-xp -O2 -pipe. I did note that a couple of packages were

Re: GCC4 Util-linux sed [Was: Re: r6800]

Chris Staub wrote: Jürg Billeter wrote: On Sam, 2005-09-03 at 05:26 -0400, Chris Staub wrote: On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote: Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some debug info on the stack and that's the reason gdb didn't help. The

Re: GCC4 Util-linux sed [Was: Re: r6800]

Jürg Billeter wrote: On Sam, 2005-09-03 at 05:26 -0400, Chris Staub wrote: On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote: Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some debug info on the stack and that's the reason gdb didn't help. The problem occured on all

Re: GCC4 Util-linux sed [Was: Re: r6800]

Chris Staub wrote: Jürg Billeter wrote: On Sam, 2005-09-03 at 18:53 +1000, Greg Schafer wrote: On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote: Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some debug info on the stack and that's the reason gdb didn't help. The

Re: GCC4 Util-linux sed [Was: Re: r6800]

On Sam, 2005-09-03 at 05:26 -0400, Chris Staub wrote: > >>On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote: > >> > >>>Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some > >>>debug info on the stack and that's the reason gdb didn't help. The > >>>problem occured on all sys

Re: GCC4 Util-linux sed [Was: Re: r6800]

Jürg Billeter wrote: Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some debug info on the stack and that's the reason gdb didn't help. The problem occured on all systems with linux partitions that don't have a ext2/ext3, xfs, or jfs filesystem as the crash happens during the r

Re: GCC4 Util-linux sed [Was: Re: r6800]

Greg Schafer wrote: Jürg Billeter wrote: It's not as easy as it sounds. As it's very likely that it's a GCC optimization bug you can't really debug the compiled cfdisk as the generated code is wrong. The stack after the SEGV is completely destroyed, gdb doesn't help at all. It seems as if y

Re: GCC4 Util-linux sed [Was: Re: r6800]

Jürg Billeter wrote: On Sam, 2005-09-03 at 18:53 +1000, Greg Schafer wrote: On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote: Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some debug info on the stack and that's the reason gdb didn't help. The problem occured on al

Re: GCC4 Util-linux sed [Was: Re: r6800]

Jürg Billeter wrote: The patch speaks for itself, I have no idea why this doesn't crash > with other gcc versions / optimization settings, must be luck... The attached script should pinpoint the particular setting that tickles the crash, in case you're really interested in finding out! IIRC,

Re: GCC4 Util-linux sed [Was: Re: r6800]

On Sam, 2005-09-03 at 18:53 +1000, Greg Schafer wrote: > On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote: > > > Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some > > debug info on the stack and that's the reason gdb didn't help. The > > problem occured on all systems w

Re: GCC4 Util-linux sed [Was: Re: r6800]

On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote: > Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some > debug info on the stack and that's the reason gdb didn't help. The > problem occured on all systems with linux partitions that don't have a > ext2/ext3, xfs, or jfs f

Re: GCC4 Util-linux sed [Was: Re: r6800]

On Sam, 2005-09-03 at 08:24 +0200, Jürg Billeter wrote: > On Sam, 2005-09-03 at 10:35 +1000, Greg Schafer wrote: > > Better still, we should just find the bug and fix it. Why pessimize the > > whole of Util-linux just because of an intermittent bug in cfdisk? It's a > > bad workaround IMHO. Surely

Re: GCC4 Util-linux sed [Was: Re: r6800]

Jürg Billeter wrote: > It's not as easy as it sounds. As it's very likely that it's a GCC > optimization bug you can't really debug the compiled cfdisk as the > generated code is wrong. The stack after the SEGV is completely > destroyed, gdb doesn't help at all. It seems as if you are able to rep

Re: GCC4 Util-linux sed [Was: Re: r6800]

On Sam, 2005-09-03 at 08:24 +0200, Jürg Billeter wrote: > Maybe it wouldn't be that unwise to test with current 4.0 (or maybe also > 4.1) snapshot as it may already have been fixed. Will test that 4.0-20050901 and 4.1-20050902 are still affected. -- Jürg Billeter <[EMAIL PROTECTED]> -- http://l