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: Link tests not allowed

On Mon, Jan 01, 2007 at 07:32:51PM -0800, Jim Wilson wrote: > This is the wrong part of the config.log fragment. The interesting part > is nearer the top, immediately after the command using the -V option. > The use of -V probably fails which is OK as this is only for information > purposes, but t

Re: Link tests not allowed

On Mon, 2007-01-01 at 18:19 -0800, Douglas B Rupp wrote: > Would you like the complete config.log by private email? Sure. > config.log fragment This is the wrong part of the config.log fragment. The interesting part is nearer the top, immediately after the command using the -V option. The use o

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: Link tests not allowed

On Mon, Jan 01, 2007 at 06:19:08PM -0800, Douglas B Rupp wrote: > configure:4811: /home/rupp/ngnat/buildxppcaix/./gcc/xgcc > -B/home/rupp/ngnat/buildxppcaix/./gcc/ > -B/home/rupp/gnat/powerpc-ibm-aix5.2.0.0/bin/ > -B/home/rupp/gnat/powerpc-ibm-aix5.2.0.0/lib/ -isystem > /home/rupp/gnat/powerpc-

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: Link tests not allowed

Jim Wilson wrote: Douglas B Rupp wrote: I'm happy to try writing a patch, but my version of gcc/configure doesn't look like what you described. I tried a build with the gcc-4.1.x branch, and gcc/nm is computed correctly, so the problem I described on mainline does not exist here. Unfortunate

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: Link tests not allowed

Douglas B Rupp wrote: I'm happy to try writing a patch, but my version of gcc/configure doesn't look like what you described. I tried a build with the gcc-4.1.x branch, and gcc/nm is computed correctly, so the problem I described on mainline does not exist here. Unfortunately, I wasn't able t

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

gfortran year end status report

Gfortran has achieved many milestones this year and hopefully the contributors can continue to move forward with bug fixes, conformance to Fortran 95 standard, and the implementation of Fortran 2003 features. A few highlights from the past year are: 1) Jakub Jelinek committed the front end suppo

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: GCC optimizes integer overflow: bug or feature?

> Currently our documentation on -fwrapv is rather short and does not > provide examples or anything to provide such a feel: > > This option instructs the compiler to assume that signed arithmetic > overflow of addition, subtraction and multiplication wraps around > using twos-complement re

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: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

Hi, I've commited the following patch that fixes the obvious problem of calling emit_insn_1 for INSN_LIST argument. It seems to solve the problems I can reproduce and it bootstraps x86_64-linux/i686-linux and Darwin (thanks to andreast). The patch was preaproved by Ian. This is meant as fast fix

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: GCC optimizes integer overflow: bug or feature?

On Tue, 19 Dec 2006, Ian Lance Taylor wrote: > Here is a quick list of optimizations that mainline gcc performs which > rely on the idea that signed overflow is undefined. All the types > are, of course, signed. I made have made some mistakes. I think this > gives a good feel for the sorts of op

Re: [PATCH] Relocated compiler should not look in $prefix.

On Tue, 12 Dec 2006, Mark Mitchell wrote: > If you want to make a patch, and Gerald approves it, it's fine by me. > But, fwprop is described as a new feature (faster compiler, better > code), and the build system affects people building the compiler. The > change we're talking about seems to affec

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: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

I've bootstrapped OK C/C++/Fortran on PPC. make check-gcc is running now Thanks, Vladimir On 1/1/07, Jan Hubicka <[EMAIL PROTECTED]> wrote: > Hi, > Sorry for possibly causing confusion. I had tested the patch on my ICE > testcase and bootstrapped for -enable-languages=C, but didn't run the > fu

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: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

> Hi, > Sorry for possibly causing confusion. I had tested the patch on my ICE > testcase and bootstrapped for -enable-languages=C, but didn't run the > full bootstrap. Bootstrapping the latest Andrew's patch on ppc-linux > and testing it on SPU. Vladimir, I bootstrapped/regtested the patch myself

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