[Bug fortran/44292] [libgfortran ABI breakage] Increase internal size of RECL= of the OPEN statement
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-06-06 06:01 --- I have managed a patch that writes one very big record as in the test case. I don't have sufficient memory to actually test a read. It should be noted that the record length stored in gfc_unit which is created at runtime is a 64 bit value already. The front-end changes needed to support large record lengths is almost trivial. On the library side, writing is fairly simple as well. Reading is a little bit more complicated. Hopefully soon I will post a partial patch (or maybe even a complete but untested one) I know Steve has a machine with lots of RAM, is there anyone else who would like to help with testing this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44292
[Bug fortran/43851] Add _gfortran_error_stop_numeric
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-06-06 06:10 --- There is one last improvement we can do here. Currently we are using gfc_match_init_expr. This works fine, but the error messages are worded toward initialization expressions and not stop codes. We could generalize the messages in gfc_match_init_expr or come up with a way to either signal a different message for a stop code or create a new function such as gfc_match_stopcode_expr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
[Bug bootstrap/44428] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: Insn `*' will never be issued
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-06 08:00 --- Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00449.html With this patch I am at stage 2, so this pr is a duplicate of pr44427 and fixed. *** This bug has been marked as a duplicate of 44427 *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44428
[Bug bootstrap/44427] genautomata uses more than 1.5GB of RAM on powerpc64-linux
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-06 08:00 --- *** Bug 44428 has been marked as a duplicate of this bug. *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44427
[Bug middle-end/41753] [OOP] segfault with -O2 using methods as actual arguments
--- Comment #4 from dominiq at lps dot ens dot fr 2010-06-06 08:05 --- At r160335, I don't see the failure on x86_64-unknown-linux-gnu. Maybe it has been fixed by some middle-end changes by now. Can anyone confirm that the error is gone? No error for the flags I have tried on x86_64-apple-darwin10.3.0 and powerpc-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41753
[Bug c++/44086] undiagnosed invalid default initialization of const bit field members
--- Comment #2 from fabien at gcc dot gnu dot org 2010-06-06 09:35 --- Subject: Bug 44086 Author: fabien Date: Sun Jun 6 09:35:45 2010 New Revision: 160337 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160337 Log: Fix PR c++/44086 Added: trunk/gcc/testsuite/g++.dg/init/pr44086.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/decltype4.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44086
[Bug fortran/44430] New: [4.6 Regression] Infinite recursion with -fdump-parse-tree
This is with revision 160336. $ cat a.f90 subroutine foo(a,b) real :: a(10), b(5) a(1:5) = b end $ gfortran -fdump-parse-tree a.f90 | head -40 Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = foo symtree: __convert_i4_i8 Ambig 0 symbol __convert_i4_i8 (INTEGER 8)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN FUNCTION ELEMENTAL PURE) result: __convert_i4_i8 symtree: a Ambig 0 symbol a (REAL 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN DIMENSION DUMMY) Array spec:(1 [0] AS_EXPLICIT 1 10 ) symtree: b Ambig 0 symbol b (REAL 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN DIMENSION DUMMY) Array spec:(1 [0] AS_EXPLICIT 1 5 ) symtree: foo Ambig 0 symbol foo (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN SUBROUTINE) Formal arglist: a b Formal namespace Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = foo symtree: __convert_i4_i8 Ambig 0 symbol __convert_i4_i8 (INTEGER 8)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN FUNCTION ELEMENTAL PURE) result: __convert_i4_i8 symtree: a Ambig 0 symbol a (REAL 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN DIMENSION DUMMY) Array spec:(1 [0] AS_EXPLICIT 1 10 ) symtree: b Ambig 0 symbol b (REAL 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN DIMENSION DUMMY) Array spec:(1 [0] AS_EXPLICIT 1 5 ) symtree: foo Ambig 0 symbol foo (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN SUBROUTINE) Formal arglist: a b Formal namespace Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = foo symtree: __convert_i4_i8 Ambig 0 symbol __convert_i4_i8 (INTEGER 8)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN FUNCTION ELEMENTAL PURE) result: __convert_i4_i8 symtree: a Ambig 0 symbol a (REAL 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN DIMENSION DUMMY) Array spec:(1 [0] AS_EXPLICIT 1 10 ) symtree: b Ambig 0 symbol b (REAL 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN DIMENSION DUMMY) Array spec:(1 [0] AS_EXPLICIT 1 5 ) ... and so on. -- Summary: [4.6 Regression] Infinite recursion with -fdump-parse- tree Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug fortran/44430] [4.6 Regression] Infinite recursion with -fdump-parse-tree
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug fortran/44430] [4.6 Regression] Infinite recursion with -fdump-parse-tree
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-06 10:32 --- gcc version 4.4.4 gives Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = foo symtree: __convert_i4_i8 Ambig 0 symbol __convert_i4_i8 (INTEGER 8)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN FUNCTION ELEMENTAL PURE) symtree: a Ambig 0 symbol a (REAL 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN DIMENSION DUMMY) Array spec:(1 AS_EXPLICIT 1 10 ) symtree: b Ambig 0 symbol b (REAL 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN DIMENSION DUMMY) Array spec:(1 AS_EXPLICIT 1 5 ) symtree: foo Ambig 0 symbol foo (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC UNKNOWN SUBROUTINE) Formal arglist: a b ASSIGN foo:a(1_8:5_8) foo:b(FULL) Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = MAIN__ symtree: MAIN__ Ambig 0 symbol MAIN__ (UNKNOWN 0)(PROGRAM UNKNOWN-INTENT PUBLIC UNKNOWN-PROC UNKNOWN SUBROUTINE) The infinite recursion occurs also for gcc version 4.5.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug lto/44429] lto ignoring __attribute__((used))
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-06 10:32 --- The problem is that statics need to be mangled, so they persist as i.1234 instead. Really refering to a local symbol in asm is going to be difficult with LTO (any global or other static symbol with name i will cause a non-resolvable conflict). *** This bug has been marked as a duplicate of 43038 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44429
[Bug lto/43038] DECL_PRESERVE_P static globals not completely preserved with -flto
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-06 10:32 --- *** Bug 44429 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||astrange at ithinksw dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038
[Bug target/43729] Mach-O LTO support needed for darwin
--- Comment #50 from dominiq at lps dot ens dot fr 2010-06-06 10:50 --- On x86_64-apple-darwin10.3.0 between revisions 160235 and 160330 the failures with -m32 went from FAIL: gcc.c-torture/execute/builtins/abs-1.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/memmove-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/memset-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/stpcpy-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/strcat-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/strcpy-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/strncat-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/strncpy-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/strstr-asm.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c compilation, -O2 -fwhopr to FAIL: gcc.c-torture/execute/builtins/abs-1.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/strstr-asm.c compilation, -O2 -fwhopr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug c++/16630] missing type name in __PRETTY_FUNCTION__
--- Comment #9 from redi at gcc dot gnu dot org 2010-06-06 11:17 --- Are we sure we'll always want the typename BU::X = int part? Would checking for just const char* DU::foo(typename BU::X) be preferable? (I don't know what the convention is for this sort of check) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16630
[Bug fortran/44430] [4.5/4.6 Regression] Infinite recursion with -fdump-parse-tree
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.5.0 4.6.0 Known to work||4.4.1 Last reconfirmed|-00-00 00:00:00 |2010-06-06 11:22:49 date|| Summary|[4.6 Regression] Infinite |[4.5/4.6 Regression] |recursion with -fdump-parse-|Infinite recursion with - |tree|fdump-parse-tree http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug bootstrap/44427] genautomata uses more than 1.5GB of RAM on powerpc64-linux
--- Comment #3 from segher at gcc dot gnu dot org 2010-06-06 11:39 --- Subject: Bug 44427 Author: segher Date: Sun Jun 6 11:38:46 2010 New Revision: 160338 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160338 Log: gcc/ChangeLog 2010-06-06 Segher Boessenkool seg...@kernel.crashing.org PR bootstrap/44427 PR bootstrap/44428 genautomata.c (SET_BIT, CLEAR_BIT, TEST_BIT): Make these macros endianness-independent. Modified: trunk/gcc/ChangeLog trunk/gcc/genautomata.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44427
[Bug bootstrap/44428] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: Insn `*' will never be issued
--- Comment #3 from segher at gcc dot gnu dot org 2010-06-06 11:39 --- Subject: Bug 44428 Author: segher Date: Sun Jun 6 11:38:46 2010 New Revision: 160338 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160338 Log: gcc/ChangeLog 2010-06-06 Segher Boessenkool seg...@kernel.crashing.org PR bootstrap/44427 PR bootstrap/44428 genautomata.c (SET_BIT, CLEAR_BIT, TEST_BIT): Make these macros endianness-independent. Modified: trunk/gcc/ChangeLog trunk/gcc/genautomata.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44428
[Bug bootstrap/44427] genautomata uses more than 1.5GB of RAM on powerpc64-linux
--- Comment #4 from segher at gcc dot gnu dot org 2010-06-06 11:40 --- Fixed. -- segher at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44427
[Bug ada/44431] New: [boot with C++] Conflicting exit declaration in ada/b_gnatb.c
With --enable-build-with-cxx I see In file included from ada/b_gnatb.c:252: ada/b_gnatb.c:5: error: previous declaration of 'void exit(int)' with 'C++' linkage /usr/include/stdlib.h:543: error: conflicts with new declaration with 'C' linkage /usr/include/stdlib.h:543: error: declaration of 'void exit(int) throw ()' throws different exceptions ada/b_gnatb.c:5: error: from previous declaration 'void exit(int)' -- Summary: [boot with C++] Conflicting exit declaration in ada/b_gnatb.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44431
[Bug bootstrap/44432] New: [boot with C++] configure does not check presence of host C++ compiler
Without a C++ host compiler (AC_PROG_CXX fails) bootsrap with --enbale-build-with-cxx fails like config.status: creating nm config.status: creating Makefile config.status: creating gccbug config.status: creating ada/gcc-interface/Makefile config.status: creating ada/Makefile config.status: creating auto-host.h config.status: executing default commands make[2]: Leaving directory `/home/abuild/rguenther/obj' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/abuild/rguenther/obj' make: *** [all] Error 2 instead of complaining for the lack of a C++ host compiler. -- Summary: [boot with C++] configure does not check presence of host C++ compiler Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44432
[Bug bootstrap/44433] New: [meta-bug] --enable-build-with-cxx issues
Issues to be fixed before --enable-build-with-cxx can be made the default. -- Summary: [meta-bug] --enable-build-with-cxx issues Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44433
[Bug fortran/44434] New: [OOP] ICE in in gfc_add_component_ref
The attached code produces the following error output [sfili...@localhost bug18]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.6.0 20100605 (experimental) (GCC) [sfili...@localhost bug18]$ gfortran -c bug18.f03 bug18.f03:76:0: internal compiler error: in gfc_add_component_ref, at fortran/class.c:77 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [OOP] ICE in in gfc_add_component_ref Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44434
[Bug fortran/44434] [OOP] ICE in in gfc_add_component_ref
--- Comment #1 from sfilippone at uniroma2 dot it 2010-06-06 12:07 --- Created an attachment (id=20850) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20850action=view) test case If the CLASS DEFAULT block is switched to use AA%CSGET() instead of A%A%CSGET() no ICE ensues. I am not sure whether this is legal, but it is accepted by both IBM XLF and NAG. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44434
[Bug fortran/44434] [OOP] ICE in in gfc_add_component_ref
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-06 12:18 --- It looks like a duplicate of the unfixed part of pr43945. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44434
[Bug ada/44431] [boot with C++] Conflicting exit declaration in ada/b_gnatb.c
--- Comment #1 from laurent at guerby dot net 2010-06-06 12:35 --- The Ada language build issues were all adressed by my patch on june 2009 here: http://gcc.gnu.org/ml/gcc/2009-06/msg00635.html The patch for your problem is the gcc/ada/gcc-interface/Makefile.in change to use -A instead of -C for gnatbind. As I said in the last message of the discussion there are a few choice to make to do the switch to be able to use C++ and an Ada maintainer needs to step in now. -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net, ||charlet at gcc dot gnu dot ||org, ebotcazou at gcc dot ||gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44431
[Bug ada/44431] [boot with C++] Conflicting exit declaration in ada/b_gnatb.c
--- Comment #2 from rguenther at suse dot de 2010-06-06 12:41 --- Subject: Re: [boot with C++] Conflicting exit declaration in ada/b_gnatb.c On Sun, 6 Jun 2010, laurent at guerby dot net wrote: --- Comment #1 from laurent at guerby dot net 2010-06-06 12:35 --- The Ada language build issues were all adressed by my patch on june 2009 here: http://gcc.gnu.org/ml/gcc/2009-06/msg00635.html The patch for your problem is the gcc/ada/gcc-interface/Makefile.in change to use -A instead of -C for gnatbind. As I said in the last message of the discussion there are a few choice to make to do the switch to be able to use C++ and an Ada maintainer needs to step in now. All other languages work fine with C++ now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44431
[Bug middle-end/41753] [OOP] segfault with -O2 using methods as actual arguments
--- Comment #5 from pault at gcc dot gnu dot org 2010-06-06 12:49 --- (In reply to comment #4) It's fixed for me too. x86_64/FC9 I'll mark it as fixed - thanks for noting that it had gone. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41753
[Bug c++/44086] undiagnosed invalid default initialization of const bit field members
--- Comment #3 from fabien at gcc dot gnu dot org 2010-06-06 12:59 --- Fixed in 4.6. -- fabien at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44086
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- Comment #16 from redi at gcc dot gnu dot org 2010-06-06 13:27 --- Subject: Bug 40296 Author: redi Date: Sun Jun 6 13:27:23 2010 New Revision: 160340 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160340 Log: 2010-06-06 Jonathan Wakely jwakely@gmail.com PR libstdc++/40296 * libsupc++/exception_ptr.h (exception_ptr::exception_ptr): Replace __safe_bool constructor with nullptr_t constructor in C++0x mode. (exception_ptr::operator bool): Add explicit conversion to bool. (swap(exception_ptr, exception_ptr)): Add. (exception_ptr::_M_safe_bool_dummy): Only declare for old ABI. * libsupc++/eh_ptr.cc (exception_ptr::_M_safe_bool_dummy): Move next to other functions retained for ABI compatibility. * testsuite/18_support/exception_ptr/requirements.cc: New. * testsuite/18_support/exception_ptr/requirements_neg.cc: New. Added: trunk/libstdc++-v3/testsuite/18_support/exception_ptr/requirements.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/requirements_neg.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/eh_ptr.cc trunk/libstdc++-v3/libsupc++/exception_ptr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #74 from iains at gcc dot gnu dot org 2010-06-06 13:35 --- posted as http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00463.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- Comment #17 from redi at gcc dot gnu dot org 2010-06-06 13:36 --- Changed for 4.6.0 but I don't think the change is appropriate for the 4.5.0 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug c/44435] New: gengtype: don't test undefined value after vasprintf failure
Harmless, but distracting... This is present is the latest sources on trunk. gengtype: don't test undefined value after vasprintf failure While libiberty's asprintf function does guarantee that the pointer is set to NULL upon asprintf failure, POSIX/glibc make no such guarantee. * gengtype.c (xasprintf): Don't test an undefined value upon vasprintf failure. * gengtype.c (oprintf): Likewise. Patch attached. -- Summary: gengtype: don't test undefined value after vasprintf failure Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jim at meyering dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
[Bug c/44435] gengtype: don't test undefined value after vasprintf failure
--- Comment #1 from jim at meyering dot net 2010-06-06 13:41 --- Created an attachment (id=20851) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20851action=view) gengtype: don't test undefined value after vasprintf failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
[Bug target/43729] Mach-O LTO support needed for darwin
--- Comment #51 from dominiq at lps dot ens dot fr 2010-06-06 13:46 --- The 14 tests were fixed by revision 160258 (that has nothing to do with darwin). Also I see the following changes, 160257: === gcc tests === Schedule of variations: unix/-m32 unix/-m64 Running target unix/-m32 Using /sw64/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw64/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/p_work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/lto.exp ... FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20081112 c_lto_20081112_0.o-c_lto_20081112_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/20081112 c_lto_20081112_0.o-c_lto_20081112_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090213 c_lto_20090213_0.o-c_lto_20090213_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090218 c_lto_20090218_0.o-c_lto_20090218_3.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20100227-1 c_lto_20100227-1_0.o-c_lto_20100227-1_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/20100227-1 c_lto_20100227-1_0.o-c_lto_20100227-1_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20100423-2 c_lto_20100423-2_0.o-c_lto_20100423-2_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20100423-2 c_lto_20100423-2_0.o-c_lto_20100423-2_1.o link, -O3 -fwhopr FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o link, -O0 -fwhopr (internal compiler error) FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o link, -O2 -fwhopr (internal compiler error) FAIL: gcc.dg/lto/20100603-3 c_lto_20100603-3_0.o-c_lto_20100603-3_0.o link, -O0 -fwhopr (internal compiler error) FAIL: gcc.dg/lto/20100603-3 c_lto_20100603-3_0.o-c_lto_20100603-3_0.o link, -O2 -fwhopr (internal compiler error) FAIL: gcc.dg/lto/ipacp c_lto_ipacp_0.o-c_lto_ipacp_1.o link, -O1 -fwhopr -fipa-cp -fipa-cp-clone FAIL: gcc.dg/lto/ipareference2 c_lto_ipareference2_0.o-c_lto_ipareference2_1.o link, -O1 -fwhopr -fwhole-program FAIL: gcc.dg/lto/ipareference c_lto_ipareference_0.o-c_lto_ipareference_1.o link, -O1 -fwhopr FAIL: gcc.dg/lto/materialize-1 c_lto_materialize-1_0.o-c_lto_materialize-1_1.o link, -O3 -fwhopr === gcc Summary for unix/-m32 === # of expected passes520 # of unexpected failures20 # of unresolved testcases 20 # of unsupported tests 4 Running target unix/-m64 Using /sw64/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw64/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/p_work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/lto.exp ... FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o link, -O0 -fwhopr (internal compiler error) FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o link, -O2 -fwhopr (internal compiler error) FAIL: gcc.dg/lto/20100603-3 c_lto_20100603-3_0.o-c_lto_20100603-3_0.o link, -O0 -fwhopr (internal compiler error) FAIL: gcc.dg/lto/20100603-3 c_lto_20100603-3_0.o-c_lto_20100603-3_0.o link, -O2 -fwhopr (internal compiler error) === gcc Summary for unix/-m64 === # of expected passes544 # of unexpected failures6 # of unresolved testcases 6 # of unsupported tests 4 === gcc Summary === # of expected passes1064 # of unexpected failures26 # of unresolved testcases 26 # of unsupported tests 8 r160258: === gcc tests === Schedule of variations: unix/-m32 unix/-m64 Running target unix/-m32 Using /sw64/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw64/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/p_work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/lto.exp ... FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20081112 c_lto_20081112_0.o-c_lto_20081112_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090213 c_lto_20090213_0.o-c_lto_20090213_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090218 c_lto_20090218_0.o-c_lto_20090218_3.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090717 c_lto_20090717_0.o-c_lto_20090717_1.o link, -O0 -fwhopr FAIL:
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #19 from amodra at gmail dot com 2010-06-06 14:11 --- Confirmed. Regarding O1test.c: Wierd set of gcc options, particularly -fno-dce and -fcaller-saves. I can't see any sane reason why you would use those options on powerpc, unless you were deliberately stress testing gcc.. It's quite possible that your O1test.c is tickling an entirely different bug than in the original testcase. Trimming the options a bit, I can reproduce the O1test.c problem with only -fcaller-saves -O -fno-omit-frame-pointer -fno-dce -fno-split-wide-types -- amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-06 14:11:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug ada/44431] [boot with C++] Conflicting exit declaration in ada/b_gnatb.c
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-06-06 14:16 --- The patch for your problem is the gcc/ada/gcc-interface/Makefile.in change to use -A instead of -C for gnatbind. As I said in the last message of the discussion there are a few choice to make to do the switch to be able to use C++ and an Ada maintainer needs to step in now. The -C mode for gnatbind is to be deprecated so we'll need to make the switch in any cases. Let's wait for Arno's take on this. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-06 14:16:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44431
[Bug bootstrap/44427] genautomata uses more than 1.5GB of RAM on powerpc64-linux
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-06-06 14:38 --- Missing '*' before the file name in the ChangeLog. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44427
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #20 from amodra at gmail dot com 2010-06-06 14:52 --- My guess is that tc-lossings-floats.c hits an ira related problem, but I'm not particularly familiar with that area of the compiler so won't look further myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #21 from Kyle dot D dot Moffett at boeing dot com 2010-06-06 15:37 --- I was trying to strip down the testcase and try to see which optimization flags caused it. I started from -O2 and tried to see which -O2 flags (in addition to O1) were needed to cause the problem. From there I simplified the testcase as small as I could get it and turned off as many other optimizations as possible. As far as I can tell, it seems to be a combination of -fcaller-saves and the minimal CSE that -O1 always turns on (regardless of other -fno-* options). Part of the reason for the extra -fno-* compiler options was to prevent the compiler from moving registers around so much as I fiddled with the testcase, since the bug is only triggered when it allocates one of the 2 doubles in a register that is reused by one of the libgcc functions it calls. Other than that, I'm just grasping at straws... If somebody can debug this and fix both testcases before FreeScale gets back to us with a fix I'll ship them a case or two of their favorite beer (or whatever other beverage they'd prefer). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug bootstrap/44335] [4.6 regression] gcc-4.6-20100529 java bootstrap failure on arm-linux-gnueabi
--- Comment #3 from mikpe at it dot uu dot se 2010-06-06 15:42 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00472.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44335
[Bug other/44435] gengtype: don't test undefined value after vasprintf failure
--- Comment #2 from jsm28 at gcc dot gnu dot org 2010-06-06 15:53 --- If the libiberty maintainers won't review the xvasprintf patch, perhaps a global reviewer could do so? That would be better than fiddling with local checks. http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01448.html http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01449.html -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Component|c |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
[Bug fortran/44434] [OOP] ICE in in gfc_add_component_ref
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-06 16:16 --- (In reply to comment #2) It looks like a duplicate of the unfixed part of pr43945. It is. One can reduce the test case here to something equivalent to PR 43945 comment #12, which is: module foo_mod type foo contains procedure :: doit generic :: do = doit end type contains subroutine doit(a) class(foo) :: a end subroutine end module program testd15 contains subroutine dodo(x) use foo_mod class(foo) :: x call x%do() end subroutine end We can track the issue in this PR, and I'll close the other one. -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-06-06 16:16:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44434
[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP
--- Comment #13 from janus at gcc dot gnu dot org 2010-06-06 16:20 --- The remaining issue (comment #4/#11/#12) is being tracked by PR 44434, so this one can be closed. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
[Bug c/20000] missing warning for noreturn function returning non-void
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-06 16:40 --- Subject: Bug 2 Author: manu Date: Sun Jun 6 16:40:18 2010 New Revision: 160346 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160346 Log: 2010-06-06 Manuel López-Ibáñez m...@gcc.gnu.org PR c/2 * c-decl.c (grokdeclarator): Delete warning. testsuite/ * c-c++-common/pr2.c: New. Added: trunk/gcc/testsuite/c-c++-common/pr2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug c/20000] missing warning for noreturn function returning non-void
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-06 16:41 --- FIXED in GCC 4.6 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug c++/25994] Using declarations and base function overloading
-- fabien at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fabien at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-27 13:40:58 |2010-06-06 17:52:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25994
[Bug c++/44188] Fails to produce DW_AT_typedef for typedef of anonymous struct
--- Comment #8 from dodji at gcc dot gnu dot org 2010-06-06 18:24 --- Subject: Bug 44188 Author: dodji Date: Sun Jun 6 18:24:27 2010 New Revision: 160347 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160347 Log: Fix PR c++/44188 gcc/ChangeLog: PR c++/44188 * c-common.c (is_typedef_decl): Move this definition ... * tree.c (is_typedef_decl): ... here. (typdef_variant_p): Move definition here from gcc/cp/tree.c. * c-common.h (is_typedef_decl): Move this declaration ... * tree.h (is_typedef_decl): ... here. (typedef_variant_p): Move declaration here from gcc/cp/cp-tree.h * dwarf2out.c (is_naming_typedef_decl): New function. (gen_tagged_type_die): Split out of ... (gen_type_die_with_usage): ... this function. When an anonymous tagged type is named by a typedef, make sure a DW_TAG_typedef DIE is emitted for the typedef. (gen_typedef_die): Emit DW_TAG_typedef also for typedefs naming anonymous tagged types. gcc/cp/ChangeLog: PR c++/44188 * cp-tree.h (typedef_variant_p): Move this declaration to gcc/tree.h. * tree.c (typedef_variant_p): Move this definition to gcc/tree.c. * decl.c (grokdeclarator): Do not rename debug info of an anonymous tagged type named by a typedef. gcc/testsuite/ChangeLog: PR c++/44188 * g++.dg/debug/dwarf2/typedef3.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef3.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/tree.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
[Bug c++/44188] Fails to produce DW_AT_typedef for typedef of anonymous struct
--- Comment #9 from dodji at gcc dot gnu dot org 2010-06-06 18:33 --- Hopefully properly fixed in trunk (4.6) now. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #16 from mikpe at it dot uu dot se 2010-06-06 19:16 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00481.html I tried to use the existing stack tie instead of a full barrier, but it had no effect at all, causing the mis-schedules to reappear. I also tried to port over the PowerPC version of the stack tie, but that ICEd the compiler; I'm not yet good enough at .md hackery to resolve that one. So I went back to the initial patch, and bootstrapped and regtested it in native builds of 4.6, 4.5, and 4.4 on armv5tel-linux-gnueabi. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug target/42159] [4.4/4.5/4.6] app SIGABRTs after a trivial nested throw/stack unwinding
--- Comment #18 from michael at jarvis dot net 2010-06-06 19:32 --- I can confirm the bug on my system (MacOS 10.6.3, Intel Core i7) with g++ 4.4.2, 4.4.3 and 4.4.4. However, I have discovered a workaround. Linking with -lpthread makes the problem go away, both for this simple test case, and my larger program where I too discovered the bug. My program only started failing when I turned off the OpenMP stuff. However, if I leave OpenMP off, but link with -lpthread anyway, the exception stuff works fine. Likewise, this example program works correctly when I compile with -lpthread. -- michael at jarvis dot net changed: What|Removed |Added CC||michael at jarvis dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
[Bug libstdc++/44436] New: Associative containers lack emplace() and emplace_hint() methods.
C++0x associative containers should have emplace() and emplace_hint() methods, but those in libstdc++ do not. -- Summary: Associative containers lack emplace() and emplace_hint() methods. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jack2 at cantab dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436
[Bug target/44392] [4.5/4.6 Regression] libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2
--- Comment #3 from mikpe at it dot uu dot se 2010-06-06 19:54 --- I've looked at this, and as far as I can tell it's caused by two separate improvements in 4.5 that are Ok individually but cause libgcc's __bswapsi2 to call itself when combined (and certain build options are selected). 1. The middle-end now recognises C idioms for bswap and represents them as calls to the builtin bswap. 2. The ARM backend now generates much better code for the builtin bswap, but for archs prior to ARMv6 when -Os is enabled the .md expander arranges to have a libcall emitted instead. Consequently, then building for (say) ARMv5 with --enable-target-optspace: a) the middle-end represents the C bswap idiom in libgcc2.c:__bswapsi2 () as a call to the builtin b) the ARM backend (not knowing it's compiling libgcc) emits a libcall c) hence __bswapsi2 () calls itself The only way I see around this is to add a compiler option (-fin-libgcc say), set it when compiling libgcc routines (similar to -DIN_LIBGCC2), check for it in the ARM bswap expander, and if set ignore -Os in the arch v6 case. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392
[Bug fortran/44430] [4.5/4.6 Regression] Infinite recursion with -fdump-parse-tree
--- Comment #2 from tkoenig at gcc dot gnu dot org 2010-06-06 20:15 --- This was between rev. 149577 (works) and rev. 149607 (does not work). Still narrowing it down a bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug target/44392] [4.5/4.6 Regression] libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-06 20:22 --- No, the arm backend should not claim to implement bswapsi when it in fact emits a libcall. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392
[Bug target/43729] Mach-O LTO support needed for darwin
--- Comment #52 from dominiq at lps dot ens dot fr 2010-06-06 20:23 --- On powerpc-apple-darwin9 I see a similar improvement at revision 160335: === gcc tests === Schedule of variations: unix/-m32 unix/-m64 Running target unix/-m32 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.6-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.6-work/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp ... FAIL: gcc.c-torture/execute/builtins/abs-1.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/strstr-asm.c compilation, -O2 -fwhopr === gcc Summary for unix/-m32 === # of expected passes900 # of unexpected failures2 # of unresolved testcases 2 Running target unix/-m64 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.6-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.6-work/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp ... FAIL: gcc.c-torture/execute/builtins/abs-1.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/strstr-asm.c compilation, -O2 -fwhopr === gcc Summary for unix/-m64 === # of expected passes900 # of unexpected failures2 # of unresolved testcases 2 === gcc Summary === # of expected passes1800 # of unexpected failures4 # of unresolved testcases 4 === gcc tests === Schedule of variations: unix/-m32 unix/-m64 Running target unix/-m32 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.6-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.6-work/gcc/testsuite/gcc.dg/lto/lto.exp ... FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20081112 c_lto_20081112_0.o-c_lto_20081112_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090213 c_lto_20090213_0.o-c_lto_20090213_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090218 c_lto_20090218_0.o-c_lto_20090218_3.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090717 c_lto_20090717_0.o-c_lto_20090717_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/20090717 c_lto_20090717_0.o-c_lto_20090717_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20091005-1 c_lto_20091005-1_0.o-c_lto_20091005-1_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/20100227-1 c_lto_20100227-1_0.o-c_lto_20100227-1_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/20100227-1 c_lto_20100227-1_0.o-c_lto_20100227-1_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20100518 c_lto_20100518_0.o assemble, -O0 -fwhopr FAIL: gcc.dg/lto/20100518 c_lto_20100518_0.o assemble, -O2 -fwhopr FAIL: gcc.dg/lto/20100518 c_lto_20100518_0.o assemble, -O0 -flto FAIL: gcc.dg/lto/20100518 c_lto_20100518_0.o assemble, -O2 -flto FAIL: gcc.dg/lto/ipacp c_lto_ipacp_0.o-c_lto_ipacp_1.o link, -O1 -fwhopr -fipa-cp -fipa-cp-clone FAIL: gcc.dg/lto/ipareference2 c_lto_ipareference2_0.o-c_lto_ipareference2_1.o link, -O1 -fwhopr -fwhole-program FAIL: gcc.dg/lto/materialize-1 c_lto_materialize-1_0.o-c_lto_materialize-1_1.o link, -O3 -fwhopr === gcc Summary for unix/-m32 === # of expected passes516 # of unexpected failures17 # of unresolved testcases 21 # of unsupported tests 6 Running target unix/-m64 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.6-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.6-work/gcc/testsuite/gcc.dg/lto/lto.exp ... FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20081112 c_lto_20081112_0.o-c_lto_20081112_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error) FAIL: gcc.dg/lto/20090213 c_lto_20090213_0.o-c_lto_20090213_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090218 c_lto_20090218_0.o-c_lto_20090218_3.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20090717 c_lto_20090717_0.o-c_lto_20090717_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/20090717 c_lto_20090717_0.o-c_lto_20090717_1.o link, -O2 -fwhopr FAIL: gcc.dg/lto/20091005-1 c_lto_20091005-1_0.o-c_lto_20091005-1_1.o link, -O0 -fwhopr FAIL: gcc.dg/lto/20100227-1
[Bug fortran/44430] [4.5/4.6 Regression] Infinite recursion with -fdump-parse-tree
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-06 20:39 --- This was between rev. 149577 (works) and rev. 149607 (does not work). The only candidate I see is 149586. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug fortran/44430] [4.5/4.6 Regression] Infinite recursion with -fdump-parse-tree
--- Comment #4 from tkoenig at gcc dot gnu dot org 2010-06-06 20:52 --- I agree. Rev. 149586 is: 2009-07-13 Janus Weil ja...@gcc.gnu.org PR fortran/40646 * module.c (mio_symbol): If the symbol has formal arguments, the formal namespace will be present. * resolve.c (resolve_actual_arglist): Correctly handle 'called' procedure pointer components as actual arguments. (resolve_fl_derived,resolve_symbol): Make sure the formal namespace is present. * trans-expr.c (gfc_conv_procedure_call): Correctly handle the formal arguments of procedure pointer components. (nothing else suspicious in that range. Janus? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug fortran/44430] [4.5/4.6 Regression] Infinite recursion with -fdump-parse-tree
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-06 21:31 ---
I'm afraid you're right. r149586 indeed seems to be the culprit. The bug goes
away when reverting a part of that commit, more precisely this one:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 160347)
+++ gcc/fortran/resolve.c (working copy)
@@ -11661,20 +11655,6 @@ resolve_symbol (gfc_symbol *sym)
!sym-attr.contained !sym-attr.intrinsic)
gfc_resolve (sym-formal_ns);
- /* Make sure the formal namespace is present. */
- if (sym-formal !sym-formal_ns)
-{
- gfc_formal_arglist *formal = sym-formal;
- while (formal !formal-sym)
- formal = formal-next;
-
- if (formal)
- {
- sym-formal_ns = formal-sym-ns;
- sym-formal_ns-refs++;
- }
-}
-
/* Check threadprivate restrictions. */
if (sym-attr.threadprivate !sym-attr.save !sym-ns-save_all
(!sym-attr.in_common
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2
--- Comment #7 from redi at gcc dot gnu dot org 2010-06-06 21:31 --- Created an attachment (id=20852) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20852action=view) alternative patch Based on the dates from Dave, I think this might be more accurate, and I hope clearer. The output looks like ... * gcc-3.3.3: libgcc_s.so.1 * gcc-3.4.x, gcc-4.[0-1].x: libgcc_s.so.1 For m68k-linux the versions differ as follows: * gcc-3.4.x, gcc-4.[0-5].x: libgcc_s.so.1 when configuring --with-sjlj-exceptions, or libgcc_s.so.2 For hppa-linux the versions differ as follows: * gcc-3.4.x, gcc-4.[0-1].x: either libgcc_s.so.1 when configuring --with-sjlj-exceptions, or libgcc_s.so.2 * gcc-4.[2-5].x: either libgcc_s.so.3 when configuring --with-sjlj-exceptions) or libgcc_s.so.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44268
[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2
--- Comment #8 from redi at gcc dot gnu dot org 2010-06-06 21:33 --- (In reply to comment #7) ... * gcc-3.3.3: libgcc_s.so.1 * gcc-3.4.x, gcc-4.[0-1].x: libgcc_s.so.1 ^ oops, should be 5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44268
[Bug fortran/44430] [4.5/4.6 Regression] Infinite recursion with -fdump-parse-tree
--- Comment #6 from janus at gcc dot gnu dot org 2010-06-06 21:45 ---
A simple way to fix this:
Index: gcc/fortran/dump-parse-tree.c
===
--- gcc/fortran/dump-parse-tree.c (revision 160347)
+++ gcc/fortran/dump-parse-tree.c (working copy)
@@ -853,7 +853,7 @@ show_symbol (gfc_symbol *sym)
}
}
- if (sym-formal_ns)
+ if (sym-formal_ns (sym-formal_ns != sym-ns))
{
show_indent ();
fputs (Formal namespace, dumpfile);
I'm not 100% sure yet if this is the *proper* way, but I'll try to find out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug fortran/44430] [4.5/4.6 Regression] Infinite recursion with -fdump-parse-tree
-- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-06-06 11:22:49 |2010-06-06 21:46:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug fortran/44430] [4.5/4.6 Regression] Infinite recursion with -fdump-parse-tree
--- Comment #7 from janus at gcc dot gnu dot org 2010-06-06 21:50 --- (In reply to comment #5) The bug goes away when reverting a part of that commit Of course simply reverting that part causes a couple of regressions, e.g. proc_ptr_1,10,22 and others. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug target/44067] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713
--- Comment #1 from amodra at gmail dot com 2010-06-07 02:19 --- First testcase in pr44364 tickles this bug on mainline too. Looks like we need the following. Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 160351) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -17013,7 +17013,7 @@ rs6000_split_multireg_move (rtx dst, rtx ((TARGET_HARD_FLOAT TARGET_DOUBLE_FLOAT) ? DFmode : SFmode); else if (ALTIVEC_REGNO_P (reg)) reg_mode = V16QImode; - else if (TARGET_E500_DOUBLE mode == TFmode) + else if (TARGET_E500_DOUBLE (mode == DFmode || mode == TFmode)) reg_mode = DFmode; else reg_mode = word_mode; -- amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-07 02:20:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44067
[Bug target/44419] ICE when building for Freescale e500v2
--- Comment #1 from amodra at gmail dot com 2010-06-07 02:21 --- *** This bug has been marked as a duplicate of 44067 *** -- amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44419
[Bug target/44067] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713
--- Comment #2 from amodra at gmail dot com 2010-06-07 02:21 --- *** Bug 44419 has been marked as a duplicate of this bug. *** -- amodra at gmail dot com changed: What|Removed |Added CC||edmar at freescale dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44067
[Bug c++/39437] Support for automatic linking via pragma
--- Comment #2 from olafvdspek at gmail dot com 2010-06-07 03:01 --- Would that be a problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39437
[Bug target/44067] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713
--- Comment #3 from gcc at breakpoint dot cc 2010-06-07 04:21 --- Thank you Alan. Trunk and 4.5 branch is affected, the 4.4 branch just built. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44067
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #22 from amodra at gmail dot com 2010-06-07 04:41 --- Adding the following to config/rs6000/e500.h will likely fix the bug. Testing.. #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \ (TARGET_E500_DOUBLE ((MODE) == DFmode || (MODE) == TFmode \ || (MODE) == DCmode || (MODE) == TCmode) \ ? (MODE) \ : choose_hard_reg_mode ((REGNO), (NREGS), false)) -- amodra at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-06-06 14:11:46 |2010-06-07 04:41:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug bootstrap/44437] New: 4.5 bootstrap failure on powerpc-linux
Wow I figured building on Linux would just work, even if not x86. uname -a: Linux plin 2.6.26-2-powerpc #1 Thu Feb 11 01:36:51 UTC 2010 ppc GNU/Linux /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o: In function `_start': (.text+0x20): relocation truncated to fit: R_PPC_REL24 against symbol `__libc_start_main@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o /usr/lib/gcc/powerpc-linux-gnu/4.3.2/crtbegin.o:(.fini+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' /usr/lib/gcc/powerpc-linux-gnu/4.3.2/crtend.o:(.init+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' c-lang.o: In function `VEC_tree_base_quick_insert': /home/jay/src/gcc-4.5.0/gcc/tree.h:182: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_base_ordered_remove': /home/jay/src/gcc-4.5.0/gcc/tree.h:182: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_base_block_remove': /home/jay/src/gcc-4.5.0/gcc/tree.h:182: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_gc_copy': /home/jay/src/gcc-4.5.0/gcc/tree.h:183: relocation truncated to fit: R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_gc_safe_grow_cleared': /home/jay/src/gcc-4.5.0/gcc/tree.h:183: relocation truncated to fit: R_PPC_REL24 against symbol `memset@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_heap_free': /home/jay/src/gcc-4.5.0/gcc/tree.h:184: relocation truncated to fit: R_PPC_REL24 against symbol `free@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_heap_copy': /home/jay/src/gcc-4.5.0/gcc/tree.h:184: relocation truncated to fit: R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_heap_safe_grow_cleared': /home/jay/src/gcc-4.5.0/gcc/tree.h:184: additional relocation overflows omitted from the output collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 make[3]: Leaving directory `/home/jay/obj/gcc45/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/jay/obj/gcc45' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/jay/obj/gcc45' make: *** [all] Error 2 j...@plin:~/obj/gcc45$ gcc -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-softfloat --enable-secureplt --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) j...@plin:~/obj/gcc45$ ld -V GNU ld (GNU Binutils for Debian) 2.18.0.20080103 Supported emulations: elf32ppclinux elf32ppc elf32ppcsim elf64ppc elf32_spu Presumably if I use a newer gcc/ld it will work. Or maybe without -g or with -O1 instead of -O2. -- Summary: 4.5 bootstrap failure on powerpc-linux Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44437
[Bug target/44319] -fzee is mishandled
--- Comment #1 from tmsriram at gcc dot gnu dot org 2010-06-07 05:25 --- Subject: Bug 44319 Author: tmsriram Date: Mon Jun 7 05:24:37 2010 New Revision: 160357 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160357 Log: 2010-06-06 Sriraman Tallam tmsri...@google.com PR target/44319 * config/i386/i386.c (override_options): Turn zee pass on for level 2 and above and defer till target is known. (optimization_options): Turn on zee pass if TARGET_64BIT is set and turn off otherwise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44319
[Bug regression/44281] Global Register variable pessimisation and regression
--- Comment #1 from adam at consulting dot net dot nz 2010-06-07 05:35
---
Example-specific workaround discovered for global register variable
pessimisation with recent versions of GCC:
void push_flag_into_global_reg_var(uint64_t a, uint64_t b) {
uint64_t flag = (a==b);
global_flag_stack = 8;
__asm__ __volatile__( : : : memory); /* ??? */
global_flag_stack |= flag;
}
Every version of GCC tested (including gcc (Debian 20100530-1) 4.6.0 20100530
(experimental) [trunk revision 160047]) produces similarly compact code:
00400494 push_flag_into_global_reg_var:
400494: 48 c1 e3 08 shlrbx,0x8
400498: 31 c0 xoreax,eax
40049a: 48 39 f7cmprdi,rsi
40049d: 0f 94 c0sete al
4004a0: 48 09 c3or rbx,rax
4004a3: c3 ret
Telling the compiler that memory may have changed between global register
variable assignments seems to have coaxed the compiler into treating the global
register variable as volatile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44281
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #23 from Kyle dot D dot Moffett at boeing dot com 2010-06-07 05:36 --- (In reply to comment #22) Adding the following to config/rs6000/e500.h will likely fix the bug. Testing.. Oh, very nice! Thanks for the speedy assistance on this! I've got my own test compiler building now; I'll let you know what the result is as soon as its done! Cheers, Kyle Moffett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #24 from Kyle dot D dot Moffett at boeing dot com 2010-06-07 05:44 --- Hmm, unfortunately in my preliminary testing this does not seem to fix either testcase. Cheers, Kyle Moffett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
