Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Ian Lance Taylor wrote: I believe there is a comprehensible distinction between "compiler will not assume that signed overflow is undefined behaviour" and "compiler will cause all arithmetic to wrap around." In any case, I have no plans to continue working on this. I described my work in consi

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Robert Dewar <[EMAIL PROTECTED]> writes: > > You're right, I shouldn't have said "implementation defined." > > What will happen with -fno-strict-overflow is whatever the processor > > ISA happens to do when a signed arithmetic operation overflows. For > > ordinary machines it will just wrap. > >

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Ian Lance Taylor wrote: You're right, I shouldn't have said "implementation defined." What will happen with -fno-strict-overflow is whatever the processor ISA happens to do when a signed arithmetic operation overflows. For ordinary machines it will just wrap. Given that all ordinary machines

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Robert Dewar <[EMAIL PROTECTED]> writes: > Ian Lance Taylor wrote: > > > The new option -fstrict-overflow tells gcc that it can assume the > > strict signed overflow semantics prescribed by the language standard. > > This option is enabled by default at -O2 and higher. Using > > -fno-strict-over

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Robert Dewar wrote: Ian Lance Taylor wrote: The new option -fstrict-overflow tells gcc that it can assume the strict signed overflow semantics prescribed by the language standard. This option is enabled by default at -O2 and higher. Using -fno-strict-overflow will tell gcc that it can not assum

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Ian Lance Taylor wrote: The new option -fstrict-overflow tells gcc that it can assume the strict signed overflow semantics prescribed by the language standard. This option is enabled by default at -O2 and higher. Using -fno-strict-overflow will tell gcc that it can not assume that signed overfl

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert <[EMAIL PROTECTED]> writes: > >> GCC itself relies on wrapv semantics. As does glibc. And > >> coreutils. And GNU tar. And Python. I'm sure there are > >> many other significant programs. I don't have time to do a > >> comprehensive survey right now. > > > > Where does GCC rely o

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Thorsten Glaser <[EMAIL PROTECTED]> writes: > Paul Eggert dixit: > >> […] gcc -O2 makes no promises without >> -fwrapv. > > gcc -O1 -fwrapv even doesn't work correctly for gcc3, > and gcc2 and gcc <3.3(?) don't even have -fwrapv: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477 The latter wo

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert dixit: > […] gcc -O2 makes no promises without > -fwrapv. gcc -O1 -fwrapv even doesn't work correctly for gcc3, and gcc2 and gcc <3.3(?) don't even have -fwrapv: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477 bye, //mirabile -- "Using Lynx is like wearing a really good pair o

Re: [bug-gnulib] Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Richard Kenner wrote: > (3) How many programs are known to rely on wrap semantics? For each: > (a) How hard was it to determine there was a problem with that > assumption? A piece of data for GNU clisp and cln: - For clisp, it was easy to find out and fix all problems, because the

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote: "Richard Guenther" <[EMAIL PROTECTED]> writes: > On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote: >> Paul Eggert <[EMAIL PROTECTED]> writes: >> > Mark Mitchell <[EMAIL PROTECTED]> writes: >> >> it sounds like that would eliminate most

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

"Richard Guenther" <[EMAIL PROTECTED]> writes: > On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote: >> Paul Eggert <[EMAIL PROTECTED]> writes: >> > Mark Mitchell <[EMAIL PROTECTED]> writes: >> >> it sounds like that would eliminate most of the problem. Certainly, >> >> making -INT_MIN evaluat

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote: Paul Eggert <[EMAIL PROTECTED]> writes: > Mark Mitchell <[EMAIL PROTECTED]> writes: >> it sounds like that would eliminate most of the problem. Certainly, >> making -INT_MIN evaluate to INT_MIN, when expressed like that, is an >> easy thing

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert <[EMAIL PROTECTED]> writes: > Mark Mitchell <[EMAIL PROTECTED]> writes: >> it sounds like that would eliminate most of the problem. Certainly, >> making -INT_MIN evaluate to INT_MIN, when expressed like that, is an >> easy thing to do; that's just a guarantee about constant folding. >

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Laurent GUERBY wrote: On Sun, 2006-12-31 at 12:04 -0500, Robert Dewar wrote: Duncan Sands wrote: The C front-end performs this transformation too. I'm not claiming that the back-end optimizers would actually do something sensible if the front-end didn't transform this code (in fact they don't

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On Sun, 2006-12-31 at 12:04 -0500, Robert Dewar wrote: > Duncan Sands wrote: > > > The C front-end performs this transformation too. I'm not claiming that the > > back-end optimizers would actually do something sensible if the front-end > > didn't transform this code (in fact they don't seem too)

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On Mon, 2007-01-01 at 22:27 -0500, Richard Kenner wrote: > > I don't think -frisky is a good name for that option. A better name > > would be -fstrict. > > Or -pedantic? ;-) -pedantic-codegen :) Laurent

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Diego Novillo <[EMAIL PROTECTED]> writes: | Mark Mitchell wrote on 01/01/07 14:46: | | > What a thread this has turned out to be. | > | Indeed. | | In general, I'm not too thrilled with the idea of disabling | transformations for the sake of non-conforming code. However, I would | not mind a -f

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > I don't think -frisky is a good name for that option. Aaaaww. Nobody will remember boring and forbidding option names like -fstrict or -fstandard. Everybody will remember -frisky. Where's your sense of pun and -foetry? Anyway, thanks for your sum

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Mark Mitchell wrote on 01/01/07 14:46: What a thread this has turned out to be. Indeed. In general, I'm not too thrilled with the idea of disabling transformations for the sake of non-conforming code. However, I would not mind a -fconforming flag similar to -fstrict-aliasing. I haven't ye

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On Jan 1, 2007, at 21:14, Ian Lance Taylor wrote: [...] extern void bar (void); void foo (int m) { int i; for (i = 1; i < m; ++i) { if (i > 0) bar (); } } Here the limit for i without -fwrapv becomes (1, INF]. This enables VRP to eliminate the test "i > 0". With -fwra

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Richard Guenther wrote: >> Perhaps Richard G. would be so kind as to turn this off in VRP, and >> rerun SPEC with that change? > > I can do this. Thank you very much! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Richard Kenner wrote: > ... > In other words, -fwrapv says that we are modifying the language semantics > to define signed overflows as wrapping and this will have effects on the > optimizer (so the language effect is primary), while -fno-strict-aliasing > says what the optimizer will do and henc

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Schlie wrote: So this proposal would be tantamount to implementing a different language at -O1 and -O2, and having -O2 change the formal semantic interpretation of the program. That seems a very bad idea to me. ... Yes, it would be laudable for GCC to adopt the principle that whatever lan

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Robert Dewar wrote: > ... > I think it is a bad idea for the optimization levels to deal with > anything other than optimization. -fwrapv is not about optimization, > it is about changing the language semantics. > > So this proposal would be tantamount to implementing a different > language at -

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Well, while the effect of -fstrict-aliasing is hard to describe > (TBAA _is_ a complex part of the standard), -fno-strict-aliasing > rules are simple. All loads and stores alias each other if they > cannot be proven not to alias by points-to analysis. Yes, the rules are "simple", but are writte

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Richard Guenther wrote: On 1/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote: We do that with -fstrict-aliasing, which also changes language semantics. Well, yes, but not quite in the same way. Indeed it's rather hard to describe in what way it changes the language semantics but easier to descr

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 1/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > We do that with -fstrict-aliasing, which also changes language semantics. Well, yes, but not quite in the same way. Indeed it's rather hard to describe in what way it changes the language semantics but easier to describe the effect it has o

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> We do that with -fstrict-aliasing, which also changes language semantics. Well, yes, but not quite in the same way. Indeed it's rather hard to describe in what way it changes the language semantics but easier to describe the effect it has on optimization. I think -fwrapv is the other way aroun

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Richard Guenther wrote: We do that with -fstrict-aliasing, which also changes language semantics. -fstrict-aliasing is disabled for -O0 and -O1 and enabled for -O[23s]. Yes, and as others have said, this is a bad precedent, and should not be followed further. Inclusion of -fwrapv would be much

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 1/2/07, Robert Dewar <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: > On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote: specfp. > > I would support the proposal to enable -fwrapv for -O[01], but > not for -O2 as that is supposed to be "optimize for speed" and > as -O3 is not widely used

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Richard Kenner wrote: What about -fno-wrapv for the first? Actually I don't like this. Why? Because it seems weird to have a flag that you can turn on and off, but the default is neither on nor off.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Richard Kenner wrote: Then we have two switches: -fstandard which allows all optimizations (name can be changed, I don't care about the name) -fwrapv which changes the semantics to require wrapping in all cases (including loops) What about -fno-wrapv for the first? Possible .. my view was

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Then we have two switches: > > -fstandard > > which allows all optimizations (name can be changed, I > don't care about the name) > > -fwrapv > > which changes the semantics to require wrapping in > all cases (including loops) What about -fno-wrapv for the first?

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Richard Guenther wrote: On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote: specfp. I would support the proposal to enable -fwrapv for -O[01], but not for -O2 as that is supposed to be "optimize for speed" and as -O3 is not widely used to optimize for speed (in fact it may make code slower). I

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> | >|> for (i = 1; i < m; ++i) > | >|> { > | >|> if (i > 0) > | >|> bar (); > | >|> } > > I suspect part of Richard K.'s questions has been to determine, based > on data, what improvements we actually gain from doing that kind of > elimination predicated on undefined-ness o

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> I can do this. What I also will do is improve VRP to still fold comparisons > of the for a - 10 > 20 when it knows there is no overflow due to available > range information for a (it doesn't do that right now). I thought fold-const.c optimizes that right now and has been for a long time? If tha

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Gerald Pfeifer <[EMAIL PROTECTED]> writes: | On Tue, 2 Jan 2007, Gabriel Dos Reis wrote: | >|> for (i = 1; i < m; ++i) | >|> { | >|> if (i > 0) | >|> bar (); | >|> } | >| Of course, this is an example where either the programmer is doing | >| something very silly or else is expe

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 1/2/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: >> Richard Guenther added -fwrapv to the December 30 run of SPEC at >> >> and >>

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote: On Dec 31, 2006, at 19:13, Daniel Berlin wrote: > Note the distinct drop in performance across almost all the benchmarks > on Dec 30, including popular programs like bzip2 and gzip. Not so. To my eyes, the specint 2000 mean went UP by about 1% f

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On Tue, 2 Jan 2007, Gabriel Dos Reis wrote: >|> for (i = 1; i < m; ++i) >|> { >|> if (i > 0) >|> bar (); >|> } >| Of course, this is an example where either the programmer is doing >| something very silly or else is expecting overflow and depending on >| wrap semantics, so it

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[EMAIL PROTECTED] (Richard Kenner) writes: [...] | > for (i = 1; i < m; ++i) | > { | > if (i > 0) | > bar (); | > } | | Of course, this is an example where either the programmer is doing something | very silly or else is expecting overflow and depending on wrap semantics, so

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Mark Mitchell <[EMAIL PROTECTED]> writes: > > let's disable the assumption about signed overflow not wrapping for > > VRP, but leave it in place for loop analysis. On Mon, Jan 01, 2007 at 06:09:41PM -0800, Paul Eggert wrote: > As far as I know this will work for all the wrapv-assuming code that >

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> I don't think -frisky is a good name for that option. A better name > would be -fstrict. Or -pedantic? ;-) > 4) We permit an exception to occur if there is a signed overflow. If >we can prove that some expression causes signed overflow, we are >permitted to assume that that case will

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On Mon, 2007-01-01 at 22:21 -0500, Richard Kenner wrote: > > Of course, this is an example where either the programmer is doing > something > very silly or else is expecting overflow and depending on wrap > semantics. or it comes from inlining of something like get() which has bounds checking. -

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> VRP as currently written adjust limits out to "infinity" of an > appropriate sign for variables which are changed in loops. It then > assumes that the (signed) variable will not wrap past that point, > since that would constitute undefined signed overflow. But isn't that fine since OTHER code i

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Ian Lance Taylor wrote: I don't think -frisky is a good name for that option. A better name would be -fstrict. or perhaps -fstandard which says "my program is 100% compliant ISO C. please mr. compiler make any assumptions you like based on knowing this is the case. If my claim that I am 100%

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert <[EMAIL PROTECTED]> writes: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > Also, it does not make sense to me to lump together all potentially > > troublesome optimizations under a single name. > > As a compiler developer, you see the trees. But most users just see a > forest

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Here I'd like to demur, since I think it's useful to document > something that users can rely on. > > I'm not asking that we document every possible wrapv-assuming code > that happens to work. I'm only asking for enough so that users can > easily write code that tests for signed integer overflow

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[EMAIL PROTECTED] (Richard Kenner) writes: > The question that I'd like to understand the answer to is what kinds of > optimizations DO we get by having VRP optimized signed overflow. Is it just > the elimination of tests on overflow? If so, then it strikes me as > definitely wrong since those t

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Mark Mitchell <[EMAIL PROTECTED]> writes: > let's disable the assumption about signed overflow not wrapping for > VRP, but leave it in place for loop analysis. As far as I know this will work for all the wrapv-assuming code that we've found, so it should be an improvement. Thanks to all for help

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Richard Kenner wrote: >> Where there are reasonable positions on both sides, nobody ever >> accurately predicts what the majority of a hugely diverse population >> of language users is going to want, and almost everyone believes >> they are in that majority. > > I agree. That's why I support a m

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> No offense, but all enabling wrapv at O2 or less would do is cause > more bug reports about > 1. Getting different program behavior between O2 and O3 > 2. Missed optimizations at O2 > It also doesn't fit with what we have chosen to differentiate > optimization levels based on. > > IMHO, it's jus

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Daniel Berlin wrote: >> Richard Guenther added -fwrapv to the December 30 run of SPEC at >> >> and >> . >> Daniel Berlin and Geert Bosch disagreed about how

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 1/1/07, Paul Eggert <[EMAIL PROTECTED]> wrote: Mark Mitchell <[EMAIL PROTECTED]> writes: > * Dan Berlin says that xlc assumes signed overflow never occurs, gets > much better performance as a result, and that nobody has complained. Most likely xlc and icc have been used to compile the gnulib

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Bruce Korb <[EMAIL PROTECTED]> writes: > > 2) Add an option like -fstrict-signed-overflow which controls those > >cases which appear to be risky. Turn on that option at -O2. > > Not a good plan. -O2 should be constrained to disrupting very few > applications. (e.g. loop unrolling seems unl

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Bruce Korb <[EMAIL PROTECTED]> writes: > WRT strict aliasing, I've never seen any data that indicated that the > language change was compelling. Consequently, as best I can tell it > was a marginal optimization improvement. So, I doubt its value. > Still, it should have had compiler warnings in

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[EMAIL PROTECTED] (Richard Kenner) writes: >> More important, we don't yet have an easy way to characterize the >> cases where (2) would apply. For (2), we need a simple, documented >> rule that programmers can easily understand, so that they can easily >> verify that C code is safe > > I'm not s

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Mark Mitchell <[EMAIL PROTECTED]> writes: > * Dan Berlin says that xlc assumes signed overflow never occurs, gets > much better performance as a result, and that nobody has complained. Most likely xlc and icc have been used to compile the gnulib mktime-checking code many times without incident (t

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Richard Kenner wrote: > > I'm not sure what you mean: there's the C standard. > We have many standards, starting with K&Rv1 through the current draft. > Which do you call, "the C standard"? The current one. All others are "previous C standards". However, it doesn't matter in this case since ALL

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Changing syntax and semantics should not be impossible (it's being done), What change? There has never been a version of the C language, all the way from K&Rv1 to the present, that defined signed overflow. The problem is the previous compilers never took advantage of the permission to make it

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> I don't agree with this point. There is a substantial number of > application developers who would prefer -failsafe. There is a > substantial number who would prefer -frisky. We don't know which set > is larger. We get a lot of bug reports about missed optimizations. six vs. half a dozen.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Daniel Berlin wrote: > Sorry, but it's rather impossible to argue against someone who seems > to believe users should not be responsible and held responsible for > knowing the rules of the language they are programming in. Down this > path, madness lies. > "strict aliasing" is really just "what th

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On Mon, Jan 01, 2007 at 07:33:06AM -0500, Richard Kenner wrote: > > the seemingly prevalent attitude "but it is undefined; but it is not > > C" is the opinion of the majority of middle-end maintainers. > > Does anybody DISAGREE with that "attitude"? It isn't valid C to assume that > signed overfl

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On Mon, Jan 01, 2007 at 10:24:36AM -0800, Andrew Pinski wrote: > Then the question is why does C developers act differently than Fortran > developers when it comes to undefinedness? In the case of int overflow wrapping, I think it's because the Bell Labs folks appeared to assume wrapping semantics

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> More important, we don't yet have an easy way to characterize the > cases where (2) would apply. For (2), we need a simple, documented > rule that programmers can easily understand, so that they can easily > verify that C code is safe I'm not sure what you mean: there's the C standard. That sa

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Andrew Pinski wrote: Look at Fortran argument aliasing, we get almost no bugs about that undefinedness. We have an option to change the way argument aliasing works, in the same way we have an option for signed overflow. I don't see why overflow will be any different from argument aliasing. W

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On Mon, 2007-01-01 at 10:00 -0800, Paul Eggert wrote: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > Also, it does not make sense to me to lump together all potentially > > troublesome optimizations under a single name. > > As a compiler developer, you see the trees. But most users just se

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Ian Lance Taylor <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > I do hope your and Richard G's constructive search for middle ground | > will find echoes within the middle-end maintainers. | | This seems likely, since Richard and I are two of the three middle-en

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > Also, it does not make sense to me to lump together all potentially > troublesome optimizations under a single name. As a compiler developer, you see the trees. But most users just see a forest and want things to be simple. Even adding a single bin

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Still, in practical terms, it is true that overflow > being undefined is unpleasant. In Ada terms, it would > have seemed better in the C standard to reign in the > effect of overflow, for instance, merely saying that > the result is an implementation defined value of the > type, or the program i

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> Ian Lance Taylor wrote: > ... > I don't personally see that as the question. This code is > undefined, and, therefore, is in some sense not C. If we take > any other attitude, then we will be defining and supporting > a different language. I think that relatively few people want > the language

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Geert Bosch wrote: As undefined execution can result in arbitrary badness, this is really at odds with the increasing need for many programs to be secure. Since it is almost impossible to prove that programs do not have signed integer overflow, That seems a bit pessimistic, given the work Prax

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On Jan 1, 2007, at 12:16, Joseph S. Myers wrote: For a program to be secure in the face of overflow, it will generally need explicit checks for overflow, and so -fwrapv will only help if such checks have been written under the presumption of -fwrapv semantics. Yes, but often people do writ

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On Mon, 1 Jan 2007, Geert Bosch wrote: > As undefined execution can result in arbitrary badness, > this is really at odds with the increasing need for many > programs to be secure. Since it is almost impossible to > prove that programs do not have signed integer overflow, > it makes far more sense

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert <[EMAIL PROTECTED]> writes: > Ralf Wildenhues suggested bugzilla originally, but Andrew Pinski > responded that the > problem "has been observed many, many times and talked about a lot of > time on this list" and implied strongly that t

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On Dec 31, 2006, at 19:13, Daniel Berlin wrote: Note the distinct drop in performance across almost all the benchmarks on Dec 30, including popular programs like bzip2 and gzip. Not so. To my eyes, the specint 2000 mean went UP by about 1% for the base -O3 compilation. The peak enabled more un

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > I do hope your and Richard G's constructive search for middle ground > will find echoes within the middle-end maintainers. This seems likely, since Richard and I are two of the three middle-end maintainers, and I don't recall hearing from the other o

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Richard Kenner wrote: the seemingly prevalent attitude "but it is undefined; but it is not C" is the opinion of the majority of middle-end maintainers. Does anybody DISAGREE with that "attitude"? It isn't valid C to assume that signed overflow wraps. I've heard nobody argue that it is. The q

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 1/1/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > the seemingly prevalent attitude "but it is undefined; but it is not > C" is the opinion of the majority of middle-end maintainers. Does anybody DISAGREE with that "attitude"? It isn't valid C to assume that signed overflow wraps. I've hea

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> the seemingly prevalent attitude "but it is undefined; but it is not > C" is the opinion of the majority of middle-end maintainers. Does anybody DISAGREE with that "attitude"? It isn't valid C to assume that signed overflow wraps. I've heard nobody argue that it is. The question is how far we

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 12/31/06, Richard Kenner <[EMAIL PROTECTED]> wrote: > Are you volunteering to audit the present cases and argue whether they > fall in the "traditional" cases? I'm certainly willing to *help*, but I'm sure there will be some cases that will require discussion to get a consensus. > Note that

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > I'm not entirely happy with what I take to be stampeding it by > introducing what I believe would be a completely inappropriate patch > to autoconf, rather than, say, opening a gcc bugzilla problem report > for the cases you feel gcc should handle dif

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Ian Lance Taylor <[EMAIL PROTECTED]> writes: [...] | I believe the best option is | going to be to take an case by case approach to selecting which | optimizations should be enabled by default, and which optimizations | should not be done except via a special

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Bernd Schmidt <[EMAIL PROTECTED]> writes: > Paul Eggert wrote: >> But so far, benchmark scores are the only scores given by the people >> who oppose having -O2 imply -fwrapv. > > And you expect real-world results will be different because...? Because of the (admittedly limited) real-world measure

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[EMAIL PROTECTED] (Richard Kenner) writes: > > But didn't this thread get started by a real program that was broken > > by an optimization of loop invariants? Certainly I got a real bug > > report of a real problem, which you can see here: > > > > http://lists.gnu.org/archive/html/bug-gnulib/200

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Daniel Berlin wrote: > I generally have no problem with turning on -fwrapv at O2, but i'm > curious where this ends. > After all, strict aliasing makes it hard to write a bunch of styles of > code people really want to write, and breaks real world programs and > GNU software. > > Yet we decided t

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> But didn't this thread get started by a real program that was broken > by an optimization of loop invariants? Certainly I got a real bug > report of a real problem, which you can see here: > > http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00084.html I just thought of something intere

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert <[EMAIL PROTECTED]> writes: > Robert Dewar <[EMAIL PROTECTED]> writes: > > > We have not seen ONE imaginary example, let > > alone a real example, where the optimziation of loop invariants > > (by far the most important optimization in the class we are > > discussing) would break exis

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> > But how would that happen here? If we constant-fold something that would > > have overflowed by wrapping, we are ELIMINATING a signed overflow, not > > INTRODUCING one. Or do I misunderstand what folding we're talking about > > here? > > http://gcc.gnu.org/PR27116 is what led to the patch.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert <[EMAIL PROTECTED]> writes: > "Daniel Berlin" <[EMAIL PROTECTED]> writes: > > >> http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html > >> and > >> http://www.suse.de/~gcctest/SPEC/CINT/sb-vangelis-head-64/recent.html > >> > > Note the distinct drop in performance acro

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[EMAIL PROTECTED] (Richard Kenner) writes: > > > > Note that -fwrapv also _enables_ some transformations on signed > > > > integers that are disabled otherwise. We for example constant fold > > > > -CST for -fwrapv while we do not if signed overflow is undefined. > > > > Would you change those? >

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> > > Note that -fwrapv also _enables_ some transformations on signed > > > integers that are disabled otherwise. We for example constant fold > > > -CST for -fwrapv while we do not if signed overflow is undefined. > > > Would you change those? > > > > I don't understand the rationale for not wra

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> http://gcc.gnu.org/ml/gcc/2006-12/msg00607.html > > If this doesn't count as "optimization of loop invariants" > then what would count? One where the induction variable was updated additively, not multiplicatively. When we talk about normal loop optimizations, that's what we mean. I agree tha

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 12/31/06, Daniel Berlin <[EMAIL PROTECTED]> wrote: ... > I added -fwrapv to the Dec30 run of SPEC at > http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html > and > http://www.suse.de/~gcctest/SPEC/CINT/sb-vangelis-head-64/recent.html Note the distinct drop in performance acros

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

> This isn't just about old code. If you're saying that old code with > overflow checking can't be fixed (in a portable manner...), then new > code will probably use the same tricks. I said there's no "good" way, meaning as compact as the current tests. But it's certainly easy to test for overfl

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[EMAIL PROTECTED] (Richard Kenner) writes: > > Note that -fwrapv also _enables_ some transformations on signed > > integers that are disabled otherwise. We for example constant fold > > -CST for -fwrapv while we do not if signed overflow is undefined. > > Would you change those? > > I don't unde

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Robert Dewar <[EMAIL PROTECTED]> writes: > We have not seen ONE imaginary example, let > alone a real example, where the optimziation of loop invariants > (by far the most important optimization in the class we are > discussing) would break existing code. But didn't this thread get started by a r

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

"Daniel Berlin" <[EMAIL PROTECTED]> writes: >> http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html >> and >> http://www.suse.de/~gcctest/SPEC/CINT/sb-vangelis-head-64/recent.html >> > Note the distinct drop in performance across almost all the benchmarks > on Dec 30, including pop

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 11:37:21 -0500, Richard Kenner wrote: > Certainly. Indeed I think that's the whole point of this thread: that if > you want to catch ALL potential optimizations opportunities given to you > by the standard, you must assume that signed overflows are undefined. > > However, what's bei

  1   2   3   4   >