[Bug middle-end/40981] aermod.f90 ICEs on -O2 -fgraphite-identity -floop-strip-mine

--- Comment #27 from spop at gcc dot gnu dot org 2009-08-15 07:10 --- Subject: Bug 40981 Author: spop Date: Sat Aug 15 07:10:20 2009 New Revision: 150789 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150789 Log: Correct the use of ppl_Pointset_Powerset_C_Polyhedron_maximize. 2

[Bug target/41076] New: [avr] pessimal code for logical OR of 8-bit fields

This trivial function: unsigned short f(unsigned char a, unsigned char b) { return a | (b << 8); } generates the code: f: /* prologue: function */ /* frame size = 0 */ mov r21,r22 ldi r20,lo8(0) mov r18,r24 ldi r19,lo8(0) or r18,r20 or r19,r21

[Bug fortran/31593] Invariant DO loop variables and subroutines

--- Comment #27 from jv244 at cam dot ac dot uk 2009-08-15 07:50 --- (In reply to comment #26) > If it weren't for the outermost loop it would actually be perfectly legal to > modify 'value' inside the loops. If there were a way of telling the compiler > "this pointer can't escape" this

[Bug fortran/31593] Invariant DO loop variables and subroutines

--- Comment #28 from jv244 at cam dot ac dot uk 2009-08-15 07:53 --- (In reply to comment #23) > subroutine output(i1,i2,i3,i4,i5) > print '(5(I0,:" "))',i1,i2,i3,i4,i5 > end subroutine output [..] > if (p1 * p2 * p3 * p4 == value * 100) &

[Bug target/41077] New: [avr] excessive prologue/epilogue for interrupt handler

This function: void __vector_7 (void) __attribute__ ((signal,used, externally_visible)) ; void __vector_7 (void) { timerCounter++; (*(volatile uint8_t *)(0x89)) = 0; (*(volatile uint8_t *)(0x88)) = 0; (*(volatile uint8_t *)(0x7C)) = 0; } yields the code: __vector_7: push __zero_re

[Bug fortran/31593] Invariant DO loop variables and subroutines

--- Comment #29 from tkoenig at gcc dot gnu dot org 2009-08-15 09:22 --- Subject: Re: Invariant DO loop variables and subroutines On Sat, 2009-08-15 at 07:53 +, jv244 at cam dot ac dot uk wrote: > > --- Comment #28 from jv244 at cam dot ac dot uk 2009-08-15 07:53 --- > (

[Bug fortran/31593] Invariant DO loop variables and subroutines

--- Comment #30 from tkoenig at gcc dot gnu dot org 2009-08-15 09:25 --- Subject: Re: Invariant DO loop variables and subroutines On Fri, 2009-08-14 at 22:58 +, tobi at gcc dot gnu dot org wrote: > > --- Comment #26 from tobi at gcc dot gnu dot org 2009-08-14 22:58 --- >

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

--- Comment #8 from rguenth at gcc dot gnu dot org 2009-08-15 09:42 --- Subject: Bug 41069 Author: rguenth Date: Sat Aug 15 09:42:28 2009 New Revision: 150791 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150791 Log: 2009-08-15 Richard Guenther PR lto/41069

[Bug fortran/31593] Invariant DO loop variables and subroutines

--- Comment #31 from tobi at gcc dot gnu dot org 2009-08-15 09:51 --- (In reply to comment #30) > Escaping pointers for non-target dummy arguments can't happen in > Fortran, can they? Could we just disable this (or ad a > TREE_CANNOT_ALIAS flag to the middle end, which is on by default

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

--- Comment #9 from rguenth at gcc dot gnu dot org 2009-08-15 09:52 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug target/41076] [avr] pessimal code for logical OR of 8-bit fields

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-15 09:55 --- because this is what C says you are doing: return (unsigned short) ((int) a | ((int) b << 8)); which is harder to transform back into what you expect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41076

[Bug fortran/31593] Invariant DO loop variables and subroutines

--- Comment #32 from jv244 at cam dot ac dot uk 2009-08-15 10:05 --- (In reply to comment #29) > It's the other way around: If output were to modify any of its > arguments, the program would be illegal. Therefore, the compiler can > assume that this doesn't happen. Intent(in) would b

[Bug fortran/31593] Invariant DO loop variables and subroutines

--- Comment #33 from =?ISO-8859-1?Q?Tobias_Schl=FCter?= 2009-08-15 10:17 --- Subject: Re: Invariant DO loop variables and subroutines jv244 at cam dot ac dot uk wrote: > --- Comment #32 from jv244 at cam dot ac dot uk 2009-08-15 10:05 --- > (In reply to comment #29) > >> I

[Bug fortran/31593] Invariant DO loop variables and subroutines

--- Comment #34 from tkoenig at gcc dot gnu dot org 2009-08-15 10:57 --- (In reply to comment #33) > Actually, we're buggy there, and my patch fixes it. I'm just now trying > out testcases. Are we really buggy? $ cat gaga.f90 n=10 do i=1,n call foo(n) print *,i end do end subrouti

[Bug fortran/31593] Invariant DO loop variables and subroutines

--- Comment #35 from =?ISO-8859-1?Q?Tobias_Schl=FCter?= 2009-08-15 10:58 --- Subject: Re: Invariant DO loop variables and subroutines tkoenig at gcc dot gnu dot org wrote: > --- Comment #34 from tkoenig at gcc dot gnu dot org 2009-08-15 10:57 > --- > (In reply to comment #

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

--- Comment #10 from jv244 at cam dot ac dot uk 2009-08-15 12:12 --- great... with this fix CP2K can be compiled and linked at -flto -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41069

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

--- Comment #11 from rguenther at suse dot de 2009-08-15 12:14 --- Subject: Re: lto1: error: type mismatch in indirect reference On Sat, 15 Aug 2009, jv244 at cam dot ac dot uk wrote: > --- Comment #10 from jv244 at cam dot ac dot uk 2009-08-15 12:12 --- > great... with this

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

--- Comment #12 from jv244 at cam dot ac dot uk 2009-08-15 12:25 --- (In reply to comment #11) > You definitely want to add -fwhole-program for extra optimization and > a less overall program size. there are still the two issues I reported in PR40011 with -fwhole-file.. hmm actually

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

--- Comment #13 from rguenther at suse dot de 2009-08-15 12:28 --- Subject: Re: lto1: error: type mismatch in indirect reference On Sat, 15 Aug 2009, jv244 at cam dot ac dot uk wrote: > > > --- Comment #12 from jv244 at cam dot ac dot uk 2009-08-15 12:25 --- > (In reply to

[Bug debug/37801] DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine

--- Comment #7 from dodji at gcc dot gnu dot org 2009-08-15 15:38 --- Patch posted to http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00813.html . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37801

[Bug bootstrap/41078] New: [4.5 Regression] Build failure with --enable-maintainer-mode

This is with revision 150791. See http://gcc.gnu.org/ml/gcc/2009-08/msg00257.html $ ../../gcc/trunk/configure --prefix=$HOME --enable-languages=c,fortran --enable-maintainer-mode && make && make install ... make[3]: Leaving directory `/var/work/gcc-bin/trunk/libdecnumber' make[3]: Entering dire

[Bug bootstrap/41078] [4.5 Regression] Build failure with --enable-maintainer-mode

-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Target Milestone|--- |4.5.0 http

[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template

--- Comment #11 from cppljevans at suddenlink dot net 2009-08-15 15:44 --- Created an attachment (id=18371) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18371&action=view) test case for gcc/testsuite/g++.dg/cpp0x with gcc-4.5 compile This is even a "more minimal" test case. Th

[Bug lto/41079] New: Bootstrap comparison fails, executables contain .gnu.lto_* sections

Likely because .gnu.lto_* sections remain in the final executables (like for example cc1-dummy) bootstrap with BOOT_CFLAGS="-O2 -flto -g" BOOT_LDFLAGS="-flto" currently fails at comparing stage2 and stage3. Comparing stage2 and stage3 cc1-dummy readelf -S output reveals: --- a 2009-08-15 17:25:

[Bug fortran/41080] New: gfortran -dumpversion does not behave like gcc or g++

The 'dumpversion' option of gcc and g++ show just the version number, which is useful. The same is not true of gfortran, which shows a lot of other information, making getting the version more difficult drkir...@smudge:[~] $ g++ -dumpversion 4.4.1 drkir...@smudge:[~] $ gcc -dumpversion 4.4.1 drki

[Bug libstdc++/41061] Compile of program using std random fails.

--- Comment #9 from 3dw4rd at verizon dot net 2009-08-15 16:04 --- Subject: Re: Compile of program using std random fails. paolo dot carlini at oracle dot com wrote: > --- Comment #7 from paolo dot carlini at oracle dot com 2009-08-14 23:34 > --- > Fixed. > > > Paolo, Tha

[Bug bootstrap/41078] [4.5 Regression] Build failure with --enable-maintainer-mode

--- Comment #1 from tkoenig at gcc dot gnu dot org 2009-08-15 16:05 --- Caused by wrong version of aclocal, sorry for the noise. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug libstdc++/41061] Compile of program using std random fails.

--- Comment #10 from paolo dot carlini at oracle dot com 2009-08-15 16:27 --- You are welcome. By the way, Walter Brown told me in private email that is working on the "de-conceptified" specifications, let's see what happens of those comparison operators... -- http://gcc.gnu.org/bu

[Bug middle-end/40981] aermod.f90 ICEs on -O2 -fgraphite-identity -floop-strip-mine

--- Comment #28 from howarth at nitro dot med dot uc dot edu 2009-08-15 16:44 --- Fixed on x86_64-apple-darwin10 with current gcc trunk. Thanks. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added --

[Bug libstdc++/41061] Compile of program using std random fails.

--- Comment #11 from 3dw4rd at verizon dot net 2009-08-15 17:29 --- Subject: Re: Compile of program using std random fails. paolo dot carlini at oracle dot com wrote: > --- Comment #10 from paolo dot carlini at oracle dot com 2009-08-15 > 16:27 --- > You are welcome. By the w

[Bug libstdc++/41061] Compile of program using std random fails.

--- Comment #12 from paolo dot carlini at oracle dot com 2009-08-15 17:41 --- (In reply to comment #11) > I agree we'll wait and see. I think he'll need comparison operators. > You could compare the contents of param_type because all the bits are > available as calls. But you'll st

[Bug fortran/41080] gfortran -dumpversion does not behave like gcc or g++

--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-15 18:14 --- Trivial patch: Index: gcc/fortran/gfortranspec.c === --- gcc/fortran/gfortranspec.c (Revision 150791) +++ gcc/fortran/gfortranspec.c (Arbeitskopie) @@

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

--- Comment #14 from jv244 at cam dot ac dot uk 2009-08-15 18:46 --- (In reply to comment #13) > > -flto needs about 35min compile time and 10.5Gb RAM. > > Doh. How does that compare to the all-CP2K in one file builds? an all-in-one-file-CP2K takes about 2.5Gb and 30min last time I te

[Bug fortran/41080] gfortran -dumpversion does not behave like gcc or g++

--- Comment #2 from david dot kirkby at onetel dot net 2009-08-15 20:10 --- Thank you. Does this mean the next version of gcc will support this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41080

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

--- Comment #15 from rguenther at suse dot de 2009-08-15 20:18 --- Subject: Re: lto1: error: type mismatch in indirect reference On Sat, 15 Aug 2009, jv244 at cam dot ac dot uk wrote: > --- Comment #14 from jv244 at cam dot ac dot uk 2009-08-15 18:46 --- > (In reply to comme

[Bug fortran/41080] gfortran -dumpversion does not behave like gcc or g++

--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-15 20:52 --- Subject: Bug 41080 Author: burnus Date: Sat Aug 15 20:51:55 2009 New Revision: 150792 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150792 Log: 2009-08-15 Tobias Burnus PR fortran/41080 *

[Bug fortran/41080] gfortran -dumpversion does not behave like gcc or g++

--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-15 20:57 --- (In reply to comment #2) > Thank you. Does this mean the next version of gcc will support this? Now yes - I have just committed it to the trunk, i.e. the 4.5.0 release will have it (as will have the nightly trunk bu

[Bug c/39959] [4.5 Regression] IMA is broken

--- Comment #8 from hp at gcc dot gnu dot org 2009-08-16 00:16 --- (In reply to comment #7) > It was fixed between revision revision 150368 and revision 150371. For the record, "covered up" rather than "fixed" according to . Rich

[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

--- Comment #17 from hp at gcc dot gnu dot org 2009-08-16 00:31 --- For the record, the gfortran.dg/forall_1.f90 regression has been covered since r150588. (And I'm still on the hook to address the concerns with the posted patch.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4008

[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0

--- Comment #3 from ami_stuff at o2 dot pl 2009-08-16 01:28 --- This slowdown is because of libz. When I use minigzip from libz package to compress data, I get the same slowdown with GCC 4.4.1. Maybe someone will try to fix it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454

[Bug target/41081] New: redundant ZERO_EXTENDs

Linux kernel block sha1 code on powerpc64 has many redundant clrldi instructions, significantly slowing execution time. Current gcc seems to generate more of these than 3.4.5 which is in turn worse than 3.3. Breakdown of clrldi insns - 140 redundant clrldi on rotate insn output - 79 other redunda

[Bug target/41081] redundant ZERO_EXTENDs

--- Comment #1 from amodra at bigpond dot net dot au 2009-08-16 02:41 --- Created an attachment (id=18372) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18372&action=view) block sha1 source blk_SHA1Block takes all its input from unsigned ints and only writes to unsigned ints, thu

[Bug target/41081] redundant ZERO_EXTENDs

--- Comment #2 from amodra at bigpond dot net dot au 2009-08-16 02:45 --- Created an attachment (id=18373) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18373&action=view) Cure the zero_extends on rotate output This patch teaches gcc that the powerpc rotate/shift unit appropriate

[Bug target/41081] redundant ZERO_EXTENDs

--- Comment #3 from amodra at bigpond dot net dot au 2009-08-16 03:05 --- Created an attachment (id=18374) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18374&action=view) aims to teach gcc that rotate/shift insn input register's high bits are ignored This patch is aimed at the "

[Bug target/41081] redundant ZERO_EXTENDs

--- Comment #4 from amodra at bigpond dot net dot au 2009-08-16 03:07 --- Please ignore the RS6000_ALT_REG_ALLOC_ORDER hunk in rs6000-2.diff. I forgot to edit that out.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41081