[Bug c++/42358] [C++0x] Assembler failure on libstdc++-v3/testsuite/23_containers/multimap/init-list.cc with -O0
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-13 14:57 --- Created an attachment (id=19282) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19282action=view) testcase Preprocessed source produced on i?86-linux. I'll try to auto-reduce it, the present one doesn't build with 4.4 so I'm not sure it's a regression or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42358
[Bug c++/42355] Segmentation fault
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-13 15:04 --- Please update to 4.4.2 at least. Without a testcase we can't do anything here. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
[Bug c++/42357] another ice in create_tmp_var
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-13 15:19 ---
The type is addressable and we're creating the temporary on behalf of
early SRA through force_gimple_operand_gsi.
VIEW_CONVERT_EXPRstruct PixelARGB(SR.9075)
it's not necessary to do this gimplification as the stmt is a struct copy
before:
2449 if (force_gimple_rhs)
2450rhs = force_gimple_operand_gsi (gsi, rhs, true, NULL_TREE,
2451true, GSI_SAME_STMT);
2452 if (gimple_assign_rhs1 (*stmt) != rhs)
2453{
2454 gimple_assign_set_rhs_from_tree (gsi, rhs);
(gdb) call debug_gimple_stmt (*stmt)
# .MEM_199 = VDEF .MEM_91
pixel.argb = D.93455.argb;
in fact, why the following looks wrong:
if (!useless_type_conversion_p (TREE_TYPE (lhs), TREE_TYPE (rhs)))
{
rhs = fold_build1_loc (loc, VIEW_CONVERT_EXPR, TREE_TYPE (lhs),
rhs);
if (!is_gimple_reg (lhs))
force_gimple_rhs = true;
it should check for is_gimple_reg_type (TREE_TYPE (lhs)) instead.
I'm reducing the testcase and check a patch to that effect.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-12-13 15:19:50
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42357
[Bug c++/42358] [C++0x] Assembler failure on libstdc++-v3/testsuite/23_containers/multimap/init-list.cc with -O0
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-13 15:32 --- Created an attachment (id=19283) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19283action=view) auto-reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42358
[Bug c++/42358] [4.5 Regression][C++0x] Assembler failure on libstdc++-v3/testsuite/23_containers/multimap/init-list.cc with -O0
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-13 15:34 --- 4.4.2 works with the reduced testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.4.2 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2009-12-13 15:34:12 date|| Summary|[C++0x] Assembler failure on|[4.5 Regression][C++0x] |libstdc++- |Assembler failure on |v3/testsuite/23_containers/m|libstdc++- |ultimap/init-list.cc with - |v3/testsuite/23_containers/m |O0 |ultimap/init-list.cc with - ||O0 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42358
[Bug c++/42357] another ice in create_tmp_var
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-13 16:04 ---
typedef unsigned char uint8;
typedef unsigned int uint32;
class PixelARGB {
public:
~PixelARGB() throw() { }
PixelARGB (const uint32 argb_) throw() : argb (argb_) { }
inline __attribute__((always_inline)) uint8 getRed() const throw() {
return components.r;
}
union {
uint32 argb;
struct {
uint8 b, g, r, a;
} components;
};
};
class Colour {
public:
Colour() throw() : argb (0) {};
uint8 getRed() const throw() {
return argb.getRed();
}
PixelARGB argb;
};
uint8 writeImage (void) {
Colour pixel;
pixel = Colour ();
return pixel.getRed();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42357
[Bug fortran/40568] F2008: C_SIZEOF is in the wrong scope, rejected as initialization expression
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-13 16:19 --- F2008 allows C_SIZEOF in initialization expressions: The definition for specification inquiry is in Fortran 2008 (7.1.11 Specification expression): A speci cation inquiry is a reference to (1) an intrinsic inquiry function, [...] (4) the function C_SIZEOF from the intrinsic module ISO C BINDING (15.2.3.7) Currently C_SIZEOF is rejected as init expression as it is not listed as valid inquiry function, neither is CLASS_INQUIRY in intrinsic.c(add_functions) set. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org OtherBugsDependingO||29962, 39627 nThis|| Summary|F2008: C_SIZEOF is in the |F2008: C_SIZEOF is in the |wrong scope |wrong scope, rejected as ||initialization expression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568
[Bug fortran/41298] wrong-code: Default initializer C_NULL_PTR ignored
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-12-13 16:22 --- While looking at this one, I found two oddities: * There are two similar special-case handlers for ISOCBINDING_NULL_[FUN]PTR, one in trans-expr.c(gfc_conv_initializer), the other in trans-const.c (gfc_conv_constant). They may be redundant? * Both these checks create a 'gfc_int_expr(0)' as replacement value, wouldn't a 'null_pointer_node' be technically more correct? I'm out of this one, trans-* is dark magic *uhhh* -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41298
[Bug fortran/42359] New: ICEs with specification function and init expression
$ cat ice-on-onvalid.f90 INTERFACE PURE INTEGER FUNCTION spec_func() END FUNCTION END INTERFACE INTEGER :: p(spec_func()) = 23 ! scalar initializer, works without IF (SIZE(p) /= 42) CALL abort() IF (ANY(p /= 23)) CALL abort() END PURE INTEGER FUNCTION spec_func() spec_func = 42 END FUNCTION $ gfortran-svn ice-on-valid.f90 ice-on-valid.f90: In function 'MAIN__': ice-on-valid.f90:3:0: internal compiler error: tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:4087 Please submit a full bug report If the initializer is an array, there's another ice ... $ cat ice-on-valid.f90 ! ice-on-valid in trans-array.c:4087 INTERFACE PURE INTEGER FUNCTION spec_func() END FUNCTION END INTERFACE INTEGER :: p(spec_func()) = (/ 23 /) ! array instead of scalar IF (SIZE(p) /= 42) CALL abort() IF (ANY(p /= 23)) CALL abort() END PURE INTEGER FUNCTION spec_func() spec_func = 42 END FUNCTION $ gfortran-svn ice-on-valid.f90 ice-on-valid.f90: In function 'MAIN__': ice-on-valid.f90:7:0: internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:4328 Please submit a full bug report $ gfortran-svn -v gcc version 4.5.0 20091212 (experimental) (GCC) -- Summary: ICEs with specification function and init expression Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42359
[Bug fortran/42360] New: intent(out)-dummy-not-set warning for types depends on order of component initializers
$ cat warning.f90 MODULE m TYPE :: t1 INTEGER :: a = 1 ! component with default initializer first INTEGER :: b END TYPE TYPE :: t2 INTEGER :: a ! component without default initializer first INTEGER :: b = 2 END TYPE CONTAINS SUBROUTINE sub1(x) type(t1), intent(out) :: x ! no warning END SUBROUTINE SUBROUTINE sub2(x) type(t2), intent(out) :: x ! warning END SUBROUTINE END MODULE $ $ gfortran-svn -Wall -c warning.f90 warning.f90:17.19: SUBROUTINE sub2(x) 1 Warning: Dummy argument 'x' at (1) was declared INTENT(OUT) but was not set $ gfortran-svn -v gcc version 4.5.0 20091212 (experimental) (GCC) As both types have components without default initializers, I'd expect a warning in both cases. -- Summary: intent(out)-dummy-not-set warning for types depends on order of component initializers Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42360
[Bug c++/42357] another ice in create_tmp_var
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-13 17:36 --- Subject: Bug 42357 Author: rguenth Date: Sun Dec 13 17:36:20 2009 New Revision: 155193 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155193 Log: 2009-12-13 Richard Guenther rguent...@suse.de PR tree-optimization/42357 * tree-sra.c (sra_modify_assign): Do not tear apart struct copies. * g++.dg/torture/pr42357.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr42357.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42357
[Bug tree-optimization/42357] [4.5 Regression] another ice in create_tmp_var
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-13 17:36 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |tree-optimization Keywords||ice-on-valid-code Known to work||4.4.2 Summary|another ice in |[4.5 Regression] another ice |create_tmp_var |in create_tmp_var Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42357
[Bug middle-end/41734] ICE in cgraph_mark_functions_to_output, at cgraphunit.c:1137 with -fwhopr
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-13 17:52 --- Re-confirmed with todays trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-10-16 23:02:04 |2009-12-13 17:52:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41734
[Bug other/39951] Dangling symlink .../include-fixed/mach created on install
--- Comment #1 from skunk at iskunk dot org 2009-12-13 20:09 --- This bug persists in 4.4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39951
[Bug fortran/42361] New: [Meta-bug] Serious Fortran bugs
This meta bug is for serious bugs (wrong-code, rejects-valid, ice-on-valid-code) which should be given a high priority. If the problem is already a Fortran 90/95 problem, please mark as blocking PR 32834 instead. This PR is here in order prioritize the gfortran work. Adding a huge number of PRs as dependency will defy this purpose and thus PR can also be removed if the impact is seen as low. The list should maximally contain about 10 to 20 unfixed PRs. If there are fewer, one can start adding new ones! -- Summary: [Meta-bug] Serious Fortran bugs Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 32834 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42361
[Bug rtl-optimization/23726] Missed optimizations for divmod
--- Comment #9 from hutchinsonandy at gcc dot gnu dot org 2009-12-13 21:03 --- Subject: Bug 23726 Author: hutchinsonandy Date: Sun Dec 13 21:03:41 2009 New Revision: 155195 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155195 Log: PR target/23726 * config/avr/predicates.md (pseudo_register_operand): New predicate for pseudos. * config/avr/avr.md (divmodqi4): Replace with define_insn_and_split to allow div/mod optimization. (udivmodqi4): Ditto. (divmodhi4): Ditto. (udivmodhi4): Ditto. (divmodsi4): Ditto. (udivmodsi4): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23726
[Bug rtl-optimization/23726] Missed optimizations for divmod
--- Comment #10 from hutchinsonandy at gcc dot gnu dot org 2009-12-13 21:05 --- Fixed 4.5 -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23726
[Bug fortran/42353] [OOP] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-13 21:09 --- One can get rid of this by making the vtypes private: Index: gcc/fortran/symbol.c === --- gcc/fortran/symbol.c(revision 155182) +++ gcc/fortran/symbol.c(working copy) @@ -4764,6 +4764,7 @@ gfc_find_derived_vtab (gfc_symbol *derived) return NULL; vtype-refs++; gfc_set_sym_referenced (vtype); + vtype-attr.access = ACCESS_PRIVATE; /* Add component '$hash'. */ if (gfc_add_component (vtype, $hash, c) == FAILURE) This patch fixes the error and is regression free. -- 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|2009-12-11 23:13:39 |2009-12-13 21:09:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
[Bug fortran/42353] [OOP] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-13 21:41 --- Btw, here is a reduced/modified test case which gives the same error: module m0 type :: t end type end module module m1a use m0 class(t), pointer :: c1 end module module m1b use m0 class(t), pointer :: c2 end module module m2 use m1a use m1b end module -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components
--- Comment #18 from janus at gcc dot gnu dot org 2009-12-13 21:51 --- r155024 contains the patch in comment #12, which fixes comment #9, but not the double free issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug tree-optimization/42027] [4.5 Regression] Performance regression in convolution loop optimization
--- Comment #6 from matz at gcc dot gnu dot org 2009-12-13 21:51 --- Subject: Bug 42027 Author: matz Date: Sun Dec 13 21:51:34 2009 New Revision: 155196 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155196 Log: PR tree-optimization/42027 * dojump.c (do_jump TRUTH_AND_EXPR, TRUTH_OR_EXPR): Go to TRUTH_ANDIF_EXPR resp. TRUTH_ORIF_EXPR expander, instead of falling through. Modified: trunk/gcc/ChangeLog trunk/gcc/dojump.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
[Bug tree-optimization/42027] [4.5 Regression] Performance regression in convolution loop optimization
--- Comment #7 from matz at gcc dot gnu dot org 2009-12-13 21:53 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
[Bug tree-optimization/42357] [4.5 Regression] another ice in create_tmp_var
--- Comment #6 from matz at gcc dot gnu dot org 2009-12-13 21:57 --- Mark it so. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42357
[Bug fortran/40629] Host association problem
--- Comment #6 from burnus at gcc dot gnu dot org 2009-12-13 22:05 --- Paul what is the status of this PR? I see a commit as last comment. Is this fixed? Is something missing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40629
[Bug debug/41806] G++ fails to compile a testcase with -fcompare-debug
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2009-12-13 22:06 --- This bug has disappeared. -- d dot g dot gorbachev at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41806
[Bug debug/41371] [4.5 Regression] -g causes compiler to hang
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-13 22:18 --- *** Bug 41264 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug middle-end/41264] [4.5 Regression] variable-tracking unbelievably slow
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-12-13 22:18 --- Mark as dup of a single vartracking is slow with VTA bug. *** This bug has been marked as a duplicate of 41371 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41264
[Bug debug/41371] [4.5 Regression] -g causes compiler to hang
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-13 22:18 --- Another testcase is attached to PR41264. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug tree-optimization/42211] [4.5 Regression] Segmentation fault with graphite -floop-interchange
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-13 22:20 --- *** This bug has been marked as a duplicate of 42178 *** -- 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=42211
[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-13 22:20 --- *** Bug 42211 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=42178
[Bug debug/42362] New: gdb stack crawl at point of internal error in WalkerTest
The dwarf debug code generated by gcj in gcc trunk is not backward compatible with the older gdb release used by Apple in darwin10. When compiled as... gcj WalkerTest.jar -w -bind_at_load -multiply_defined suppress -Wl,-allow_stack_execute --main=WalkerTest -g -lm -o WalkerTest.exe The resulting WalkerTest.exe binary from gcc trunk causes the following error in Apple's gdb... gdb ./WalkerTest.exeGNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC 2009) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-apple-darwin...Reading symbols for shared libraries .. done gdb stack crawl at point of internal error: 0 gdb-i386-apple-darwin 0x0001001076e7 internal_vproblem + 308 1 gdb-i386-apple-darwin 0x0001001078c1 internal_verror + 27 2 gdb-i386-apple-darwin 0x00010010795f align_down + 0 3 gdb-i386-apple-darwin 0x0001000b1fc4 find_partial_die_in_comp_unit + 79 4 gdb-i386-apple-darwin 0x0001000bd97f find_partial_die + 626 5 gdb-i386-apple-darwin 0x0001000bd9cc fixup_partial_die + 55 6 gdb-i386-apple-darwin 0x0001000be08d scan_partial_symbols + 58 7 gdb-i386-apple-darwin 0x0001000bef51 dwarf2_build_psymtabs + 2982 8 gdb-i386-apple-darwin 0x000100144af3 macho_symfile_read + 294 9 gdb-i386-apple-darwin 0x00010004bbb8 syms_from_objfile + 1401 10 gdb-i386-apple-darwin 0x00010004c601 symbol_file_add_with_addrs_or_offsets_using_objfile + 690 11 gdb-i386-apple-darwin 0x00010004c5bb symbol_file_add_with_addrs_or_offsets_using_objfile + 620 12 gdb-i386-apple-darwin 0x00010004c894 symbol_file_add_name_with_addrs_or_offsets + 117 13 gdb-i386-apple-darwin 0x00010004cd5c symbol_file_add_main_1 + 207 14 gdb-i386-apple-darwin 0x00010006e75d catch_command_errors + 65 /SourceCache/gdb/gdb-1346/src/gdb/dwarf2read.c:8233: internal-error: could not find partial DIE in cache A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n This error doesn't occur when the FSF gdb from the current gdb cvs is used. The problem also doesn't occur with Apple's gdb when the WalkerTest is compiled with the gcj from gcc 4.4.2. -- Summary: gdb stack crawl at point of internal error in WalkerTest Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42362
[Bug debug/42362] gdb stack crawl at point of internal error in WalkerTest
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-13 22:31 --- Sounds like this should be reported to Apple really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42362
[Bug debug/42362] gdb stack crawl at point of internal error in WalkerTest
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-12-13 22:34 --- Created an attachment (id=19284) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19284action=view) assembly from WalkerTest.jar in gcc trunk on x86_64-apple-darwin10 Generated with... gcj WalkerTest.jar -w -bind_at_load -multiply_defined suppress -Wl,-allow_stack_execute --main=WalkerTest --save-temps -g -lm -o WalkerTest.exe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42362
[Bug debug/42362] gdb stack crawl at point of internal error in WalkerTest
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-12-13 22:34 --- Created an attachment (id=19285) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19285action=view) assembly from WalkerTest.jar in gcc 4.4.2 on x86_64-apple-darwin10 Generated using... gcj WalkerTest.jar -w -bind_at_load -multiply_defined suppress -Wl,-allow_stack_execute --main=WalkerTest --save-temps -g -lm -o WalkerTest.exe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42362
[Bug debug/42362] gdb stack crawl at point of internal error in WalkerTest
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-13 22:36 --- Created an attachment (id=19286) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19286action=view) diff between assembly from gcc 4.4.2 and gcc trunk on x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42362
[Bug debug/42362] gdb stack crawl at point of internal error in WalkerTest
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-13 22:37 --- Using built-in specs. Reading specs from /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.2.0/4.5.0/../../../libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig COLLECT_GCC=gcj COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/lto-wrapper Target: x86_64-apple-darwin10.2.0 Configured with: ../gcc-4.5-20091211/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib Thread model: posix gcc version 4.5.0 20091212 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42362
[Bug debug/42362] gdb stack crawl at point of internal error in WalkerTest
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-12-13 22:41 --- (In reply to comment #1) Sounds like this should be reported to Apple really. True except that i recall some discussion of making at least a minimal effort to be backward compatible with older gdb's. This should at least cover making a cursory evaluation of the cause of the gdb crash and whether there is a simple fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42362
[Bug debug/42362] gdb stack crawl at point of internal error in WalkerTest
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-13 22:59 --- This isn't a gcc bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42362
[Bug libstdc++/40133] exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-linux
--- Comment #10 from doko at gcc dot gnu dot org 2009-12-13 23:45 --- Subject: Bug 40133 Author: doko Date: Sun Dec 13 23:45:12 2009 New Revision: 155200 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155200 Log: 2009-12-11 Paolo Carlini paolo.carl...@oracle.com Matthias Klose d...@ubuntu.com PR libstdc++/40133 * acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): On *-*-linux*, *-*-uclinux*, *-*-kfreebsd*-gnu | *-*-gnu* targets do link tests when possible. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #25 from matz at gcc dot gnu dot org 2009-12-13 23:48 --- The reason that the testcase still is slow (and that the inner loop isn't unrolled or vectorized) is still the calculation of countm1. The division therein stays in the second inner loop, whereas with GCC 4.3 it can be moved into the outer loop. In this specific testcase it's a pass ordering problem: we start with (at .vrp1) (only parts shown): bb 2: D.1564_45 = *n_9(D); if (D.1564_45 1) ... bb 6: D.1572_60 = *n_9(D); if (D.1572_60 0) goto bb 7; else goto bb 8; Here _45 and _60 are equivalent, but VRP doesn't know this, hence it doesn't detect the goto bb 8 as dead. The equivalence is only detected after PRE (not by PRE, though :-/ ), which means VRP2 does detect the jump as dead, and hence leaves only the step0 case in the code. But this is too late for the late PRE (running before VRP2 and the loop optimizers) in order to move the dependend division to the outer loop. As the division isn't moved as loop invariant to the outer loop this also means that the loop count determination doesn't work, hence no unrolling. But the slowness itself is due to the div instruction in the second loop, instead of in the outer loop as with 4.3. -- matz at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug middle-end/42363] New: [4.5 Regression] ICE: verify_flow_info failed for gcc.c-torture/compile/pr37913.c -O1 -g
/obj/trunk-g/gcc/xgcc -B/obj/trunk-g/gcc/ -O1 -w -c -g -o pr37913.o /home/richard/src/trunk/gcc/testsuite/gcc.c-torture/compile/pr37913.c^M /home/richard/src/trunk/gcc/testsuite/gcc.c-torture/compile/pr37913.c: In function 'baz':^M /home/richard/src/trunk/gcc/testsuite/gcc.c-torture/compile/pr37913.c:15:1: error: control flow in the middle of basic block 2^M /home/richard/src/trunk/gcc/testsuite/gcc.c-torture/compile/pr37913.c:15:1: internal compiler error: verify_flow_info failed^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^M from http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01178.html (the gcc.dg/tree-ssa/ltrans-*.c FAILs look like compare-debug issues to me). -- Summary: [4.5 Regression] ICE: verify_flow_info failed for gcc.c- torture/compile/pr37913.c -O1 -g Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end 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=42363
[Bug middle-end/42363] [4.5 Regression] ICE: verify_flow_info failed for gcc.c-torture/compile/pr37913.c -O1 -g
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42363
[Bug middle-end/42363] [4.5 Regression] ICE: verify_flow_info failed for gcc.c-torture/compile/pr37913.c -O1 -g
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-14 00:06 --- Happens after copyprop. (gdb) call debug_bb (bb) ;; basic block 2, loop depth 0, count 0 ;; prev block 0, next block 1 ;; pred: ENTRY (fallthru,exec) ;; succ: bb 2: i_1 = bar (); # DEBUG i = i_1 we have a DEBUG stmt after a noreturn call. Or rather it happens at into-SSA time already. We just don't verify flow-info very often. Thus the initial insertion happens at the wrong place already. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42363
[Bug middle-end/42363] [4.5 Regression] ICE: verify_flow_info failed for gcc.c-torture/compile/pr37913.c -O1 -g
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-14 00:07 --- Of course the LHS is never assigned to so the debug stmt is useless and we should refrain from inserting it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42363
[Bug c++/42364] New: C++ testsuite fails with -g
http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01178.html Running target unix/-g FAIL: g++.dg/charset/function.cc scan-assembler-not foobar FAIL: g++.dg/cpp0x/variadic31.C (internal compiler error) FAIL: g++.dg/cpp0x/variadic31.C (test for excess errors) FAIL: g++.dg/cpp0x/variadic32.C (internal compiler error) FAIL: g++.dg/cpp0x/variadic32.C (test for excess errors) FAIL: g++.dg/cpp0x/variadic42.C (internal compiler error) FAIL: g++.dg/cpp0x/variadic42.C (test for excess errors) ERROR: g++.dg/cpp0x/variadic42.C: error executing dg-final: couldn't open variadic42.s: no such file or directory UNRESOLVED: g++.dg/cpp0x/variadic42.C: error executing dg-final: couldn't open variadic42.s: no such file or directory FAIL: g++.dg/cpp0x/variadic66.C (internal compiler error) FAIL: g++.dg/cpp0x/variadic66.C (test for excess errors) FAIL: g++.dg/cpp0x/variadic80.C (internal compiler error) FAIL: g++.dg/cpp0x/variadic80.C (test for excess errors) WARNING: g++.dg/cpp0x/variadic80.C compilation failed to produce executable FAIL: g++.dg/ext/attrib33.C (internal compiler error) FAIL: g++.dg/ext/attrib33.C (test for excess errors) -- Summary: C++ testsuite fails with -g Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ 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=42364
[Bug libstdc++/40133] exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-linux
--- Comment #11 from debian-gcc at lists dot debian dot org 2009-12-14 00:19 --- fixed on the trunk -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133
[Bug target/40134] symbols not resolved when building shared libraries (link with -lgcc_s -lgcc?)
--- Comment #5 from debian-gcc at lists dot debian dot org 2009-12-14 00:21 --- fixed on the trunk -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134
[Bug c++/42356] confused compiler
--- Comment #2 from igodard at pacbell dot net 2009-12-14 04:51 --- Well, I see several issues with the diagnostics. 1) The call is not ambiguous, because if it were (only) ambiguous then removing the base baz would disambiguate. Instead the case without baz gets you: s3:~/ootbc/memspec$ g++ foo.cc foo.cc: In function int main(): foo.cc:27: error: no matching function for call to foo::newNode() That is, a call cannot be both ambiguous and have no matching function. 2) The reported list of overloads include those which have the wrong number of arguments. 3) The diagnostic contains freeList::newNode(U, V) [with U = U, V = V, T = bar] as the call citation, which makes it look like the local U matches a (non-existent in this case) global U and local V matches a global V, the way that local T matches global bar. Perhaps it could say something like freeList::newNode(U, V) [with U = ?, V = ?, T = bar] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #26 from matz at gcc dot gnu dot org 2009-12-14 04:55 --- And if I fix this problem (so that only one reference to *n_9) remains I hit the problem that the fortran frontend emits the computation of countm1 after the loop bound test. No pass is moving code in front of that test as this is potentially a regression (more evaluations in out-of-bound case). And if I fix _that_ I hit the problem of the fix for PR38819. PRE won't move the division at all, because it could trap :-/ If I disable this I get back the 4.3 performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug fortran/40629] Host association problem
--- Comment #7 from pault at gcc dot gnu dot org 2009-12-14 05:20 --- (In reply to comment #6) Paul what is the status of this PR? I see a commit as last comment. Is this fixed? Is something missing? From everything that I can see, it is fixed. Thanks for the reminder. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40629
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #27 from matz at gcc dot gnu dot org 2009-12-14 05:25 --- Created an attachment (id=19287) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19287action=view) three hacks My current collection of patches and hacks for this problem. Obviously the if (0) in tree-ssa-pre.c will break pr38819 again; apart from that untested, hence probably miscompiles everything except this testcase here :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug bootstrap/42365] New: -march=native -mfpmath=sse leads to bootstrap failure
My cpu is an amd athlon II 240 and My CFLAGS is -O3 -pipe -march=sse -mfpmath=sse -mveclibabi=svml, All went ok until compile libgomp multilib 32 bit. the compiling message is : /bin/sh ./libtool --tag=CC --mode=compile /home/xhs/build/gcc/./gcc/xgcc -B/home/xhs/build/gcc/./gcc/ -B/gcc-4.5/gcc-4.5/x86_64-unknown-linux-gnu/bin/ -B/gcc-4.5/gcc-4.5/x86_64-unknown-linux-gnu/lib/ -isystem /gcc-4.5/gcc-4.5/x86_64-unknown-linux-gnu/include -isystem /gcc-4.5/gcc-4.5/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I/svn/compilers/gcc/libgomp -I/svn/compilers/gcc/libgomp/config/linux/x86 -I/svn/compilers/gcc/libgomp/config/linux -I/svn/compilers/gcc/libgomp/config/posix -I/svn/compilers/gcc/libgomp -Wall -Werror -ftls-model=initial-exec -march=i486 -mtune=i686 -Wc,-pthread -march=native -mfpmath=sse -mveclibabi=svml -pipe -O3 -pthread -m32 -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c -o alloc.lo /svn/compilers/gcc/libgomp/alloc.c libtool: compile: /home/xhs/build/gcc/./gcc/xgcc -B/home/xhs/build/gcc/./gcc/ -B/gcc-4.5/gcc-4.5/x86_64-unknown-linux-gnu/bin/ -B/gcc-4.5/gcc-4.5/x86_64-unknown-linux-gnu/lib/ -isystem /gcc-4.5/gcc-4.5/x86_64-unknown-linux-gnu/include -isystem /gcc-4.5/gcc-4.5/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I/svn/compilers/gcc/libgomp -I/svn/compilers/gcc/libgomp/config/linux/x86 -I/svn/compilers/gcc/libgomp/config/linux -I/svn/compilers/gcc/libgomp/config/posix -I/svn/compilers/gcc/libgomp -Wall -Werror -ftls-model=initial-exec -march=i486 -pthread -mtune=i686 -march=native -mfpmath=sse -mveclibabi=svml -pipe -O3 -pthread -m32 -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c /svn/compilers/gcc/libgomp/alloc.c -fPIC -DPIC -o .libs/alloc.o and the error message Is cc1: warnings being treated as errors /svn/compilers/gcc/libgomp/alloc.c:1:0: error: SSE instruction set disabled, using 387 arithmetics make[6]: *** [alloc.lo] Error 1 make[5]: *** [all-recursive] Error 1 make[4]: *** [all] Error 2 make[3]: *** [multi-do] Error 1 make[2]: *** [all-multi] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 It seems that Makefile added a -march=i486 -pthread -mtune=i686 option which leads to bootstrap error. -- Summary: -march=native -mfpmath=sse leads to bootstrap failure Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linuxl4 at sohu dot com GCC build triplet: amd64_Linux GCC host triplet: amd64_Linux GCC target triplet: amd64_Linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42365
[Bug bootstrap/42365] -march=native -mfpmath=sse leads to bootstrap failure
--- Comment #1 from linuxl4 at sohu dot com 2009-12-14 05:52 --- Sorry, My CFLAGS is My CFLAGS is -O3 -pipe -march=native -mfpmath=sse -mveclibabi=svml -- linuxl4 at sohu dot com changed: What|Removed |Added Summary|-march=native -mfpmath=sse |-march=native -mfpmath=sse |leads to bootstrap failure |leads to bootstrap failure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42365
[Bug libstdc++/42352] -std=c++0x reference binding problem
--- Comment #12 from rwgk at yahoo dot com 2009-12-14 06:05 ---
(In reply to comment #10)
What do you mean by of this type? As I tried already to explain, until the
ISO C++ Committee resolves DR 1133 we cannot touch list::merge and
list::splice.
Sorry, I wasn't looking carefully enough. The remaining errors are indeed
different. Reduced below.
If I comment out all .splice() in our code everything else compiles.
The DR details are over my head, I'm afraid. Does cannot touch mean we are
stuck with a broken list.splice() and .merge() for now, until the standards
committee has made changes?
#include list
void work()
{
std::listint l, m;
l.splice(l.end(), m);
}
% g++ -c -std=c++0x ~/gcc_bugs/list_splice_bind.cpp
/net/cci/rwgk/gcc_bugs/list_splice_bind.cpp: In function 'void work()':
/net/cci/rwgk/gcc_bugs/list_splice_bind.cpp:6:21: error: cannot bind
'std::listint' lvalue to 'std::listint'
/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_155182_fc12_x86_64/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stl_list.h:1154:7:
error: initializing argument 2 of 'void std::list_Tp,
_Alloc::splice(std::list_Tp, _Alloc::iterator, std::list_Tp, _Alloc)
[with _Tp = int, _Alloc = std::allocatorint, std::list_Tp, _Alloc::iterator
= std::_List_iteratorint, std::list_Tp, _Alloc = std::listint]'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
