[Bug middle-end/43307] ICE in assign_temp() with STRICT_ALIGNMENT set to true on x86_64

--- Comment #3 from pluto at agmk dot net 2010-03-13 06:53 --- (In reply to comment #2) > I think this is expected because on i?86, the alignment of the stack is only > required to be 32 bit aligned so obviously emit_push_insn is going to have > issues with stricted aligned TFmode pushe

[Bug objc++/43353] Objective-C++ @try{} block produces linker error

--- Comment #4 from dyob at lunaport dot net 2010-03-13 06:47 --- OK, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43353

[Bug middle-end/43354] function �pofun2' from xplor-nih ICEs compiler at -O2 -fgraphite-identity

--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-03-13 06:18 --- Test case doesn't ICE gfortran from current gcc 4-4 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43354

[Bug middle-end/43354] function �pofun2' from xplor-nih ICEs compiler at -O2 -fgraphite-identity

--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-03-13 05:40 --- Created an attachment (id=20099) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20099&action=view) reduced pofun2 subroutine that still produces the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi

[Bug middle-end/43354] New: function �pofun2' from xplor-nih ICEs compiler at -O2 -fgraphite-identity

The subroutine 'pofun2' in the pxparse.f file of xplor-nih 2.25 causes gcc trunk to ICE when compiling with -O2 -fgraphite. A reduced testcase for this subroutine produces the error... gfortran -O2 -fgraphite-identity -c pofun2.f pofun2.f: In function ‘pofun2’: pofun2.f:2:0: internal compiler er

[Bug objc++/23616] obj-c++.dg/try-catch-[29].mm (objc exceptions are broken) fails with the GNU Runtime

--- Comment #11 from pinskia at gcc dot gnu dot org 2010-03-13 05:35 --- *** Bug 43353 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug objc++/43353] Objective-C++ @try{} block produces linker error

--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-13 05:35 --- I should say with the GNU runtime combined with Objective-C++. *** This bug has been marked as a duplicate of 23616 *** -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug objc++/43353] Objective-C++ @try{} block produces linker error

--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-13 05:34 --- I mean in Objective-C++ ;). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43353

[Bug objc++/43353] Objective-C++ @try{} block produces linker error

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-13 05:34 --- Yes this is known issue with the current @try in Objective-C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43353

[Bug objc++/43353] New: Objective-C++ @try{} block produces linker error

Objective-C++ @try{} block produces linker error. $ cat test.mm @interface Foo { } @end @implementation Foo @end int main() { @try { Foo* foo; @throw foo; } @catch (Foo* e) { } return 0; } $ /usr/lib/gcc-snapshot/bin/g++ -x objective-c test.mm -lobjc # OK $ /u

[Bug c++/43352] keyword 'and' defined when even in the absence of iso646

--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-13 04:37 --- Use -fno-operator-names if you want these keywords not to be keywords in C++. Closing as invalid because these are keywords in C++. -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug c++/43352] keyword 'and' defined when even in the absence of iso646

--- Comment #3 from mdjones0978-gcc at yahoo dot com 2010-03-13 03:59 --- g++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1 Linux 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:05:19 UTC 2010 i686 GNU/Linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43352

[Bug c++/43352] keyword 'and' defined when even in the absence of iso646

--- Comment #2 from pinskia at gmail dot com 2010-03-13 03:59 --- Subject: Re: New: keyword 'and' defined when even in the absence of iso646 Sent from my iPhone On Mar 12, 2010, at 7:54 PM, "mdjones0978-gcc at yahoo dot com" wrote: > = test.cpp == > #include > >

Re: [Bug c++/43352] New: keyword 'and' defined when even in the absence of iso646

Sent from my iPhone On Mar 12, 2010, at 7:54 PM, "mdjones0978-gcc at yahoo dot com" > wrote: = test.cpp == #include std::string and(" AND "); #ifdef and #undef and #endif #define and error msgs = test.cpp:5:8: error: "and" cannot be used as a macro na

[Bug c++/43352] keyword 'and' defined when even in the absence of iso646

--- Comment #1 from mdjones0978-gcc at yahoo dot com 2010-03-13 03:58 --- Created an attachment (id=20098) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20098&action=view) Example code compile with g++ test.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43352

[Bug c++/43352] New: keyword 'and' defined when even in the absence of iso646

= test.cpp == #include std::string and(" AND "); #ifdef and #undef and #endif #define and error msgs = test.cpp:5:8: error: "and" cannot be used as a macro name as it is an operator in C++ test.cpp:8:9: error: "and" cannot be used as a macro name as it is an

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

--- Comment #9 from kargl at gcc dot gnu dot org 2010-03-13 03:52 --- (In reply to comment #8) > Maybe we just need to document that -pedantic changes the range of integers to > be what the Fortran standard requires (a symmetric range). The Fortran Standard requires neither a symmetric

[Bug libgcj/43278] shs.h:62: syntax error before `*' token

--- Comment #2 from diskman at kc dot rr dot com 2010-03-13 03:32 --- Actually this was straight from gnu.org, but I was looking at a Redhate specfile and they simply disabled libgcj all together. -- diskman at kc dot rr dot com changed: What|Removed

[Bug target/42779] extremely poor code quality, aliasing issues with __m128i

--- Comment #13 from pinskia at gcc dot gnu dot org 2010-03-13 03:21 --- Invalid as mentioned as __m128i has to alias int, short, and char as shown by PR 31245. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug target/42779] extremely poor code quality, aliasing issues with __m128i

--- Comment #12 from pinskia at gcc dot gnu dot org 2010-03-13 03:19 --- I think it is by design that __m128i is marked as may_alias.In fact it is, see PR 31245. There is no other way to get around this really. -- pinskia at gcc dot gnu dot org changed: What|Rem

[Bug target/42040] [ia64] Inappropriate address spills

--- Comment #4 from wilson at codesourcery dot com 2010-03-13 03:16 --- Subject: Re: [ia64] Inappropriate address spills Or maybe we should just accept any constant here? I tried that, and for typedef struct table { int a; int b; int c; } table; extern table mv_tables[10]; void f

[Bug bootstrap/42735] Error: symbol `pread64' is already defined

--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-13 03:14 --- Well you can do an upgrade piece wise. Do GCC 4.4.2 build with --enable-languages=c and than build a new glibc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/42721] possible integer wrong code bug

--- Comment #11 from pinskia at gcc dot gnu dot org 2010-03-13 03:10 --- Fixed in 4.4. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|

[Bug target/42040] [ia64] Inappropriate address spills

--- Comment #3 from wilson at gcc dot gnu dot org 2010-03-13 03:06 --- Created an attachment (id=20097) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20097&action=view) Untested patch that works for sje's testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040

[Bug target/42040] [ia64] Inappropriate address spills

--- Comment #2 from wilson at codesourcery dot com 2010-03-13 03:03 --- Subject: Re: [ia64] Inappropriate address spills This broke between gcc-4.0.0 and gcc-4.1.2. It appears to be the patch for PR 28490. There is a test in ia64_legitimate_constant_p for symbol +offset, where we req

[Bug rtl-optimization/43332] valgrind warns about using uninitialized variable with -fsched-pressure -fschedule-insns

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-13 02:51 --- It is the same and was fixed by the same patch. *** This bug has been marked as a duplicate of 42941 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug rtl-optimization/42941] -fsched-pressure -fschedule-insns - valgrind warns about using uninitialized variable

--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-13 02:51 --- *** Bug 43332 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42941

[Bug target/31667] Integer externsions vectorization could be improved

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-13 01:35 --- GCC 4.5 is able to produce pmovzxbw via sse4_1_zero_extendv8qiv8hi2 but it does not accept a memory operand for operand 1. movdqa x(%rip), %xmm0 pmovzxbw%xmm0, %xmm1 psrldq $8, %xmm0

[Bug c++/43145] local extern declaration gets wrong namespace

--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-13 01:29 --- If f is done inside "namespace N{}", it works -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-13 01:18 --- Maybe we just need to document that -pedantic changes the range of integers to be what the Fortran standard requires (a symmetric range). > Not all valid FORTRAN 95 programs will compile properly when using this > o

[Bug middle-end/43307] ICE in assign_temp() with STRICT_ALIGNMENT set to true on x86_64

--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-13 01:04 --- I think this is expected because on i?86, the alignment of the stack is only required to be 32 bit aligned so obviously emit_push_insn is going to have issues with stricted aligned TFmode pushes. So really this is

[Bug c++/43327] ICE in unifiy.c

--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-13 00:59 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCON

[Bug c++/43273] use in template constant from another template

--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-13 00:58 --- (In reply to comment #3) > (In reply to comment #1) > > compiles without problems using 4.4.3 and 4.5.0 > > > > if this only fails with GCC 4.2 it's unlikely to get fixed > > > > There is something strange here. >

[Bug libgcj/43278] shs.h:62: syntax error before `*' token

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-13 00:25 --- 3.2.3 is almost 7 years old and is no longer maintained. Can you try 4.4.3? Also I think this is a modified redhat 3.2.3 which means you should be reporting the problem you are having to them. I almost want to say

[Bug middle-end/33699] [4.3/4.4/4.5 regression], missing optimization on const addr area store

--- Comment #9 from pinskia at gcc dot gnu dot org 2010-03-12 23:56 --- PowerPC has the same issue. X86 does not because it's move instruction can take a constant address. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/43349] [graphite] very long compile time for gamess with -floop-interchange

--- Comment #5 from janis at gcc dot gnu dot org 2010-03-12 23:25 --- In response to comment #4, it looks like that change would fix the problem in trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43349

[Bug tree-optimization/43349] [graphite] very long compile time for gamess with -floop-interchange

--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-03-12 23:17 --- Wouldn't changes like r157319 (which hasn't made it into trunk) impact this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43349

[Bug tree-optimization/43349] [graphite] very long compile time for gamess with -floop-interchange

--- Comment #3 from janis at gcc dot gnu dot org 2010-03-12 23:12 --- I can't find that parameter in trunk, just in the graphite branch. The branch is fine, it's trunk that's taking a long time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43349

[Bug debug/43329] Early inlining causes suboptimal debug info

--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-12 23:06 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug tree-optimization/43349] [graphite] very long compile time for gamess with -floop-interchange

--- Comment #2 from spop at gcc dot gnu dot org 2010-03-12 23:01 --- The exponential behavior of PPL has been discussed here: http://groups.google.com/group/gcc-graphite/browse_thread/thread/db215cefd9bb9c8d -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43349

[Bug tree-optimization/43349] [graphite] very long compile time for gamess with -floop-interchange

--- Comment #1 from spop at gcc dot gnu dot org 2010-03-12 22:57 --- It looks like 10 is still a too high number for PARAM_GRAPHITE_MAX_NB_SCOP_PARAMS Could you try with --param graphite-max-nb-scop-params=5 I think we should improve the parameter detection to improve the compile time f

[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)

--- Comment #14 from pault at gcc dot gnu dot org 2010-03-12 22:05 --- Fixed on trunk. I´ll keep 43326 open for a bit, until I figure out what to do with fortran-dev. Thanks for the report. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed

[Bug fortran/43326] [OOP] dynamic dispatch with CLASS components

--- Comment #3 from pault at gcc dot gnu dot org 2010-03-12 22:01 --- Subject: Bug 43326 Author: pault Date: Fri Mar 12 22:00:52 2010 New Revision: 157411 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157411 Log: 2010-03-12 Paul Thomas PR fortran/43291 PR fo

[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)

--- Comment #13 from pault at gcc dot gnu dot org 2010-03-12 22:01 --- Subject: Bug 43291 Author: pault Date: Fri Mar 12 22:00:52 2010 New Revision: 157411 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157411 Log: 2010-03-12 Paul Thomas PR fortran/43291 PR f

[Bug tree-optimization/43351] ICE: SIGSEGV with -fgraphite-identity in 4.4

--- Comment #1 from zsojka at seznam dot cz 2010-03-12 21:56 --- Valgrind backtrace is the same as in pr43083: ==32751== Invalid write of size 8 ==32751==at 0x4CEAD4: link_block (cfg.c:153) ==32751==by 0x721465: create_bb (tree-cfg.c:406) ==32751==by 0x4D50A2: create_basic_bl

[Bug tree-optimization/43351] New: ICE: SIGSEGV with -fgraphite-identity in 4.4

This is very similiar to pr43083. In trunk, it stopped crashing between r156745 and r156999, so it's probably fixed by r156997, fix for pr43083. Command line: gcc -O1 testcase.c in 4.4, it crashes with -O[123s], but in trunk r156745 only with -O1 testcase.c int foo(int i) { if (i < 0)

[Bug tree-optimization/38819] [4.3 Regression] trapping expression wrongly hoisted out of loop

--- Comment #20 from ebotcazou at gcc dot gnu dot org 2010-03-12 21:27 --- > Like Eric I'm still seeing this fail on mainline on 32-bit sparc. The problem is that this is hard to fix without pessimizing the common case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819

[Bug middle-end/34668] [4.3 Regression] ICE in find_compatible_field with -combine

--- Comment #14 from pinskia at gcc dot gnu dot org 2010-03-12 21:20 --- (In reply to comment #13) > I'm still seeing this fail on 32-bit sparc with mainline: Yes we know, but that ICE is different from the problem here, see PR 39959. -- pinskia at gcc dot gnu dot org changed:

[Bug tree-optimization/38819] [4.3 Regression] trapping expression wrongly hoisted out of loop

--- Comment #19 from davem at gcc dot gnu dot org 2010-03-12 21:00 --- Like Eric I'm still seeing this fail on mainline on 32-bit sparc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819

[Bug middle-end/34668] [4.3 Regression] ICE in find_compatible_field with -combine

--- Comment #13 from davem at gcc dot gnu dot org 2010-03-12 20:58 --- I'm still seeing this fail on 32-bit sparc with mainline: home/davem/src/GIT/GCC/gcc/gcc/testsuite/gcc.dg/pr34668-2.c: In function 'set_conv_libfunc': /home/davem/src/GIT/GCC/gcc/gcc/testsuite/gcc.dg/pr34668-2.c:5:15

[Bug target/39640] MIPS : buggy va_list with float, long long and long double arguments

--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-12 20:49 --- In the end this was not a gcc bug so closing as such. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug target/43350] New: sparcv9 mode does not seem to produce LDX/STX insns

Glibc is perhaps the only file on a typical Linux sparcv9 system (read: ELF32) that makes use of 64-bit instructions like LDX/STX, and probably does so by using assembler. How come gcc is not emitting the *X family of instructions when dealing with, for example, operating on uint64_t? The appended

[Bug other/43336] GCC leaves a temporary LTO output file in $TMPDIR

--- Comment #4 from d dot g dot gorbachev at gmail dot com 2010-03-12 20:01 --- Patch: Diego Novillo wrote: > OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43336

[Bug tree-optimization/43349] New: very long compile time for gamess with -floop-interchange

Benchmark test 416.gamess from SPEC CPU2006 takes a very long time to compile with current trunk on powerpc64-linux (both -m32 and -m64) with "-O2 -floop-interchange". The slowdown started between r157243 on 20100305 and r157293 on 20100308. Here's a minimized testcase that takes several minutes

[Bug target/42040] [ia64] Inappropriate address spills

--- Comment #1 from sje at cup dot hp dot com 2010-03-12 19:22 --- I once asked Jim Wilson about this but didn't get an answer. Here is a pointer to that email. Also included here is a short example that generates the gprel load. My earlier example and question can be seen in: http:/

[Bug target/43348] [4.4 regression] ICE in final_scan_insn, at final.c:2604

--- Comment #1 from doko at ubuntu dot com 2010-03-12 18:43 --- Created an attachment (id=20096) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20096&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43348

[Bug target/43348] New: [4.4 regression] ICE in final_scan_insn, at final.c:2604

seen with current 4.4 branch on ia64-linux, not on the trunk and 4.3. goes away removing -fno-strict-aliasing, or setting the optimization to -Os or -O1: $ g++ -c -g -O2 -fno-strict-aliasing SerializedScriptValue.ii bindings/js/SerializedScriptValue.cpp: In function 'typename TreeWalker::OutputTyp

[Bug target/42869] GOMP_critical_start wrong on Itanium due to __sync miscompilation

--- Comment #6 from sje at cup dot hp dot com 2010-03-12 18:22 --- Fixed by moving the mf after the cmpxch.rel. The cmpxchg.rel will keep memory operations from moving down and the mf will keep them from moving up. Changing cmpxchg.rel to cmpxchg.acq would have achieved the same result

[Bug target/42869] GOMP_critical_start wrong on Itanium due to __sync miscompilation

--- Comment #5 from sje at gcc dot gnu dot org 2010-03-12 18:19 --- Subject: Bug 42869 Author: sje Date: Fri Mar 12 18:19:14 2010 New Revision: 157410 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157410 Log: 2010-03-12 Steve Ellcey PR target/42869 * config/

[Bug bootstrap/43328] multilib bootstrap broken.

--- Comment #13 from rwild at gcc dot gnu dot org 2010-03-12 18:10 --- BTW, the actual bug is that, if --enable-multilib is passed explicitly, it will wrongly propagate to build_configargs and host_configargs and not only to target_configargs. -- http://gcc.gnu.org/bugzilla/show_bug

[Bug bootstrap/43328] multilib bootstrap broken.

--- Comment #12 from rwild at gcc dot gnu dot org 2010-03-12 18:09 --- Thanks. I can reproduce a spurious toplevel-build/32/zlib directory when --enable-multilib is passed explicitly to toplevel configure. Workaround is to not pass --enable-multilib, multilibs are enabled by default.

[Bug libfortran/43298] fortran library does not read in NaN -Inf or Inf

--- Comment #5 from burnus at gcc dot gnu dot org 2010-03-12 17:05 --- (In reply to comment #4) > Actually, in list_read.c's parse_real gfortran already handles inf(inity) and > nan (_but_ _not _"nan(string)"). Thus, using 'read(*,*) a' works. Also list_read.c's "read_real" handles INF/

[Bug libgcj/42676] [4.5 regression] javah doesn't generate the header files as checked in in the archive

--- Comment #1 from doko at ubuntu dot com 2010-03-12 15:41 --- Created an attachment (id=20095) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20095&action=view) differences for generated header files these are the differences, when generated with gjavah 20100312; the na

-mabi=aapcs-linux compiler switch does not work well with Variable length declaration

Hi, I downloaded the u-boot repository from this website, http://www.denx.de/wiki/U-Boot. I am using an ARM11 board, which means that the compiler supports ELDK 4.2 (with EABI supported). So, the -mabi switch is set to aapcs-linux -mno-thumb-interwork. I am trying to get EXT2 support in u-boot,

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

--- Comment #17 from jvdelisle at gcc dot gnu dot org 2010-03-12 14:36 --- Subject: Bug 43320 Author: jvdelisle Date: Fri Mar 12 14:36:16 2010 New Revision: 157405 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157405 Log: 2010-03-12 Jerry DeLisle PR libfortran/4332

[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

--- Comment #18 from jvdelisle at gcc dot gnu dot org 2010-03-12 14:36 --- Subject: Bug 43265 Author: jvdelisle Date: Fri Mar 12 14:36:16 2010 New Revision: 157405 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157405 Log: 2010-03-12 Jerry DeLisle PR libfortran/4332

[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

--- Comment #17 from jvdelisle at gcc dot gnu dot org 2010-03-12 14:32 --- Subject: Bug 43265 Author: jvdelisle Date: Fri Mar 12 14:32:39 2010 New Revision: 157404 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157404 Log: 2010-03-12 Jerry DeLisle PR libfortran/4326

[Bug middle-end/43340] miscompiled code at -O2

--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-12 14:20 --- (In reply to comment #8) > looks like this rather is a bug in CP2K. fi_mat and fj_mat can alias... So, > I'll close this bug, but it is worthwhile to note that -fno-strict-aliasing > did > not 'fix' this problem.

[Bug tree-optimization/43347] Warning about symbols generated by SRA being used uninitialized

--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-12 14:12 --- I suppose %qD expansion in diagnostics should check DECL_DEBUG_EXPR_IS_FROM and instead should show DECL_DEBUG_EXPR. Sth like Index: trunk/gcc/tree-ssa.c

[Bug tree-optimization/43347] Warning about symbols generated by SRA being used uninitialized

--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-12 14:07 --- I have actually analyzed the problem earlier and it is a valid warning. The fields that SR.xxx are scalarized from are uninitialized in some paths. Thus, the only valid bug about this bug is that we show SR.xxx ins

[Bug debug/43329] Early inlining causes suboptimal debug info

--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-12 13:04 --- Subject: Bug 43329 Author: jakub Date: Fri Mar 12 13:04:37 2010 New Revision: 157402 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157402 Log: PR debug/43329 * tree-inline.c (remap_decls): Put

[Bug c/43347] [4.5 Regression] Bogus warning about symbols generated by gcc being used uninitialized

--- Comment #1 from bero at arklinux dot org 2010-03-12 12:52 --- Created an attachment (id=20094) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20094&action=view) Preprocessed source showing the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43347

[Bug c/43347] New: [4.5 Regression] Bogus warning about symbols generated by gcc being used uninitialized

gcc -std=gnu99 -Wall -Werror -O -c -o linux-kernel-modules.o linux-kernel-modules.i cc1: warnings being treated as errors linux-kernel-modules.c: In function ‘dwfl_linux_kernel_report_kernel’: linux-kernel-modules.c:894:1: error: ‘SR.243’ may be used uninitialized in this function linux-kernel-modu

[Bug middle-end/43340] miscompiled code at -O2

--- Comment #8 from jv244 at cam dot ac dot uk 2010-03-12 12:35 --- looks like this rather is a bug in CP2K. fi_mat and fj_mat can alias... So, I'll close this bug, but it is worthwhile to note that -fno-strict-aliasing did not 'fix' this problem. -- jv244 at cam dot ac dot uk chang

[Bug c++/43345] -Wunreachable-code incorrect warning

--- Comment #1 from jiri dot engelthaler at zat dot cz 2010-03-12 12:32 --- Duplicate bug with 43344 -- jiri dot engelthaler at zat dot cz changed: What|Removed |Added

[Bug c++/43346] -Wunreachable-code incorrect warning

--- Comment #1 from jiri dot engelthaler at zat dot cz 2010-03-12 12:31 --- Duplicate bug with 43344 -- jiri dot engelthaler at zat dot cz changed: What|Removed |Added

[Bug libfortran/43298] fortran library does not read in NaN -Inf or Inf

--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-12 12:31 --- Actually, in list_read.c's parse_real gfortran already handles inf(inity) and nan (_but_ _not _"nan(string)"). Thus, using 'read(*,*) a' works. * * * The TODO quote from comment 2 is for read.c's "convert_real"; ho

[Bug c++/43346] New: -Wunreachable-code incorrect warning

By adding a destructor to main class to example in the bug 21228 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21228) will produce incorrect warning about code that "will never be executed" # g++ -Wunreachable-code gstest.cpp gstest.cpp: In constructor ‘testString::testString()’: gstest.cpp:24: wa

[Bug c++/43345] New: -Wunreachable-code incorrect warning

By adding a destructor to main class to example in the bug 21228 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21228) will produce incorrect warning about code that "will never be executed" # g++ -Wunreachable-code gstest.cpp gstest.cpp: In constructor ‘testString::testString()’: gstest.cpp:24: wa

[Bug c++/43344] -Wunreachable-code incorrect warning

--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-12 12:29 --- -Wunreachable-code is broken and has been removed from GCC 4.5. Do not use it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/43344] New: -Wunreachable-code incorrect warning

By adding a destructor to main class to example in the bug 21228 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21228) will produce incorrect warning about code that "will never be executed" # g++ -Wunreachable-code gstest.cpp gstest.cpp: In constructor ‘testString::testString()’: gstest.cpp:24: wa

[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory

--- Comment #11 from rguenth at gcc dot gnu dot org 2010-03-12 12:06 --- re-confirmed with r157384. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last

[Bug middle-end/43340] miscompiled code at -O2

--- Comment #7 from jv244 at cam dot ac dot uk 2010-03-12 12:01 --- > ? You can also try -fno-ipa-cp and/or -fno-strict-overflow -O2 -fno-inline -fno-tree-vrp -fno-tree-pre -fno-strict-aliasing -fno-ipa-cp BUG -O2 -fno-inline -fno-tree-vrp -fno-tree-pre -fno-strict-aliasing -fno-ipa-cp

[Bug middle-end/43340] miscompiled code at -O2

--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-12 11:46 --- -O2 -fno-inline -fno-tree-vrp -fno-tree-pre -fno-strict-aliasing ? You can also try -fno-ipa-cp and/or -fno-strict-overflow -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43340

[Bug c/43343] -fsyntax-only rejects conforming code

--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-12 11:42 --- -fsyntax-only still runs the preprocessor. 4.1 doesn,t work for me either. i386 is one of the legacy builtin #defines. You can list them with echo | gcc-4.3 - -dD -E -- rguenth at gcc dot gnu dot org changed:

[Bug middle-end/43340] miscompiled code at -O2

--- Comment #5 from jv244 at cam dot ac dot uk 2010-03-12 11:41 --- (In reply to comment #4) > Candidates to try for -O1 vs. -O2 are -f[no-]tree-vrp, -f[no-]tree-pre, > -f[no-]strict-aliasing. You can also rule out inlining effects by > -fno-inline. no luck :-( -O1 OK -O2 BUG -O2 -fno

[Bug c/43343] New: -fsyntax-only rejects conforming code

Here the steps to reproduce: $ cat test.c int main() { int i386; } $ gcc -fsyntax-only test.c test.c: In function ‘main’: test.c:1: error: expected identifier or ‘(’ before numeric constant Also see this: $ gcc -E test.c # 1 "test.c" # 1 "" # 1 "" # 1 "test.c" int main()

[Bug lto/43342] lto1: internal compiler error: failed to reclaim unneeded function

--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-12 11:23 --- I'm not sure you are supposed to mix -flto and -fwhopr (though it probably just works). This is btw the most prominent ICE I see when building SPEC with -fwhopr and checking enabled. -- rguenth at gcc dot gnu do

[Bug middle-end/43340] miscompiled code at -O2

--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-12 11:20 --- Candidates to try for -O1 vs. -O2 are -f[no-]tree-vrp, -f[no-]tree-pre, -f[no-]strict-aliasing. You can also rule out inlining effects by -fno-inline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43340

[Bug other/43336] GCC leaves a temporary LTO output file in $TMPDIR

--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-12 11:08 --- Can you post this patch to gcc-patches@ please? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43336

[Bug fortran/43331] Cray pointers generate bogus IL for the middle-end

--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-12 10:50 --- Accept. (Draft?) patches: - Part 1: http://gcc.gnu.org/ml/fortran/2010-03/msg00061.html - Part 2: http://gcc.gnu.org/ml/fortran/2010-03/msg00062.html -- burnus at gcc dot gnu dot org changed: What|

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

--- Comment #13 from dominiq at lps dot ens dot fr 2010-03-12 10:38 --- I just got the failure today at revision 157401 on x86_64-apple-darwin10. I have saved the build directory and restarted for a successful bootstrap. Comparing the config.log files in x86_64-apple-darwin10/i386/libgom

[Bug lto/43342] lto1: internal compiler error: failed to reclaim unneeded function

--- Comment #2 from pluto at agmk dot net 2010-03-12 10:11 --- i should mention that at -O2 with object allocated on *stack* lto does a nice job and optimize indirect calls in main(): call_ZN1X3fooEv (...) call_ZN1X3barEv (...) call_ZN

[Bug lto/43342] lto1: internal compiler error: failed to reclaim unneeded function

--- Comment #1 from pluto at agmk dot net 2010-03-12 10:05 --- Created an attachment (id=20093) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20093&action=view) testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43342

[Bug lto/43342] New: lto1: internal compiler error: failed to reclaim unneeded function

here's a simple lto test on object with virtual methods: $ LANG=C make clean all CPPFLAGS=-DCRASH rm -f *.o *.s *.ii m g++-4.5 -Wall -g2 -O3 -DCRASH a.cpp -c -flto g++-4.5 -Wall -g2 -O3 -DCRASH m.cpp -c -flto g++-4.5 -Wall -g2 -O3 -DCRASH a.o m.o -o m -fwhopr --save-temps -fverbose-asm __base_dtor

[Bug gcov-profile/43341] New: pragma pack changes padding in struct gcov_info on 64-bit archs

cat < t.c int foo(){} #pragma pack(1) EOF gcc -S -fprofile-generate t.c grep '^\.LPBX' -A 2 t.s .LPBX0: .long 875574314 .quad 0 The padding ('.zero 4') between .long and .quad that correspond to the first two fields of struct gcov_info (an int and a ptr) is gone. This makes

[Bug middle-end/43340] miscompiled code at -O2

--- Comment #3 from jv244 at cam dot ac dot uk 2010-03-12 09:00 --- (In reply to comment #2) > What kind of dependencies? all derived types, defined in various modules, each with further dependencies, and the objects that are module variables. > The routine just calls one another rou

[Bug fortran/42950] gfortran testsuite failures on mingw64

--- Comment #11 from ktietz at gcc dot gnu dot org 2010-03-12 08:57 --- The follow-up patch about those collision in enumerator names is posted at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00427.html to gcc's patch-ML. The only issue remaining open for mingw/cygwin targets after this

[Bug middle-end/43340] miscompiled code at -O2

--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-12 08:40 --- What kind of dependencies? The routine just calls one another routinem so all you need is find out what arguments it is called with, write a small wrapper that calls it with those arguments, and write a dummy rotint t

[Bug middle-end/43340] miscompiled code at -O2

--- Comment #1 from jv244 at cam dot ac dot uk 2010-03-12 08:14 --- Created an attachment (id=20092) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20092&action=view) result of -fdump-tree-all results of -fdump-tree-all at -O1 and -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cg

  1   2   >