Re: [mem-ssa] Updated documentation

Hi Diego, In the example of dynamic partitioning below (Figure 6), I don't understand why MEM7 is not killed in line 13 and is killed in line 20 later. As far as I understand, in line 13 'c' is in the alias set, and it's currdef is MEM7, so it must be killed by the store in line 14. What am I mis

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: gfortran year end status report

Thanks a lot Steve for taking time to prepare and write this mail. FX

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: gfortran year end status report

FX Coudert wrote: Thanks a lot Steve for taking time to prepare and write this mail. FX I second that - the only axe that I have to grind about it is that the majority of my commits were patches to patches of the same fix :-) Paul

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 ..."

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

The testing of the committed patch on the PPC-linux has produced no regressions relatively to the state that was before the bootstrap break-up. The same holds for the Andrew's version of the patch. 21 testsuite failures on PPC-linux that were introduced together with the bootstrap problem has disa

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 ..."

> | >|> 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 ..."

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 ..."

> 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 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 ..."

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 ..."

> 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 ..."

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 ..."

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 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 ..."

> 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 ..."

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 ..."

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 ..."

> 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 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

[ecj] Fix ArrayStore testsuite failure

Fixes almost the last gcj test failure on the branch. Andrew. 2007-01-02 Andrew Haley <[EMAIL PROTECTED]> * expr.c (expand_java_arraystore): Make sure we perform a bounds check at runtime before we perform a type check. Index: expr.c ==

gcc-4.2-20070102 is now available

Snapshot gcc-4.2-20070102 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070102/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

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 ..."

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

-pg problem

hello, can someone help me understand what is going on? are the -p and -pg options supposed to work? # gcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandi

Re: -pg problem

Adam Sulmicki <[EMAIL PROTECTED]> writes: > can someone help me understand what is going on? > > are the -p and -pg options supposed to work? This question is not appropriate for gcc@gcc.gnu.org, which is a mailing list for gcc developments. It is appropriate for [EMAIL PROTEC

Re: -pg problem

On Tue, 2 Jan 2007, Ian Lance Taylor wrote: Adam Sulmicki <[EMAIL PROTECTED]> writes: can someone help me understand what is going on? are the -p and -pg options supposed to work? This question is not appropriate for gcc@gcc.gnu.org, which is a mailing list for gcc develop

Re: -pg problem

can someone help me understand what is going on? are the -p and -pg options supposed to work? This question is not appropriate for gcc@gcc.gnu.org, which is a mailing list for gcc developments. It is appropriate for [EMAIL PROTECTED] I apologize for this. -p does work on

Re: identifing free() in tree-ssa

On Tue, Jan 02, 2007 at 02:30:45PM -0700, Roger Sayle wrote: > > I think recognizing "free" as a built-in (without an intrinsic) is the > correct way to go. In theory, all of the functions listed in > cp/cfns.gperf should be defined via builtins.def, but unfortunately > the compile-time (and memo

Retiring IPA-branch

Hi, thanks to Diego, Andrew (MacLeod), Daniel and Roger's effort on reviewing IPA branch merge patches, I hope to commit after re-testing the patch to enable IPA-SSA today. This means that the main part of IPA-branch has been merged. There are still features on IPA branch that I hope to follow sho

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

[autovect] autovect-branch reopened from latest trunk

I've reopened a new branch autovect-branch, taken off the trunk as of today. The branchpoint revision is 120362. The old branch went way out of synch with mainline so I've moved it to branches/dead/old-autovect-branch in svn repository. New autovect-branch has initialized merge tracking support

Re: running bprob.exp tests in a cross-testing environment

Ben Elliston <[EMAIL PROTECTED]> writes: > I see a couple of solutions, but would like to discuss them here before > working on a patch: > > 1. have the bprob.exp test driver create the appropriate directory >tree on the target (and remove it when finished); or > > 2. set GCOV_PREFIX when runni

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 ..."

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

Autoconf manual's coverage of signed integer overflow & portability

Today I updated the Autoconf manual to contain the following description of the current situation with signed integer overflow. This section of the manual is intended to advise programmers what to do about portable C programs in this area. I think some discussion along these lines also belongs in

Re: Autoconf manual's coverage of signed integer overflow & portability

A few comments: > Many portable C programs assume that signed integer overflow wraps around > reliably using two's complement arithmetic. I'd replace "portable C programs" with "widely-used C programs". The normal use of "portable" means that it conforms to the standard. > Conversely, in at lea

Re: Autoconf manual's coverage of signed integer overflow & portability

> > Today I updated the Autoconf manual to contain the following > description of the current situation with signed integer overflow. > This section of the manual is intended to advise programmers what to > do about portable C programs in this area. > > I think some discussion along these lines a

Re: Autoconf manual's coverage of signed integer overflow & portability

[EMAIL PROTECTED] (Richard Kenner) writes: > A few comments: Thanks for the quick review. >> Many portable C programs assume that signed integer overflow wraps around >> reliably using two's complement arithmetic. > > I'd replace "portable C programs" with "widely-used C programs". The normal >

Re: Autoconf manual's coverage of signed integer overflow & portability

Richard Kenner wrote: A few comments: Many portable C programs assume that signed integer overflow wraps around reliably using two's complement arithmetic. I'd replace "portable C programs" with "widely-used C programs". The normal use of "portable" means that it conforms to the standard.

Re: Autoconf manual's coverage of signed integer overflow & portability

> > Wrap-around is very useful for digital signal processing. Saturation is also very useful for DSPs. This is why for embedded C[1], they are adding types which the user is able to decide which behavior they want instead of just being undefined. Let me make the point that signed overflow has

Re: Autoconf manual's coverage of signed integer overflow & portability

> >> Many portable C programs assume that signed integer overflow wraps around > >> reliably using two's complement arithmetic. > > > > I was looking for an adjective that mean the programs work on a wide > variety of platforms, and "portable" seems more appropriate than > "widely-used". Maybe jus

Re: Autoconf manual's coverage of signed integer overflow & portability

Richard Kenner wrote: A few comments: Many portable C programs assume that signed integer overflow wraps around reliably using two's complement arithmetic. I'd replace "portable C programs" with "widely-used C programs". The normal use of "portable" means that it conforms to the standard.

Re: Autoconf manual's coverage of signed integer overflow & portability

Andrew Pinski <[EMAIL PROTECTED]> writes: > Let me make the point that signed overflow has been undefined since > before the C standard was finialized and in fact there is a nice > paper/book called "C Traps and Pitfalls[2]" which mentions all of this > back in 1988. C Traps and Pitfalls, like K&

Re: Autoconf manual's coverage of signed integer overflow & portability

[EMAIL PROTECTED] (Richard Kenner) writes: >> >> Many portable C programs assume that signed integer overflow wraps around >> >> reliably using two's complement arithmetic. >> > >> >> I was looking for an adjective that mean the programs work on a wide >> variety of platforms, and "portable" seems

Re: Autoconf manual's coverage of signed integer overflow & portability

Paul Eggert wrote: Andrew Pinski <[EMAIL PROTECTED]> writes: Let me make the point that signed overflow has been undefined since before the C standard was finialized and in fact there is a nice paper/book called "C Traps and Pitfalls[2]" which mentions all of this back in 1988. C Traps and Pi

Re: [autovect] autovect-branch reopened from latest trunk

> > I've reopened a new branch autovect-branch, taken off the trunk as of > today. > The branchpoint revision is 120362. The old branch went way out of synch > with mainline so I've moved it to branches/dead/old-autovect-branch in svn > repository. > > New autovect-branch has initialized merge tra

Re: Autoconf manual's coverage of signed integer overflow & portability

Here are further patches I checked into the Autoconf documentation to reflect today's comments (some of which I received privately). Thanks to all of you. The trickiest bit was documenting one simple way to reliably detect overflow without converting to unsigned and back. (At least, I hope it's r

Re: Autoconf manual's coverage of signed integer overflow & portability

> > [EMAIL PROTECTED] (Richard Kenner) writes: > > >> >> Many portable C programs assume that signed integer overflow wraps > >> >> around > >> >> reliably using two's complement arithmetic. > >> > > >> > >> I was looking for an adjective that mean the programs work on a wide > >> variety of pla

Re: Autoconf manual's coverage of signed integer overflow & portability

> > Here are further patches I checked into the Autoconf documentation to > reflect today's comments (some of which I received privately). Thanks > to all of you. The trickiest bit was documenting one simple way to > reliably detect overflow without converting to unsigned and back. > (At least,