[Bug other/34835] New: splay-tree doesn't support 64bit value on 32bit host
splay-tree.h has #ifndef _WIN64 typedef unsigned long int libi_uhostptr_t; typedef long int libi_shostptr_t; #else typedef unsigned long long libi_uhostptr_t; typedef long long libi_shostptr_t; #endif ... /* Use typedefs for the key and data types to facilitate changing these types, if necessary. These types should be sufficiently wide that any pointer or scalar can be cast to these types, and then cast back, without loss of precision. */ typedef libi_uhostptr_t splay_tree_key; typedef libi_uhostptr_t splay_tree_value; The problem is on 32bit host libi_uhostptr_t is defined as long and it don't work long long, which is used by BFD and leads to the linker bug: http://www.sourceware.org/bugzilla/show_bug.cgi?id=5303 -- Summary: splay-tree doesn't support 64bit value on 32bit host Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34835
[Bug middle-end/34812] New: [4.3 Regression] gcc.dg/Warray-bounds.c
Revision 131565 generates: FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 59) FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 65) FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 66) Revision 131501 is OK. -- Summary: [4.3 Regression] gcc.dg/Warray-bounds.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34812
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #8 from hjl at lucon dot org 2008-01-16 16:16 --- It isn't fixed. The error went from as to ld: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/bb-reorg.c -O2 -freorder-blocks-and-partition -fprofile-use -D_PROFILE_USE -fno-show-column -lm -o /export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gcc/bb-reorg.x02 (timeout = 300) /usr/local/bin/ld: error in /tmp/ccoylUaf.o(.eh_frame); no .eh_frame_hdr table will be created.^M output is: /usr/local/bin/ld: error in /tmp/ccoylUaf.o(.eh_frame); no .eh_frame_hdr table will be created.^M FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE I am using the Linux binutils 2.18.50.0.3. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #11 from hjl at lucon dot org 2008-01-16 18:23 --- (In reply to comment #9) GNU ld version 2.17.50.0.3-6 20060715 Your linker doesn't issue the error since it is too old. See http://sourceware.org/bugzilla/show_bug.cgi?id=4454 -- hjl at lucon dot org changed: What|Removed |Added Last reconfirmed|2008-01-14 17:16:25 |2008-01-16 18:23:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug debug/34249] [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #13 from hjl at lucon dot org 2008-01-16 20:17 --- (In reply to comment #12) Created an attachment (id=14949) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14949action=view) [edit] Patch to fix issue in Comment #8 H.J, could you test if attached patch fixes the problem from Comment #8? Yes, it works: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00695.html -- hjl at lucon dot org changed: What|Removed |Added Last reconfirmed|2008-01-16 18:23:05 |2008-01-16 20:17:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug tree-optimization/34769] New: [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c
On Linux/Intel64, with revision 131442, I got Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/no-vfa-pr29145.c -ftree-vectorize -fno-vect-cost-model -msse2 -O2 -fdump-tree-vect-details --param vect-max-version-for-alias-checks=0 -fno-show-column -lm -m32 -o ./no-vfa-pr29145.exe(timeout = 300) PASS: gcc.dg/vect/no-vfa-pr29145.c (test for excess errors) FAIL: gcc.dg/vect/no-vfa-pr29145.c execution test FAIL: gcc.dg/vect/no-vfa-pr29145.c scan-tree-dump-times vect vectorized 0 loops 2 FAIL: gcc.dg/vect/no-vfa-pr29145.c scan-tree-dump-times vect vectorized 1 loops 1 Revision 131403 is OK. -- Summary: [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c
--- Comment #1 from hjl at lucon dot org 2008-01-13 16:25 --- Revision 131429: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00367.html -- hjl at lucon dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org OtherBugsDependingO||34458 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c
--- Comment #2 from hjl at lucon dot org 2008-01-13 16:26 --- Revision 131429 is the cause. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c
--- Comment #3 from hjl at lucon dot org 2008-01-13 16:31 --- This bug may only happen when you compile for 32bit on 64bit host. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
[Bug fortran/33375] ICE (segfault) gfortran.dg/common_6.f90
--- Comment #11 from hjl at lucon dot org 2008-01-08 13:56 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00294.html -- hjl at lucon dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||01/msg00294.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375
[Bug target/34709] [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64
--- Comment #3 from hjl at lucon dot org 2008-01-08 18:01 ---
(In reply to comment #2)
(In reply to comment #1)
No idea if Uros has access to spec, so maybe you can quote the snippet where
rsqrtss is used from the assembly of 481.wrf?
Unfortunatelly no... does this patch help:
Index: i386.c
===
--- i386.c (revision 131392)
+++ i386.c (working copy)
@@ -21449,7 +21449,7 @@ static tree
ix86_builtin_reciprocal (unsigned int fn, bool md_fn,
bool sqrt ATTRIBUTE_UNUSED)
{
- if (! (TARGET_SSE_MATH !optimize_size
+ if (! (TARGET_SSE_MATH TARGET_RECIP !optimize_size
flag_finite_math_only !flag_trapping_math
flag_unsafe_math_optimizations))
return NULL_TREE;
It works.
BTW: What happens if -mrecip is used to compile 481.wrf?
I will give it a try.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
[Bug target/34709] [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64
--- Comment #4 from hjl at lucon dot org 2008-01-08 18:24 --- (In reply to comment #2) BTW: What happens if -mrecip is used to compile 481.wrf? -O2 -mrecip -ffast-math miscompiles 481.wrf on Linux/Intel64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
[Bug target/34709] New: [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64
This patch http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00191.html miscompiled 481.wrf in SPEC CPU 2006 on Linux/Intel64 with -O2 -ffast-math. The resulting 481.wrf segfaulted. -- Summary: [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
[Bug fortran/33375] ICE (segfault) gfortran.dg/common_6.f90
--- Comment #9 from hjl at lucon dot org 2008-01-07 22:57 ---
We are processing common block symbols which we have rejected/freed before.
This patch works for me:
Index: symbol.c
===
--- symbol.c(revision 131352)
+++ symbol.c(working copy)
@@ -2726,14 +2726,14 @@ gfc_commit_symbol (gfc_symbol *sym)
/* Recursive function that deletes an entire tree and all the common
head structures it points to. */
-static void
-free_common_tree (gfc_symtree * common_tree)
+void
+gfc_free_common_tree (gfc_symtree * common_tree)
{
if (common_tree == NULL)
return;
- free_common_tree (common_tree-left);
- free_common_tree (common_tree-right);
+ gfc_free_common_tree (common_tree-left);
+ gfc_free_common_tree (common_tree-right);
gfc_free (common_tree);
}
@@ -2863,7 +2863,7 @@ gfc_free_namespace (gfc_namespace *ns)
free_sym_tree (ns-sym_root);
free_uop_tree (ns-uop_root);
- free_common_tree (ns-common_root);
+ gfc_free_common_tree (ns-common_root);
for (cl = ns-cl_list; cl; cl = cl2)
{
Index: gfortran.h
===
--- gfortran.h (revision 131352)
+++ gfortran.h (working copy)
@@ -2137,6 +2137,7 @@ int gfc_symbols_could_alias (gfc_symbol
void gfc_undo_symbols (void);
void gfc_commit_symbols (void);
void gfc_commit_symbol (gfc_symbol *);
+void gfc_free_common_tree (gfc_symtree *);
void gfc_free_namespace (gfc_namespace *);
void gfc_symbol_init_2 (void);
Index: match.c
===
--- match.c (revision 131352)
+++ match.c (working copy)
@@ -2956,6 +2956,8 @@ done:
return MATCH_YES;
syntax:
+ gfc_free_common_tree (gfc_current_ns-common_root);
+ gfc_current_ns-common_root = NULL;
gfc_syntax_error (ST_COMMON);
cleanup:
I don't know if it is 100% correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375
[Bug fortran/34689] New: [4.3 Regression] libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors)
On Linux/Intel64, revision 131352 has FAIL: libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors) FAIL: libgomp.fortran/appendix-a/a.38.1.f90 -O (test for excess errors) FAIL: libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors) FAIL: libgomp.fortran/appendix-a/a.38.1.f90 -O (test for excess errors) Revision 131341 is OK. -- Summary: [4.3 Regression] libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34689
[Bug fortran/34690] New: gfortran.dg/elemental_args_check_2.f90 doesn't work
On Linux/Intel64, I got FAIL: gfortran.dg/elemental_args_check_2.f90 -O (test for errors, line 14) FAIL: gfortran.dg/elemental_args_check_2.f90 -O (test for excess errors) with revision 131352. -- Summary: gfortran.dg/elemental_args_check_2.f90 doesn't work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34690
[Bug fortran/34693] New: [4.3 Regression] gfortran.dg/common_6.f90 -O
On Linux/Intel64, revision 131362 gives FAIL: gfortran.dg/common_6.f90 -O (internal compiler error) FAIL: gfortran.dg/common_6.f90 -O (test for excess errors) Revision 131352 is OK. -- Summary: [4.3 Regression] gfortran.dg/common_6.f90 -O Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34693
[Bug fortran/34693] [4.3 Regression] gfortran.dg/common_6.f90 -O
--- Comment #1 from hjl at lucon dot org 2008-01-06 21:47 --- It may be introduced by the fix for bug 34658. -- hjl at lucon dot org changed: What|Removed |Added OtherBugsDependingO||34658 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34693
[Bug fortran/34693] [4.3 Regression] gfortran.dg/common_6.f90 -O
--- Comment #3 from hjl at lucon dot org 2008-01-06 21:54 --- Why didn't I see it with revision 131352? -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34693
[Bug fortran/33375] ICE (segfault) gfortran.dg/common_6.f90
--- Comment #7 from hjl at lucon dot org 2008-01-07 04:57 ---
gfc_undo_symbols has
for (p = changed_syms; p; p = q)
{
q = p-tlink;
if (p-new)
{
/* Symbol was new. */
delete_symtree (p-ns-sym_root, p-name);
p-refs--;
if (p-refs 0)
gfc_internal_error (gfc_undo_symbols(): Negative refs);
if (p-refs == 0)
gfc_free_symbol (p);
continue;
}
P is freed. But it still accessible by resolve_common_vars somehow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375
[Bug libffi/34612] libffi doesn't work with -fomit-frame-pointer on ia32
-- hjl at lucon dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34612
[Bug tree-optimization/34534] Multiple gcc.dg/struct/wo_prof_xxxx execution failures
--- Comment #7 from hjl at lucon dot org 2007-12-30 15:45 --- (In reply to comment #4) So I wonder whether this test works correctly even without -fipa-struct-reorg. Would you please try to compile it with all other options (-O3 -fdump-ipa-all -fwhole-program -combine -fipa-type-escape) and run it on your machine? It works fine: [EMAIL PROTECTED] gcc]$ /export/build/gnu/gcc/build-ia64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-ia64-linux/gcc/ /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_global_var.c -O3 -fdump-ipa-all -fwhole-program -combine -fipa-type-escape -fno-show-column -lm -o ./wo_prof_global_var.exe [EMAIL PROTECTED] gcc]$ ./wo_prof_global_var.exe [EMAIL PROTECTED] gcc]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
[Bug tree-optimization/34534] Multiple gcc.dg/struct/wo_prof_xxxx execution failures
--- Comment #8 from hjl at lucon dot org 2007-12-30 15:49 --- Created an attachment (id=14844) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14844action=view) Dump files without -fipa-struct-reorg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
[Bug libffi/34612] libffi doesn't work with -fomit-frame-pointer on ia32
--- Comment #1 from hjl at lucon dot org 2007-12-29 15:03 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-12/msg01161.html -- hjl at lucon dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||12/msg01161.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34612
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #16 from hjl at lucon dot org 2007-12-29 16:20 --- I think this is related to PR 34472 and PR 34534 -- hjl at lucon dot org changed: What|Removed |Added BugsThisDependsOn||34472, 34534 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug libffi/34612] New: libffi doesn't work with -fomit-frame-pointer
[EMAIL PROTECTED] testsuite]$ /export/build/gnu/gcc-stack/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-stack/build-i686-linux/gcc/ /net/gnu-6/export/gnu/src/gcc-stack/gcc/libffi/testsuite/libffi.call/cls_16byte.c -Os -I/export/build/gnu/gcc-stack/build-i686-linux/i686-pc-linux-gnu/./libffi/include -I/net/gnu-6/export/gnu/src/gcc-stack/gcc/libffi/testsuite/../include -I/export/build/gnu/gcc-stack/build-i686-linux/i686-pc-linux-gnu/./libffi/include/.. -L/export/build/gnu/gcc-stack/build-i686-linux/i686-pc-linux-gnu/./libffi/.libs -L/export/build/gnu/gcc-stack/build-i686-linux/i686-pc-linux-gnu/./libstdc++-v3/src/.libs -lffi -lm -o ./cls_16byte.exe -Wl,-rpath,../.libs [EMAIL PROTECTED] testsuite]$ ./cls_16byte.exe 7 8 9 1 9 3: 8 17 12 res: 8 17 12 7 8 9 1 9 3: 8 17 12 res: 8 17 12 [EMAIL PROTECTED] testsuite]$ /export/build/gnu/gcc-stack/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-stack/build-i686-linux/gcc/ /net/gnu-6/export/gnu/src/gcc-stack/gcc/libffi/testsuite/libffi.call/cls_16byte.c -Os -I/export/build/gnu/gcc-stack/build-i686-linux/i686-pc-linux-gnu/./libffi/include -I/net/gnu-6/export/gnu/src/gcc-stack/gcc/libffi/testsuite/../include -I/export/build/gnu/gcc-stack/build-i686-linux/i686-pc-linux-gnu/./libffi/include/.. -L/export/build/gnu/gcc-stack/build-i686-linux/i686-pc-linux-gnu/./libffi/.libs -L/export/build/gnu/gcc-stack/build-i686-linux/i686-pc-linux-gnu/./libstdc++-v3/src/.libs -lffi -lm -o ./cls_16byte.exe -Wl,-rpath,../.libs -fomit-frame-pointer [EMAIL PROTECTED] testsuite]$ ./cls_16byte.exe 7 8 9 1 9 3: 8 17 12 res: 8 17 12 7 8 9 1 9 3: 8 17 12 Segmentation fault [EMAIL PROTECTED] testsuite]$ That is because libffi fails to keep stack pointer unchanged after calling function with structure return value, many libffi test case will fail with -fomit-frame-pointer on ia32. -- Summary: libffi doesn't work with -fomit-frame-pointer Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34612
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #5 from hjl at lucon dot org 2007-12-27 16:56 --- Any update on this? -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug tree-optimization/34458] [4.3 Regression] ICE in int_cst_value, at tree.c:8047 at -O3
--- Comment #8 from hjl at lucon dot org 2007-12-28 01:23 --- I believe revision 125030: http://gcc.gnu.org/ml/gcc-cvs/2007-05/msg00730.html http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01061.html is the cause. -- hjl at lucon dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34458
[Bug c++/34539] New: [4.3 Regression]: Extra libmudflap.c++ failures
Between revision 130941 and revision 131009, there are extra libmudflap failures: +FAIL: libmudflap.c++/fail24-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/fail24-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/fail24-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/fail24-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/fail24-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass27-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass27-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass27-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass27-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass27-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass28-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass28-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass28-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass28-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass28-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass31-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass31-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass31-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass31-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass31-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass41-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass41-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass41-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass41-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass41-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass55-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass55-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass55-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass55-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass55-frag.cxx (test for excess errors) +FAIL: libmudflap.c++/pass57-frag.cxx (-O2) (test for excess errors) +FAIL: libmudflap.c++/pass57-frag.cxx (-O3) (test for excess errors) +FAIL: libmudflap.c++/pass57-frag.cxx ( -O) (test for excess errors) +FAIL: libmudflap.c++/pass57-frag.cxx (-static) (test for excess errors) +FAIL: libmudflap.c++/pass57-frag.cxx (test for excess errors) It happens on Linux/ia32, Linux/Intel64 and Linux/ia64. -- Summary: [4.3 Regression]: Extra libmudflap.c++ failures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34539
[Bug tree-optimization/34534] Multiple gcc.dg/struct/wo_prof_xxxx execution failures
--- Comment #2 from hjl at lucon dot org 2007-12-20 17:45 --- Created an attachment (id=14802) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14802action=view) Dump files Starting program: /export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gcc/a.out Program received signal SIGSEGV, Segmentation fault. 0x4751 in main () at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_global_var.c:22 22 p[i].a = p[i].b + 1; (gdb) p/x $pc $4 = 0x4751 (gdb) disass 0x4740 0x4752 Dump of assembler code from 0x4740 to 0x4752: 0x4740 main+192: [MII] shladd r15=r16,2,r0 0x4741 main+193: adds r16=1,r16;; 0x4742 main+194: add r14=r33,r15 0x4750 main+208: [MMI] add r15=r8,r15;; 0x4751 main+209: ldfs f6=[r14] End of assembler dump. (gdb) p/x $r14 $5 = 0x5f60 (gdb) ldfs f6=[r14] loads memory at r14 into FP register f6. It looks that -fipa-struct-reorg miscompiles the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
[Bug tree-optimization/34534] Multiple gcc.dg/struct/wo_prof_xxxx execution failures
--- Comment #3 from hjl at lucon dot org 2007-12-21 00:25 --- I configured gcc with --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld \ --enable-shared \ --enable-threads=posix \ --enable-haifa \ --enable-checking=assert \ --prefix=/usr/gcc-4.3 \ --with-local-prefix=/usr/local -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
[Bug tree-optimization/34472] gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work
--- Comment #5 from hjl at lucon dot org 2007-12-20 00:15 --- (In reply to comment #4) Thank you for debugging! Now I see approximately where it fails. Although I am not sure that the following patch solves the issue, please try it, and let me know whether it helps. Thank you a lot, Olga Index: ipa-struct-reorg.c === --- ipa-struct-reorg.c (revision 130906) +++ ipa-struct-reorg.c (working copy) @@ -3068,6 +3068,17 @@ dump_access_sites (str-accs); } Yes, it works for me on both Intel64 and ia64. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34472
[Bug tree-optimization/34534] New: Multiple gcc.dg/struct/wo_prof_xxxx execution failures
On Linux/ia64, I saw FAIL: gcc.dg/struct/wo_prof_global_var.c execution test FAIL: gcc.dg/struct/wo_prof_local_var.c execution test FAIL: gcc.dg/struct/wo_prof_mult_field_peeling.c execution test FAIL: gcc.dg/struct/wo_prof_two_strs.c execution test They are run-time failures. -- Summary: Multiple gcc.dg/struct/wo_prof_ execution failures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
[Bug tree-optimization/34472] gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work
--- Comment #2 from hjl at lucon dot org 2007-12-17 19:04 ---
Created an attachment (id=14786)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14786action=view)
Dump files.
Here are dump files. I think there may be some memory corruptions:
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f98be6b5bc4201f3bb3844a43442bc6b
Program received signal SIGSEGV, Segmentation fault.
0x0080ae61 in safe_cond_expr_check (slot=0x10384c0, data=0x7fb254)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/ipa-struct-reorg.c:3081
3081 if (TREE_CODE (acc-stmt) == COND_EXPR)
(gdb) list
3076static int
3077safe_cond_expr_check (void **slot, void *data)
3078{
3079 struct access_site *acc = *(struct access_site **) slot;
3080
3081 if (TREE_CODE (acc-stmt) == COND_EXPR)
3082{
3083 if (!is_safe_cond_expr (acc-stmt))
3084{
3085 if (dump_file)
(gdb) p acc
$1 = (struct access_site *) 0x70
(gdb) bt
#0 0x0080ae61 in safe_cond_expr_check (slot=0x10384c0,
data=0x7fb254)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/ipa-struct-reorg.c:3081
#1 0x00ab5c8c in htab_traverse_noresize (htab=0x103fba0,
callback=0x80ae42 safe_cond_expr_check, info=0x7fb254)
at /net/gnu-13/export/gnu/src/gcc/gcc/libiberty/hashtab.c:750
#2 0x00ab5cfb in htab_traverse (htab=0x103fba0,
callback=0x80ae42 safe_cond_expr_check, info=0x7fb254)
at /net/gnu-13/export/gnu/src/gcc/gcc/libiberty/hashtab.c:765
#3 0x0080bd49 in check_cond_exprs ()
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/ipa-struct-reorg.c:3547
#4 0x0080c535 in collect_data_accesses ()
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/ipa-struct-reorg.c:3830
#5 0x0080c71a in reorg_structs ()
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/ipa-struct-reorg.c:3944
#6 0x0080c739 in reorg_structs_drive ()
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/ipa-struct-reorg.c:3967
#7 0x005e2530 in execute_one_pass (pass=0xf307a0)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/passes.c:1118
#8 0x005e26ef in execute_ipa_pass_list (pass=0xf307a0)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/passes.c:1187
#9 0x007fa210 in ipa_passes ()
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/cgraphunit.c:1339
BTW, I configured gcc with --enable-checking=assert.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34472
[Bug tree-optimization/34472] gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work
--- Comment #3 from hjl at lucon dot org 2007-12-17 19:08 --- Valgrind reports: ==20091== Invalid read of size 8 ==20091==at 0x964769: htab_traverse_noresize (hashtab.c:749) ==20091==by 0x747B6B: reorg_structs_drive (ipa-struct-reorg.c:3547) ==20091==by 0x584BF1: execute_one_pass (passes.c:1118) ==20091==by 0x5850B3: execute_ipa_pass_list (passes.c:1187) ==20091==by 0x73ADAD: cgraph_optimize (cgraphunit.c:1339) ==20091==by 0x410AAA: c_write_global_declarations (c-decl.c:8077) ==20091==by 0x5FA23B: toplev_main (toplev.c:1055) ==20091==by 0x39A0A1DAB3: (below main) (in /lib64/libc-2.6.so) ==20091== Address 0x8E70F68 is 24 bytes inside a block of size 104 free'd ==20091==at 0x4A055AB: free (vg_replace_malloc.c:233) ==20091==by 0x964F85: htab_expand (hashtab.c:550) ==20091==by 0x965002: htab_traverse (hashtab.c:763) ==20091==by 0x743D33: free_data_struct (ipa-struct-reorg.c:1674) ==20091==by 0x743E0D: remove_structure (ipa-struct-reorg.c:2353) ==20091==by 0x743F0A: safe_cond_expr_check (ipa-struct-reorg.c:3090) ==20091==by 0x964777: htab_traverse_noresize (hashtab.c:750) ==20091==by 0x747B6B: reorg_structs_drive (ipa-struct-reorg.c:3547) ==20091==by 0x584BF1: execute_one_pass (passes.c:1118) ==20091==by 0x5850B3: execute_ipa_pass_list (passes.c:1187) ==20091==by 0x73ADAD: cgraph_optimize (cgraphunit.c:1339) ==20091==by 0x410AAA: c_write_global_declarations (c-decl.c:8077) ==20091== ==20091== Conditional jump or move depends on uninitialised value(s) ==20091==at 0x9201D4: global_conflicts (sparseset.h:89) ==20091==by 0x8F7259: rest_of_handle_global_alloc (global.c:533) ==20091==by 0x584BF1: execute_one_pass (passes.c:1118) ==20091==by 0x584D8F: execute_pass_list (passes.c:1171) ==20091==by 0x584DA4: execute_pass_list (passes.c:1172) ==20091==by 0x62D093: tree_rest_of_compilation (tree-optimize.c:404) ==20091==by 0x739291: cgraph_expand_function (cgraphunit.c:1151) ==20091==by 0x73ACC3: cgraph_optimize (cgraphunit.c:1214) ==20091==by 0x410AAA: c_write_global_declarations (c-decl.c:8077) ==20091==by 0x5FA23B: toplev_main (toplev.c:1055) ==20091==by 0x39A0A1DAB3: (below main) (in /lib64/libc-2.6.so) ==20091== ==20091== Conditional jump or move depends on uninitialised value(s) ==20091==at 0x920F71: global_conflicts (sparseset.h:89) ==20091==by 0x8F7259: rest_of_handle_global_alloc (global.c:533) ==20091==by 0x584BF1: execute_one_pass (passes.c:1118) ==20091==by 0x584D8F: execute_pass_list (passes.c:1171) ==20091==by 0x584DA4: execute_pass_list (passes.c:1172) ==20091==by 0x62D093: tree_rest_of_compilation (tree-optimize.c:404) ==20091==by 0x739291: cgraph_expand_function (cgraphunit.c:1151) ==20091==by 0x73ACC3: cgraph_optimize (cgraphunit.c:1214) ==20091==by 0x410AAA: c_write_global_declarations (c-decl.c:8077) ==20091==by 0x5FA23B: toplev_main (toplev.c:1055) ==20091==by 0x39A0A1DAB3: (below main) (in /lib64/libc-2.6.so) ==20091== ==20091== Conditional jump or move depends on uninitialised value(s) ==20091==at 0x920ABB: global_conflicts (sparseset.h:89) ==20091==by 0x8F7259: rest_of_handle_global_alloc (global.c:533) ==20091==by 0x584BF1: execute_one_pass (passes.c:1118) ==20091==by 0x584D8F: execute_pass_list (passes.c:1171) ==20091==by 0x584DA4: execute_pass_list (passes.c:1172) ==20091==by 0x62D093: tree_rest_of_compilation (tree-optimize.c:404) ==20091==by 0x739291: cgraph_expand_function (cgraphunit.c:1151) ==20091==by 0x73ACC3: cgraph_optimize (cgraphunit.c:1214) ==20091==by 0x410AAA: c_write_global_declarations (c-decl.c:8077) ==20091==by 0x5FA23B: toplev_main (toplev.c:1055) ==20091==by 0x39A0A1DAB3: (below main) (in /lib64/libc-2.6.so) ==20091== ==20091== Use of uninitialised value of size 8 ==20091==at 0x921C4D: global_conflicts (sparseset.h:89) ==20091==by 0x8F7259: rest_of_handle_global_alloc (global.c:533) ==20091==by 0x584BF1: execute_one_pass (passes.c:1118) ==20091==by 0x584D8F: execute_pass_list (passes.c:1171) ==20091==by 0x584DA4: execute_pass_list (passes.c:1172) ==20091==by 0x62D093: tree_rest_of_compilation (tree-optimize.c:404) ==20091==by 0x739291: cgraph_expand_function (cgraphunit.c:1151) ==20091==by 0x73ACC3: cgraph_optimize (cgraphunit.c:1214) ==20091==by 0x410AAA: c_write_global_declarations (c-decl.c:8077) ==20091==by 0x5FA23B: toplev_main (toplev.c:1055) ==20091==by 0x39A0A1DAB3: (below main) (in /lib64/libc-2.6.so) ==20091== ==20091== Use of uninitialised value of size 8 ==20091==at 0x920F7C: global_conflicts (sparseset.h:89) ==20091==by 0x8F7259: rest_of_handle_global_alloc (global.c:533) ==20091==by 0x584BF1: execute_one_pass (passes.c:1118) ==20091==by 0x584D8F: execute_pass_list (passes.c:1171) ==20091==by 0x584DA4: execute_pass_list (passes.c:1172) ==20091==by 0x62D093
[Bug rtl-optimization/33721] [meta-bug] Gcc can't properly align stack variable
--- Comment #3 from hjl at lucon dot org 2007-12-18 03:09 --- A proposal is posted at http://gcc.gnu.org/ml/gcc/2007-12/msg00503.html -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-18 03:09:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33721
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #16 from hjl at lucon dot org 2007-12-17 07:01 --- (In reply to comment #13) Now that we have ext/hash_map and ext/hash_set back (yes, SPEC2000 eon still is broken, as it uses the removed iostream.h and other *.h FWIW, I have 252.eon.gcc43.src.alt.tar.bz2, which works for gcc 4.x. Of course, it isn't an offical src.alt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #4 from hjl at lucon dot org 2007-12-15 22:05 --- Where is __GCC_FLOAT_NOT_NEEDED documented? Is this a supported gcc macro? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug tree-optimization/34472] New: gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work
On Linux/Intel64, I got /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_malloc_size_var.c -O3 -fipa-struct-reorg -fdump-ipa-all -fwhole-program -combine -fipa-type-escape -fno-show-column -lm -o ./wo_prof_malloc_size_var.exe (timeout = 300) /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_malloc_size_var.c:32: internal compiler error: Segmentation fault^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^M compiler exited with status 1 -- Summary: gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34472
[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input
--- Comment #29 from hjl at lucon dot org 2007-12-13 17:16 --- (In reply to comment #28) Could someone confirm that gfortran (with no reverted patches) now works again with 481.wrf or with SPEC in general? I am running SPEC CPU 2000/2006 now. I will report results when they are finished. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input
--- Comment #30 from hjl at lucon dot org 2007-12-14 04:15 --- (In reply to comment #29) I am running SPEC CPU 2000/2006 now. I will report results when they are finished. They are finished. No regressions. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input
--- Comment #31 from hjl at lucon dot org 2007-12-14 04:23 --- (In reply to comment #30) (In reply to comment #29) I am running SPEC CPU 2000/2006 now. I will report results when they are finished. They are finished. No regressions. Thanks. SPEC CPU 2000/2006 on Intel64 ran correctly with gcc 4.3 revision 130894. -- hjl at lucon dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled
--- Comment #6 from hjl at lucon dot org 2007-12-11 13:46 --- I saw it with revision 130726. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-11 13:46:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled
--- Comment #7 from hjl at lucon dot org 2007-12-11 14:03 --- Revision 130707 is OK if I back out revision 130629. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled
--- Comment #8 from hjl at lucon dot org 2007-12-11 14:18 --- Revision 130726 failed after I backed out revisions 130629 and 130712. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled
--- Comment #9 from hjl at lucon dot org 2007-12-11 14:56 --- Revision 130726 is OK after I reverted libgfortran to revision 130629. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled
--- Comment #11 from hjl at lucon dot org 2007-12-11 20:16 --- [EMAIL PROTECTED] 34427]$ cat foo.f90 IMPLICIT NONE real , DIMENSION(11) ::foo integer :: isfflx NAMELIST /nl/ foo NAMELIST /nl/ isfflx open (10, status=scratch) write (10,*) nl write (10,*) foo = 5, 5, 5, write (10,*) isfflx = 1, write (10,*) / rewind (10) READ (10, NML = nl, ERR = 9200) CLOSE (10) STOP 9200 CALL abort () END [EMAIL PROTECTED] 34427]$ /export/gnu/import/svn/rrs/34427/usr/bin/gfortran -static -o new foo.f90 [EMAIL PROTECTED] 34427]$ ./new Aborted [EMAIL PROTECTED] 34427]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled
--- Comment #12 from hjl at lucon dot org 2007-12-11 20:58 ---
Revision 130708 is wrong. We can't do
if ((c == 'i' || c == 'I')
((c = next_char (dtp)) == 'n' || c == 'N')
((c = next_char (dtp)) == 'f' || c == 'F'))
{
...
if (nml_bad_return (dtp, c))
return 0;
since it will change 'c' passed to nml_bad_return (). We need to restore
the old char when it doesn't match INF/NAN.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled
--- Comment #13 from hjl at lucon dot org 2007-12-11 21:06 --- Also are inf/infinity/infbar/infinityfoo/nan/nanfoo valid variables? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34427] [4.3 Regression] Revision 130708 breaks namelist input
--- Comment #15 from hjl at lucon dot org 2007-12-11 22:37 --- We can change the last_char field to #define MAX_LAST_STRING_LEN 8 char last_string[MAX_LAST_STRING_LEN]; int last_char_pos; we can unget up to MAX_LAST_STRING_LEN chars. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug libstdc++/33832] Can't tell gcc 4.3 libstdc++ API from gcc 4.2 libstdc++ API
--- Comment #7 from hjl at lucon dot org 2007-12-11 23:00 --- This one is for moved header files. One can include different header files for gcc 4.3. PR 33831 is for removed header files. I don't know if gcc 4.3 provides the identical functionality as the old one. One may needs more than including different header files for gcc 4.3. BTW, not all applications use autoconf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33832
[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input
--- Comment #21 from hjl at lucon dot org 2007-12-12 01:56 --- (In reply to comment #18) Created an attachment (id=14736) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14736action=view) [edit] Draft Patch Test patch. It seems to fix the REAL reading part. I run out of time for the COMPLEX part (parse_real), but it should follow accordingly; maybe I have time tomorrow afternoon, otherwise feel free to pick it up - or come up with something better. Do we need to fix parse_real? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34427] New: [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled
Revision 130629: http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00079.html failed 481.wrf: module_io.fppized.f90:18531: internal compiler error: in change_file, at fortran/scanner.c:322 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. specmake[1]: *** [module_io.fppized.o] Error 1 Revision 130712: http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00163.html fixed the compiler crash. But it miscompiled wrf: Contents of wrf.err STOP wrf_abort -- FATAL CALLED --- module_configure: initial_config: error reading namelist --- -- Summary: [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34427] [4.3 Regression] 481.wrf in SPEC CPU 2006 miscompiled
--- Comment #2 from hjl at lucon dot org 2007-12-10 23:49 --- This regression was introduced between revision 130629 and 130712. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34404] New: [4.3 Regression] 168.wupwise in SPEC CPU 2000 miscompiled
Revision 130713 got Running 168.wupwise ref base o2 default *** Miscompare of te.out, see /export/spec/src/2000/i686/spec/benchspec/CFP2000/168.wupwise/run/0002/te.out.mis *** Miscompare of wupwise.out, see /export/spec/src/2000/i686/spec/benchspec/CFP2000/168.wupwise/run/0002/wupwise.out.mis Invalid run; unable to continue. If you wish to ignore errors please use '-I' or ignore_errors At line 37 of file init.f (unit = 10, file = 'wupwise.in') Fortran runtime error: Bad floating point number for item 1 Revision 130596 is OK. -- Summary: [4.3 Regression] 168.wupwise in SPEC CPU 2000 miscompiled Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34404
[Bug fortran/34404] [4.3 Regression] 168.wupwise in SPEC CPU 2000 miscompiled
--- Comment #1 from hjl at lucon dot org 2007-12-09 12:14 ---
Revision 130708
http://gcc.gnu.org/viewcvs/trunk/libgfortran/io/list_read.c?r1=130708r2=130707pathrev=130708
has
@@ -1136,6 +1141,13 @@
exp2:
if (!isdigit (c))
+{
+ if (c == 'i' || c == 'I' || c == 'n' || c == 'N')
+ goto inf_nan;
+ else
+ goto bad;
+}
+
goto bad; -- Should be removed.
push_char (dtp, c);
@@ -1166,6 +1178,41 @@
--
hjl at lucon dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34404
[Bug libfortran/34404] [4.3 Regression] 168.wupwise in SPEC CPU 2000 miscompiled
--- Comment #2 from hjl at lucon dot org 2007-12-09 12:15 --- The input data file has (2.4E-1, 0.0E+0) It is read by COMPLEX*16 X ... READ(10,*) X -- hjl at lucon dot org changed: What|Removed |Added Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34404
[Bug tree-optimization/34413] New: gfortran.dg/ltrans-7.f90 doesn't work
I got FAIL: gfortran.dg/ltrans-7.f90 -O scan-tree-dump-times ltrans transformed loop 1 on x86_64-unknown-linux-gnu. -- Summary: gfortran.dg/ltrans-7.f90 doesn't work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34413
[Bug fortran/34376] New: [4.3 Regression] gfortran.dg/ishft_1.f90
I got /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/ishft_1.f90:28.29:^M ^M if (ishft (-1_8, -60) /= z'F') call abort^M 1^M Warning: Extension: BOZ used outside a DATA statement at (1)^M Is this related to http://gcc.gnu.org/ml/fortran/2007-12/msg00055.html -- Summary: [4.3 Regression] gfortran.dg/ishft_1.f90 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34376
[Bug fortran/34377] New: [4.3 Regression] 187.facerec in SPEC CPU 2000 failed to compile
With -O2 -ffast-math, gcc 4.3 revision 130669 got f951: internal compiler error: in change_file, at fortran/scanner.c:322 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gaborRoutines.f90:13.10: Revision 130596 is OK. -- Summary: [4.3 Regression] 187.facerec in SPEC CPU 2000 failed to compile Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34377
[Bug tree-optimization/34244] [4.3 Regression] VRP/SCEV miscompiles Firefox
--- Comment #12 from hjl at lucon dot org 2007-11-30 08:56 --- gcc.dg/tree-ssa/pr34244.c in http://gcc.gnu.org/viewcvs?view=revrevision=130527 has duplicated content. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34244
[Bug fortran/34246] New: gfortran.dg/bind_c_usage_16.f03 doesn't work
From http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01452.html FAIL: gfortran.dg/bind_c_usage_16.f03 -O0 execution test FAIL: gfortran.dg/bind_c_usage_16.f03 -O1 execution test FAIL: gfortran.dg/bind_c_usage_16.f03 -O2 execution test FAIL: gfortran.dg/bind_c_usage_16.f03 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/bind_c_usage_16.f03 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/bind_c_usage_16.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/bind_c_usage_16.f03 -O3 -g execution test FAIL: gfortran.dg/bind_c_usage_16.f03 -Os execution test -- Summary: gfortran.dg/bind_c_usage_16.f03 doesn't work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org BugsThisDependsOn: 34079 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34246
[Bug tree-optimization/34247] New: [4.3 Regression] ICE in omp_add_variable, at gimplify.c:4677
From http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01452.html FAIL: libgomp.fortran/character1.f90 -O0 (internal compiler error) FAIL: libgomp.fortran/character1.f90 -O0 (test for excess errors) WARNING: libgomp.fortran/character1.f90 -O0 compilation failed to produce executable ... libgomp.fortran/vla1.f90:76: internal compiler error: in omp_add_variable, at gimplify.c:4677 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.3 Regression] ICE in omp_add_variable, at gimplify.c:4677 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34247
[Bug rtl-optimization/34249] New: [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
I got
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/bb-reorg.c
-O2 -freorder-blocks-and-partition -fprofile-use -D_PROFILE_USE
-fno-show-column -lm -o
/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gcc/bb-reorg.x02
(timeout = 300)
/tmp/ccNBvTsg.s: Assembler messages:
/tmp/ccNBvTsg.s:150: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `.LFB15' {.text section}
compiler exited with status 1
--
Summary: [4.3 Regression] FAIL: gcc.dg/tree-prof/bb-reorg.c
compilation, -fprofile-use -D_PROFILE_USE
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug rtl-optimization/34249] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #1 from hjl at lucon dot org 2007-11-27 12:49 --- This testcase doesn't work on Linux/x86-64. -- hjl at lucon dot org changed: What|Removed |Added CC||revitale at gcc dot gnu dot ||org Summary|[4.3 Regression] FAIL: |FAIL: gcc.dg/tree-prof/bb- |gcc.dg/tree-prof/bb-reorg.c |reorg.c compilation, - |compilation, -fprofile-use |fprofile-use -D_PROFILE_USE |-D_PROFILE_USE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
[Bug tree-optimization/34247] [4.3 Regression] ICE in omp_add_variable, at gimplify.c:4677
--- Comment #1 from hjl at lucon dot org 2007-11-27 13:20 --- Revision 130371: http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00566.html is the cause. -- hjl at lucon dot org changed: What|Removed |Added CC||aldyh at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34247
[Bug target/34001] Incorrect x86 fastcall behavior
--- Comment #9 from hjl at lucon dot org 2007-11-28 01:25 --- Fixed in gcc 4.3. -- hjl at lucon dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
[Bug target/34001] Incorrect x86 fastcall behavior
--- Comment #6 from hjl at lucon dot org 2007-11-26 23:19 ---
We have changed fastcall behavior from gcc 3.4 to 4.1. For
---
#define FASTCALL __attribute((fastcall))
double FASTCALL f_dii( double p1d, int p2i, int p3i ){ return p1d +
(double)p2
i + (double)p3i; }
inttest_x;
inttest_y;
double test_d1;
void caller( void ){
f_dii( test_d1, test_x, test_y );
}
---
Gcc 3.4 doesn't pass the first 2 integral parameters in ecx/edx and gcc
4.1 does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
[Bug target/34001] Incorrect x86 fastcall behavior
--- Comment #7 from hjl at lucon dot org 2007-11-27 02:36 ---
(In reply to comment #6)
We have changed fastcall behavior from gcc 3.4 to 4.1. For
---
#define FASTCALL __attribute((fastcall))
double FASTCALL f_dii( double p1d, int p2i, int p3i ){ return p1d +
(double)p2
i + (double)p3i; }
inttest_x;
inttest_y;
double test_d1;
void caller( void ){
f_dii( test_d1, test_x, test_y );
}
---
Gcc 3.4 doesn't pass the first 2 integral parameters in ecx/edx and gcc
4.1 does.
This patch
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00541.html
fixes this fast call bug by changing the abi.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
[Bug bootstrap/34144] New: [4.3 Regression] Revision 130005 causes bootstrap failure
On Linux/i686 and Linux/x86-64, revision 130005 causes bootstrap failure with --disable-checking. -- Summary: [4.3 Regression] Revision 130005 causes bootstrap failure Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
[Bug bootstrap/34144] [4.3 Regression] Revision 130005 causes bootstrap failure
--- Comment #1 from hjl at lucon dot org 2007-11-18 20:48 --- Revision 130005 is http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00197.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
[Bug target/34001] Incorrect x86 fastcall behavior
--- Comment #5 from hjl at lucon dot org 2007-11-16 04:52 --- The correct patch is at http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00885.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
[Bug target/34001] Incorrect x86 fastcall behavior
--- Comment #4 from hjl at lucon dot org 2007-11-12 03:27 --- From info gcc, `fastcall' On the Intel 386, the `fastcall' attribute causes the compiler to pass the first argument (if of integral type) in the register ECX ^^^ and the second argument (if of integral type) in the register EDX. ^^^ Subsequent and other typed arguments are passed on the stack. The called function will pop the arguments off the stack. If the number of arguments is variable all arguments are pushed on the stack. It looks like gcc document follows MS compiler and we didn't implement it correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #11 from hjl at lucon dot org 2007-11-10 18:41 --- (In reply to comment #10) Subject: Re: [4.3 Regression]: Revision 130040 miscompiles 450.soplex On Sat, 10 Nov 2007, bonzini at gnu dot org wrote: --- Comment #9 from bonzini at gnu dot org 2007-11-10 18:10 --- You should report the problem to SPEC so they update http://www.spec.org/cpu2006/Docs/450.soplex.html and create a src.alt (I think, at least this is how it was for CPU2000). I'll leave that to HJ who has done so in the past. I will take care of it. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #12 from hjl at lucon dot org 2007-11-10 19:17 --- (In reply to comment #7) Created an attachment (id=14525) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14525action=view) [edit] patch for 450.soplex This patch is incomplete. I got unitvector.cc: In member function 'bool soplex::UnitVector::isConsistent() const': unitvector.cc:30: error: comparison between distinct pointer types 'soplex::SVector::Element*' and 'const soplex::SVector::Element (*)[2]' lacks a cast unitvector.cc:32: error: 'themem1' was not declared in this scope specmake[1]: *** [unitvector.o] Error 1 -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #13 from hjl at lucon dot org 2007-11-10 19:42 --- Created an attachment (id=14526) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14526action=view) A patch This patch seems to work. -- hjl at lucon dot org changed: What|Removed |Added Attachment #14525|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug target/34001] Incorrect __attribute__ fastcall behavior
--- Comment #2 from hjl at lucon dot org 2007-11-09 16:55 --- From http://msdn2.microsoft.com/en-us/library/6xa169sk(VS.80).aspx The first two DWORD or smaller arguments are passed in ECX and EDX registers; all other arguments are passed right to left. But it isn't clear if it applies to structure/union. We tested all MS compilers we have and verified that the above doesn't apply to structure/union. To make fastcall compatible with MS compilers, we should only put scalar arguments in ECX and EDX. -- hjl at lucon dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hjl at lucon dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-08 17:12:05 |2007-11-09 16:55:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
[Bug target/34001] Incorrect __attribute__ fastcall behavior
--- Comment #3 from hjl at lucon dot org 2007-11-09 17:34 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00531.html -- hjl at lucon dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||11/msg00531.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
[Bug tree-optimization/34048] New: [4.3 Regression]: Revision 130040 miscompiles 450.soplex
Revision 130040 miscompiles 450.soplex in SPEC CPU 2006 with -O2 -ffast-math on Linux/x86-64: Running (#1) 450.soplex ref base o2 default 450.soplex: copy #0 non-zero return code (rc=0, signal=11) Error with '/export/spec/src/2006/x86_64/spec/bin/specinvoke -E -d /export/spec/src/2006/x86_64/spec/benchspec/CPU2006/450.soplex/run/run_base_ref_o2. -c 1 -e compare.err -o compare.stdout -f compare.cmd': check file '/export/spec/src/2006/x86_64/spec/benchspec/CPU2006/450.soplex/run/run_base_ref_o2./.err' *** Miscompare of ref.stderr, see /export/spec/src/2006/x86_64/spec/benchspec/CPU2006/450.soplex/run/run_base_ref_o2./ref.stderr.mis *** Miscompare of ref.out, see /export/spec/src/2006/x86_64/spec/benchspec/CPU2006/450.soplex/run/run_base_ref_o2./ref.out.mis Invalid run; unable to continue. If you wish to ignore errors please use '-I' or ignore_errors -- Summary: [4.3 Regression]: Revision 130040 miscompiles 450.soplex Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: x86_64-unknown-linux-gnu OtherBugsDependingO 33604 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug target/34001] Incorrect __attribute__ fastcall behavior
--- Comment #1 from hjl at lucon dot org 2007-11-08 17:12 --- I verified that it isn't fixed in gcc 4.3.0. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-08 17:12:05 date|| Target Milestone|--- |4.3.0 Version|4.0.1 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #34 from hjl at lucon dot org 2007-11-06 17:30 --- An updated patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00273.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #42 from hjl at lucon dot org 2007-11-05 14:18 --- (In reply to comment #39) Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 04/11/2007, at 7:01 PM, hjl at lucon dot org wrote: - Won't this cause the global variable to be discarded if anyone defines a different global variable which also references the same string? The comdat group should have both global variables defined. I'm talking about static char * some_variable = hi there; and in some other file static char * some_variable = hi there; the compiler does not know that there are two files containing 'some_variable', and they have to be different variables (someone might change one of them and the other should not change if that happens), but the two hi there strings should be shared. How should the compiler represent this in ELF? 1. Put hi there in a comdat group. 2. Mark hi there global and hidden. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #43 from hjl at lucon dot org 2007-11-05 19:25 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00214.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #31 from hjl at lucon dot org 2007-11-04 14:40 --- (In reply to comment #30) Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 03/11/2007, at 7:21 AM, hjl at lucon dot org wrote: Local symbols should only be referenced within the same comdat group or the linkonce section. Otherwise, it is a compiler bug. How do you represent, in ELF, a string which should be present in the executable only once, but which need not have a globally visible name? You can put it in a comdat group. But you should only reference it from the same comdat group. A comdat group is a set of sections which have the same signature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #33 from hjl at lucon dot org 2007-11-05 00:22 --- (In reply to comment #32) What if you want to reference this string from somewhere that should never be discarded, like a global variable? Since the string is local, that global variable is defined in the same file as the string. You should put the global variable in a section which belongs to the same comdat group as the local string. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #34 from hjl at lucon dot org 2007-11-05 00:32 --- (In reply to comment #33) (In reply to comment #32) What if you want to reference this string from somewhere that should never be discarded, like a global variable? Since the string is local, that global variable is defined in the same file as the string. You should put the global variable in a section which belongs to the same comdat group as the local string. You should also put that global variable in the same comat group in all files where that comdat group is generated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #36 from hjl at lucon dot org 2007-11-05 02:50 --- The rules for the comdat group are 1. There should be no outside references to local symbols inside of the comdat group. 2. All comdat groups with the same signature should have the identical set of defined global symbols. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #37 from hjl at lucon dot org 2007-11-05 03:01 --- (In reply to comment #35) - What if the global variable references two or more strings? All local strings referenced by the global variable should be in the same comdat group. - Won't this cause the global variable to be discarded if anyone defines a different global variable which also references the same string? The comdat group should have both global variables defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #38 from hjl at lucon dot org 2007-11-05 03:03 --- (In reply to comment #37) (In reply to comment #35) - What if the global variable references two or more strings? All local strings referenced by the global variable should be in the same comdat group. It should be all ocal strings referenced by the global variable should be defined in either the same comdat group or a non-comdat section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #29 from hjl at lucon dot org 2007-11-03 14:21 --- (In reply to comment #27) In this case, though, the contents of the linkonce section will never actually differ; and I believe in this case the offset is zero, so even if they did differ it would not matter. Perhaps a zero offset should be special-cased? Local symbols should only be referenced within the same comdat group or the linkonce section. Otherwise, it is a compiler bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug middle-end/33966] New: Revision 129625 caused 1% slowdown on 200.sixtrack
Revision 129625 http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00730.html caused 11% drop in performance for 200.sixtrack in SPEC CPU 2000 with -O2 -ffast-math on Core 2 Duo 64bit. That patch caused very different codes generated for 200.sixtrack on x86-64. -- Summary: Revision 129625 caused 1% slowdown on 200.sixtrack Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33966
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #22 from hjl at lucon dot org 2007-10-30 19:12 --- The problem is typeinfo for (anonymous namespace)::t in .rodata section references typeinfo name for (anonymous namespace)::t in a comdat section. When the comdat section is discarded, we got a problem. Can we put typeinfo for (anonymous namespace)::t in the same comdat group as typeinfo name for (anonymous namespace)::t? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #24 from hjl at lucon dot org 2007-10-30 19:36 --- (In reply to comment #23) Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 30/10/2007, at 12:12 PM, hjl at lucon dot org wrote: The problem is typeinfo for (anonymous namespace)::t in .rodata section references typeinfo name for (anonymous namespace)::t in a comdat section. When the comdat section is discarded, we got a problem. Why is the comdat section being discarded when something is referencing it? It is due to S1.C S1.C. Only one comdat group in S1.C is kept. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #25 from hjl at lucon dot org 2007-10-30 19:37 --- Basically, you can't have a non-comdat section references a local symbol in a comdat section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug regression/33926] FAIL: gcc.dg/dfp/convert-dfp-round-thread.c execution test
--- Comment #4 from hjl at lucon dot org 2007-10-28 16:48 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33926
[Bug regression/33926] New: FAIL: gcc.dg/dfp/convert-dfp-round-thread.c execution test
I got FAIL: gcc.dg/dfp/convert-dfp-round-thread.c execution test on Linux/ia32 and Linux/x86-64 with revision 129372 and revision 129351 is OK. -- Summary: FAIL: gcc.dg/dfp/convert-dfp-round-thread.c execution test Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33926
[Bug regression/33926] FAIL: gcc.dg/dfp/convert-dfp-round-thread.c execution test
--- Comment #2 from hjl at lucon dot org 2007-10-27 23:16 --- If you run autoconf in libgcc, you will see the failure. See http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01652.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33926
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #3 from hjl at lucon dot org 2007-10-21 21:41 --- I believe all those header files should be restored unless we have a very good reason to break libstdc++ API. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33832] Can't tell gcc 4.3 libstdc++ API from gcc 4.2 libstdc++ API
--- Comment #1 from hjl at lucon dot org 2007-10-21 21:45 --- I believe we should add those deleted ext/xxx header files with #warning __FILE__ is deprecated #include backward/xxx if we want to move ext/xxx to backward/xxx. It is never a good idea to break the existing C++ applications for no very good reasons. -- hjl at lucon dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33832
[Bug libstdc++/33831] New: [4.3 Regression] Revision 129442 breaks libstc++ API
Revision 129442 http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00547.html removed many libstdc++ header files from include/backward. That means gcc 4.3 has a different API. It breaks many C++ applications which use the current libstdc++ API. -- Summary: [4.3 Regression] Revision 129442 breaks libstc++ API Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
