Re: GCC optimizes integer overflow: bug or feature?

Paul Brook wrote: Who says the optimisation is valid? The language standard? The example was given as something that's 100% safe to optimize. I'm disagreeing with that assertion. The use I describe isn't that unlikely if the code was written by someone with poor knowledge of C. My point is

Re: GCC optimizes integer overflow: bug or feature?

On Friday 22 December 2006 02:06, Robert Dewar wrote: > Paul Brook wrote: > > On Friday 22 December 2006 00:58, Denis Vlasenko wrote: > >> On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote: > >>> There are a lot of 100.00% safe optimizations which gcc > >>> can do. Value range propagation for

Re: GCC optimizes integer overflow: bug or feature?

Paul Eggert <[EMAIL PROTECTED]> writes: | Ian Lance Taylor <[EMAIL PROTECTED]> writes: | | > We could disable VRP's assumptions about signed overflow. I don't | > know what else we could do to fix this case. I don't even know how we | > could issue a useful warning. Perhaps there is a way. |

Re: GCC optimizes integer overflow: bug or feature?

Paul Brook wrote: On Friday 22 December 2006 00:58, Denis Vlasenko wrote: On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote: There are a lot of 100.00% safe optimizations which gcc can do. Value range propagation for bitwise operations, for one Or this, absolutely typical C code. i386 ar

Re: GCC optimizes integer overflow: bug or feature?

On Friday 22 December 2006 00:58, Denis Vlasenko wrote: > On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote: > > There are a lot of 100.00% safe optimizations which gcc > > can do. Value range propagation for bitwise operations, for one > > Or this, absolutely typical C code. i386 arch can co

Re: GCC optimizes integer overflow: bug or feature?

On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote: > There are a lot of 100.00% safe optimizations which gcc > can do. Value range propagation for bitwise operations, for one Or this, absolutely typical C code. i386 arch can compare 16 bits at a time here (luckily, no alighment worries on th

proposed patches to mbchar, mbswidth, wcwidth to use new wctype module

Now that we have a wctype module we can simplify some of the other modules to just include and depend on the wctype module. Here is a proposed patch. 2006-12-21 Paul Eggert <[EMAIL PROTECTED]> * lib/mbchar.h: Just include ; the wctype module handles its gotchas now. * l

Re: coreutils 6.6 fails to compile on IRIX 5.3

This is following up on the thread here: Georg Schwarz <[EMAIL PROTECTED]> writes: > 6.7 fails the same way: > > cc -g -o dir ls.o ls-dir.o ../lib/libcoreutils.a ../lib/libcoreutils.a > ld: > Unresolved: > _ctmp_ > _iswct

Re: GCC optimizes integer overflow: bug or feature?

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > We could disable VRP's assumptions about signed overflow. I don't > know what else we could do to fix this case. I don't even know how we > could issue a useful warning. Perhaps there is a way. It is a knotty problem. Thanks for thinking about it

Re: GCC optimizes integer overflow: bug or feature?

On Thu, 21 Dec 2006, Ian Lance Taylor wrote: > > Another question for the GCC experts: would it fix the bug > > if we replaced "j *= 2" with "j <<= 1" in this sample code? > > Well, mainline VRP isn't clever enough to understand that case. But > it doesn't make the code any more defined. A left

Re: GCC optimizes integer overflow: bug or feature?

Paul Eggert <[EMAIL PROTECTED]> writes: > That probably sounds vague, so here's the code that beta > gcc -O2 actually broke (which started this whole thread): > > int j; > for (j = 1; 0 < j; j *= 2) > if (! bigtime_test (j)) > return 1; It's interesting to note that in

Re: GCC optimizes integer overflow: bug or feature?

Dave Korn wrote: On 20 December 2006 21:42, Matthew Woehlke wrote: That said, I've seen even stranger things, too. For example: foo->bar = make_a_bar(); foo->bar->none = value; being rendered as: call make_a_bar foo->bar->none = value foo->bar = So what was wrong with my C code in that inst

Re: GCC optimizes integer overflow: bug or feature?

"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > Conversion of out-of-range integers to signed types is > implementation-defined not undefined, Thanks for the correction; I keep forgetting that. However, a conforming implementation is allowed to raise a signal for those conversions, which could

Re: GCC optimizes integer overflow: bug or feature?

Marcin Dalecki wrote: But the same applies to floating point numbers. There, the situation is even better, because nowadays I can rely on a float or double being the representation defined in IEEE 754 because there is such overwhelming hardware support. You better don't. Really! Please just

Re: GCC optimizes integer overflow: bug or feature?

On Thu, 21 Dec 2006, Paul Eggert wrote: > But because bigtime_test wants an int, this causes the test > program to compute the equivalent of (int) ((unsigned int) > INT_MAX + 1), and C99 says that if you cannot assume > wrapping semantics this expression has undefined behavior in > the common case

Re: GCC optimizes integer overflow: bug or feature?

Paolo Bonzini <[EMAIL PROTECTED]> writes: > On the autoconf mailing list, Paul Eggert mentioned as a good > compromise that GCC could treat signed overflow as undefined only for > loops and not in general. What I meant to propose (and perhaps did not propose clearly enough) is that if the C appli

Re: issue with getopt

Bruno Haible wrote: Lorenzo Bettini wrote: You see, there's no clear borderline between <> and "". I see, but are <> ensuring that the version of gnulib is used (even if getopt.h is available in the system)? The -I flags added by automake and gnulib-tool normally guarantee that. Normally. I.e

Re: issue with getopt

Lorenzo Bettini wrote: > > You see, there's no clear borderline between <> and "". > > I see, but are <> ensuring that the version of gnulib is used (even if > getopt.h is available in the system)? The -I flags added by automake and gnulib-tool normally guarantee that. Normally. I.e. not if the

Re: GCC optimizes integer overflow: bug or feature?

Some time ago (a year?) I was told on this mailing-list that code breakage due to undefinedness of signed overflow is not too common (I at least claimed with no evidence that it was more than one bug per 1,000 lines). My claim was counterclaimed by something like "most of the time people work