[Bug regression/52271] New: -fdebug-types-section crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52271 Bug #: 52271 Summary: -fdebug-types-section crashes Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: jan.kratoch...@redhat.com Target: x86_64-unknown-linux-gnu crash: gcc (GCC) 4.7.0 20120216 (experimental) It was crashing already at least on 2012-02-01, I did not search older logs. crash: gcc-4.7.0-0.12.fc17.x86_64. while PATH=$HOME/redhat/gcchead-root/bin:$PATH /usr/bin/runtest CXX_FOR_TARGET=g++ -gdwarf-4 -fdebug-types-section -g0 gdb.cp/m-static.exp gdb.cp/templates.exp gdb.cp/cpexprs.exp ! grep 'glibc detected' gdb.log;do :;done gdb compile failed, *** glibc detected *** /home/jkratoch/redhat/gcchead-root/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus: invalid fastbin entry (free): 0x0285df20 *** general data corruption, backtrace is dwarf2out_finish-...-htab_expand-... Reproducible in about 33% of runs for me.
[Bug regression/52272] New: [4.7 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 Bug #: 52272 Summary: [4.7 regression] Performance regresswion of 410.bwaves on x86. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: vbyakov...@gmail.com Created attachment 26671 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26671 Reduced testcase Commit 2012-02-06 Richard Guenther rguent...@suse.de PR tree-optimization/50955 * tree-ssa-loop-ivopts.c (get_computation_cost_at): Artificially raise cost of expressions that replace an address with an expression based on a different pointer. causes performance regression on 410.bwaves base: -2.33% peak: -3.82% I attached a reduced testcase and dumps of compilers before and after commit. Command line to reproduce gfortran -w -g -m32 -static -S t.s -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math -march=corei7 t.f
[Bug regression/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #1 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-02-16 08:16:27 UTC --- Created attachment 26672 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26672 Good case before commit
[Bug regression/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #2 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-02-16 08:17:53 UTC --- Created attachment 26673 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26673 Bad case after commit
[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org 2012-02-16 08:23:38 UTC --- (In reply to comment #10) But think about a header only library. My test case isn't that far fetched. A simple struct with no member functions (except for the implicitly generated ones) should need no visibility at all, in my opinion. Sure, but then why do you want the instantiation to have higher visibility? It doesn't make sense to me for a function that has that type in the signature to have higher visibility than the type itself.
[Bug target/52260] [4.7 Regression] ICE in clone_tree_hash, at dwarf2out.c:7424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52260 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 08:47:32 UTC --- Author: jakub Date: Thu Feb 16 08:47:24 2012 New Revision: 184303 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184303 Log: PR debug/52260 * dwarf2out.c (copy_decls_walk): Fill in *slot before traversing children with clone_tree_hash, not after it. * g++.dg/debug/dwarf2/pr52260.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr52260.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug regression/52271] -fdebug-types-section crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52271 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 08:48:45 UTC --- Dup of PR52260 IMHO.
[Bug target/52260] [4.7 Regression] ICE in clone_tree_hash, at dwarf2out.c:7424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52260 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 08:51:14 UTC --- Fixed.
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #3 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-02-16 08:58:45 UTC --- Created attachment 26674 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26674 Dump of bad case (with -fPIC -DPIC)
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #4 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-02-16 09:00:32 UTC --- Created attachment 26675 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26675 Dump of good case (without -fPIC -DPIC)
[Bug target/52260] [4.7 Regression] ICE in clone_tree_hash, at dwarf2out.c:7424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52260 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 08:50:11 UTC --- Author: jakub Date: Thu Feb 16 08:50:02 2012 New Revision: 184304 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184304 Log: PR debug/52260 * dwarf2out.c (copy_decls_walk): Fill in *slot before traversing children with clone_tree_hash, not after it. * g++.dg/debug/dwarf2/pr52260.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr52260.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/dwarf2out.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #5 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-02-16 09:05:49 UTC --- (In reply to comment #2) I don't understand what you mean by inlining, since '_Rb_tree_node_base' is a *type* not a function. This is a constructor Anyway, I don't see how Benjamin's split could have caused inlining issues. I don't know also but compare inline dumps with and witout -fPIC -DPIC (attached). I used command line from log of compiler build /export/users/vbyakovl/workspaces/581/build-bad/./gcc/xgcc -shared-libgcc -B/export/users/vbyakovl/workspaces/581/build-bad/./gcc -nostdinc++ -L/export/users/vbyakovl/workspaces/581/build-bad/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/export/users/vbyakovl/workspaces/581/build-bad/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/export/users/vbyakovl/workspaces/581/install-bad/x86_64-unknown-linux-gnu/bin/ -B/export/users/vbyakovl/workspaces/581/install-bad/x86_64-unknown-linux-gnu/lib/ -isystem /export/users/vbyakovl/workspaces/581/install-bad/x86_64-unknown-linux-gnu/include -isystem /export/users/vbyakovl/workspaces/581/install-bad/x86_64-unknown-linux-gnu/sys-include -I/export/users/vbyakovl/workspaces/581/gcc/libstdc++-v3/../libgcc -I/export/users/vbyakovl/workspaces/581/build-bad/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/users/vbyakovl/workspaces/581/build-bad/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/export/users/vbyakovl/workspaces/581/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -Wabi -ffunction-sections -fdata-sections -frandom-seed=tree.lo -g -O2 -D_GNU_SOURCE -c ../../../../../gcc/libstdc++-v3/src/c++98/tree.cc -fPIC -DPIC -o tree.o -fdump-ipa-inlin
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 09:26:58 UTC --- The fact that -fPIC code is often slower than -fno-pic code on many targets isn't that surprising. But libstdc++.so.6's tree.cc has been compiled with -fPIC -DPIC before Benjamin's change and is compiled with those flags after those changes as well (on x86_64 you would likely not being able to link libstdc++.so.6 otherwise). So, are you linking libstdc++ statically into the benchmark? Why? That isn't what people normally do, nor they should be doing. It is true that libstdc++.a now contains PIC code after the move to the convenience libraries, while previously it contained non-PIC code (with the exception of libsupc++ stuff that was PIC already before those changes).
[Bug tree-optimization/23286] missed fully redundant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286 --- Comment #37 from rguenther at suse dot de rguenther at suse dot de 2012-02-16 09:37:54 UTC --- On Wed, 15 Feb 2012, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286 --- Comment #36 from Steven Bosscher steven at gcc dot gnu.org 2012-02-15 18:37:40 UTC --- The patch was on one of the gsyprf machines, which are gone (didn't I already tell you this before??). So the latest patch is lost... Not sure, I might simply have forgotten it ;) I'm going to make the patch bootstrap again (still fails with the EH problem right now).
[Bug libitm/52220] FAIL: libitm.c++/eh-1.C execution test due to Xcode 4 weakref linker bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52220 --- Comment #3 from Iain Sandoe iains at gcc dot gnu.org 2012-02-16 09:46:37 UTC --- Author: iains Date: Thu Feb 16 09:46:31 2012 New Revision: 184305 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184305 Log: PR libitm/52220 * config/darwin-crt-tm.c: Correct typo. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/darwin-crt-tm.c
[Bug fortran/52270] [OOP] Polymorphic vars: wrong intent(in) check, passing nonptr variable to intent(in) ptr dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52270 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-16 09:54:51 UTC --- Untested patch for both issues. --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -4650,3 +4650,4 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer, bool alloc_obj, check_intentin = true; - ptr_component = sym-attr.pointer; + ptr_component = (sym-ts.type == BT_CLASS) + ? CLASS_DATA (sym)-attr.class_pointer : sym-attr.pointer; for (ref = e-ref; ref check_intentin; ref = ref-next) --- a/gcc/fortran/interface.c +++ b/gcc/fortran/interface.c @@ -1708,5 +1708,6 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual, - /* F2008, 12.5.2.5. */ + /* F2008, 12.5.2.5; IR F08/0073. */ if (formal-ts.type == BT_CLASS - (CLASS_DATA (formal)-attr.class_pointer + ((CLASS_DATA (formal)-attr.class_pointer + !formal-attr.intent == INTENT_IN) || CLASS_DATA (formal)-attr.allocatable))
[Bug translation/52273] New: translatable string typo: at at %L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52273 Bug #: 52273 Summary: translatable string typo: at at %L Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassig...@gcc.gnu.org ReportedBy: sti...@antcom.de See gcc/fortran/interface.c:2431 Further, there is a single quotation mark missing in the same string: %s' should be '%s'. Compare similar one in line 2445.
[Bug c++/52126] [4.7 Regression] compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52126 --- Comment #6 from fabien at gcc dot gnu.org 2012-02-16 09:57:20 UTC --- (In reply to comment #5) (In reply to comment #2) Further investigation shows that the issue appears only when inheritance from the template class (class B : private AT) is provided explicitly. According to the standard a nested class defined inside a class template is implicitly template as well. I don't think that's relevant. The point is that the injected-class-name 'A' and 'AT' both refer to the class template, and should work equivalently. Yes, they should. The first bug is that 'A' does not behave like 'AT' -- I have fixed it. The second bug is that 'AT' as a base for a nested class does not currently work if A is also an enclosing class. I have tested a patch, but it is not quite ready.
[Bug tree-optimization/52255] [4.7 Regression] ICE: verify_ssa failed, block does not dominate use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52255 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 10:20:33 UTC --- Author: jakub Date: Thu Feb 16 10:20:26 2012 New Revision: 184306 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184306 Log: PR tree-optimization/52255 * tree-vect-loop-manip.c (slpeel_tree_peel_loop_to_edge): If loop-header has virtual PHI, but exit_e-dest doesn't, add virtual PHI to exit_e-dest and adjust all uses after the loop. * gcc.c-torture/compile/pr52255.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr52255.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-16 10:37:34 UTC --- It is desirable that libstdc++.a contains PIC code, otherwise you cannot link it statically into shared libraries or into position independent executables.
[Bug go/52266] [4.7 Regression] syntax error in libgo/configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52266 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||missed-optimization Last reconfirmed||2012-02-16 Component|regression |tree-optimization AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Target Milestone|--- |4.7.0 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-16 10:39:34 UTC --- I didn't see the regression on a SandyBridge machine with -Ofast -funroll-loops -fpeel-loops -march=native [-flto]. But I can see the regression on an AMD Bulldozer machine. I will have a look. Note that the patch was to fix a wrong-code issue, so we may have to live with the performance regression.
[Bug c++/52263] Zero-initialization doesn't seem to work correctly for virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52263 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.3, 4.7.0 Resolution||FIXED Target Milestone|--- |4.6.3 Known to fail||4.6.2 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-16 10:42:33 UTC --- Fixed for 4.6.3 indeed.
[Bug tree-optimization/52255] [4.7 Regression] ICE: verify_ssa failed, block does not dominate use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52255 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 10:51:06 UTC --- Fixed.
[Bug fortran/52274] New: [Meta-bug] Fortran translation related issues: Typos and more
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52274 Bug #: 52274 Summary: [Meta-bug] Fortran translation related issues: Typos and more Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: diagnostic, meta-bug Severity: major Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Blocks: 38573, 42693, 52232, 52234, 52245, 52246, 52262, 52273 Issues related to translation, mostly bugs filled against translation.
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 10:57:19 UTC --- Note that if more inlining in tree.cc even in -fPIC code helps more than just a single benchmark, we could consider compiling that file with -O3, or use some attributes/pragmas to ensure it is inlined. So perhaps start with compiling tree.cc with -O3 instead of -O2 (in both cases with -fPIC -DPIC) and see if it helps and how much.
[Bug tree-optimization/52275] New: The polyhedron test air.f90 is miscompiled with '-O2 -floop-flatten' after revision 184265
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52275 Bug #: 52275 Summary: The polyhedron test air.f90 is miscompiled with '-O2 -floop-flatten' after revision 184265 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: bur...@gcc.gnu.org, gros...@gcc.gnu.org, rgue...@gcc.gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 Revision 184265 fixes the ICE I saw on the 2005 polyhedron test air.f90. However as reported in comment #9 of pr50561, the test is miscompiled with '-O2 -floop-flatten' and higher optimization: ITERATION# TIME FINAL MASS RESIDUAL 100.48597138 0.01003.390685 230.000104076310 0.01003.149714 370.000153111889 0.01003.155547 530.000203760449 0.01003.121681 700.000253653805 0.01003.304361 900.000307361190 0.0100 NaN 91 100.000307361190 0.0100 NaN deltat, final t, iterations 100.00100.00030736119007 91 10 3.3906853070974479 23 3.1497139386725364 37 3.1555468854046320 53 3.1216810612141770 70 3.3043611633047654 90 NaN 91 NaN or with -Ofast ITERATION# TIME FINAL MASS RESIDUAL a zero delta time was detected 0.20. deltat, final t, iterations 9.4702850481575148E-006 NaN 2 These miscompilations disappear if I add -fcheck=bound or -fwhole-program, but not if I add -flto. Note also that the test pass on powerpc-apple-darwin9. AFAICT the air.f90 is the only test in the suite having loops candidate for loop reversal or loop flattening, e.g., @@ -880,13 +880,13 @@ DO iy = 1 , NDY maxy = maxy + NPY(iy) + 1 dtd = 100.0 -DO i = minx , maxx - DO j = miny , maxy +DO j = miny , maxy + DO i = minx , maxx IF ( dtt(i,j).LE.dtd ) dtd = dtt(i,j) ENDDO ENDDO -DO i = minx , maxx - DO j = miny , maxy +DO j = miny , maxy + DO i = minx , maxx dtt(i,j) = dtd ENDDO ENDDO So far graphite has been unable to perform this optimization and the modified test is also miscompiled.
[Bug tree-optimization/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu.org
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-16
12:41:30 UTC ---
Proposed patch:
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 184304)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -2506,6 +2506,15 @@ add_iv_value_candidates (struct ivopts_d
if (offset
|| base != iv-base)
add_candidate (data, base, iv-step, false, use);
+
+ /* Fourth, try removing the base-object for pointer IVs. */
+ if (TREE_CODE (iv-base) == POINTER_PLUS_EXPR)
+{
+ tree base_object = iv-base_object;
+ STRIP_NOPS (base_object);
+ if (operand_equal_p (TREE_OPERAND (iv-base, 0), base_object, 0))
+ add_candidate (data, TREE_OPERAND (iv-base, 1), iv-step, false, use);
+}
}
/* Adds candidates based on the uses. */
@@ -4062,7 +4071,13 @@ get_computation_cost_at (struct ivopts_d
if (use-iv-base_object
cand-iv-base_object
!operand_equal_p (use-iv-base_object, cand-iv-base_object, 0))
- return infinite_cost;
+ {
+ if (dump_file (dump_flags TDF_DETAILS))
+ fprintf (dump_file, Not considering candidate %d for use %d
+because they have different pointer bases%s\n,
+cand-id, use-id, address_p ? (address_p) : );
+ return infinite_cost;
+ }
}
if (TYPE_PRECISION (utype) TYPE_PRECISION (ctype))
[Bug tree-optimization/23286] missed fully redundant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286 --- Comment #38 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-16 12:44:31 UTC --- Incremental patch to fix the EH related ICEs: Index: gcc/tree-ssa-pre.c === --- gcc/tree-ssa-pre.c.orig 2012-02-16 12:08:57.0 +0100 +++ gcc/tree-ssa-pre.c 2012-02-16 12:08:50.0 +0100 @@ -3937,7 +3937,8 @@ do_hoist_insertion (basic_block block AT find_or_generate_expression (block, expr, stmts, NULL); last = gsi_last_bb (block); - if (gsi_end_p (last) || is_ctrl_stmt (gsi_stmt (last))) + if (gsi_end_p (last) + || stmt_ends_bb_p (gsi_stmt (last))) gsi_insert_seq_before (last, stmts, GSI_SAME_STMT); else gsi_insert_seq_after (last, stmts, GSI_SAME_STMT); when hoisting into # BLOCK 19 # PRED: 18 (fallthru,exec) [LP 15] D.2722_10 = CYapfBaseT::PfGetSettings (D.2723_9); goto bb 20; # SUCC: 20 (fallthru,exec) 113 (eh,exec) but of course we'd have to verify we can hoist across such throwing stmt (it might be a store clobbering what we insert), so maybe disabling hoisting in that case would be more appropriate. With Index: gcc/tree-ssa-pre.c === --- gcc/tree-ssa-pre.c.orig 2012-02-16 12:28:04.0 +0100 +++ gcc/tree-ssa-pre.c 2012-02-16 12:27:37.0 +0100 @@ -3874,6 +3874,7 @@ do_hoist_insertion (basic_block block AT bitmap_iterator bi; bitmap_set_t hoistable_set; bitmap availout_in_some; + gimple_stmt_iterator last; /* At least two successors, or else... */ gcc_assert (EDGE_COUNT (block-succs) = 2); @@ -3886,6 +3887,14 @@ do_hoist_insertion (basic_block block AT if (! single_pred_p (e-dest)) return false; + /* Determine the insertion point. If we cannot safely insert before + the last stmt if we'd have to, bail out. */ + last = gsi_last_bb (block); + if (!gsi_end_p (last) + !is_ctrl_stmt (gsi_stmt (last)) + stmt_ends_bb_p (gsi_stmt (last))) +return false; + hoistable_set = bitmap_set_new (); availout_in_some = BITMAP_ALLOC (grand_bitmap_obstack); @@ -3916,7 +3925,6 @@ do_hoist_insertion (basic_block block AT pre_expr expr = expression_for_id (i); unsigned int value_id = get_expr_value_id (expr); gimple_seq stmts = NULL; - gimple_stmt_iterator last; /* If the value of this expression is not available in at least one successor, do not hoist the value. */ @@ -3936,7 +3944,6 @@ do_hoist_insertion (basic_block block AT find_or_generate_expression (block, expr, stmts, NULL); - last = gsi_last_bb (block); if (gsi_end_p (last) || is_ctrl_stmt (gsi_stmt (last))) gsi_insert_seq_before (last, stmts, GSI_SAME_STMT); else Which leaves us with /abuild/rguenther/obj/./gcc/xgcc -B/abuild/rguenther/obj/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -m32 -fpic -W -Wall -gnatpg -nostdinc -m32 a-nlrear.ads -o a-nlrear.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[9]: *** [a-nlrear.o] Error 1 during stage3 libada build ...
[Bug tree-optimization/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-16 12:40:06 UTC --- Before the patch we choose Improved to: cost: 128 (complexity 0) cand_cost: 19 cand_use_cost: 28 (complexity 0) candidates: 2, 4, 7 use:0 -- iv_cand:4, cost=(2,0) use:1 -- iv_cand:4, cost=(2,0) use:2 -- iv_cand:2, cost=(0,0) use:3 -- iv_cand:7, cost=(0,0) use:4 -- iv_cand:7, cost=(4,0) use:5 -- iv_cand:7, cost=(4,0) use:6 -- iv_cand:7, cost=(4,0) use:7 -- iv_cand:7, cost=(4,0) use:8 -- iv_cand:7, cost=(4,0) use:9 -- iv_cand:7, cost=(4,0) and now we do not consider for example candidate 7 for use 4: candidate 7 var_before ivtmp.190 var_after ivtmp.190 incremented before exit test type character(kind=4) base (character(kind=4)) (a_296(D) + (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8) step 8 base object (void *) a_296(D) use 4 generic in statement D.2322_387 = axp_318(D) + D.2321_367; at position type real(kind=8)[0:D.1963] * restrict base axp_318(D) + (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8 step 8 base object (void *) axp_318(D) related candidates and we really do not want to do that because of the wrong-code issue. We instead end up with Improved to: cost: 133 (complexity 7) cand_cost: 13 cand_use_cost: 39 (complexity 7) candidates: 4, 5 use:0 -- iv_cand:4, cost=(2,0) use:1 -- iv_cand:4, cost=(2,0) use:2 -- iv_cand:5, cost=(0,0) use:3 -- iv_cand:5, cost=(5,1) use:4 -- iv_cand:5, cost=(5,1) use:5 -- iv_cand:5, cost=(5,1) use:6 -- iv_cand:5, cost=(5,1) use:7 -- iv_cand:5, cost=(5,1) use:8 -- iv_cand:5, cost=(5,1) use:9 -- iv_cand:5, cost=(5,1) where candidate 5 (important) var_before ivtmp.188 var_after ivtmp.188 incremented before exit test type sizetype base 0 step 8 I think what we miss to relate uses 4 to 9 which all are of the form base parameter + (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8 is to have a candidate which has the base object stripped and thus only tracks (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8 which we have as IV at least: ssa name D.2332_451 type sizetype base (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8 step 8 and redundant: ssa name D.2354_680 type sizetype base (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8 step 8 ssa name D.2343_692 type sizetype base (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8 step 8 ssa name D.2365_752 type sizetype base (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8 step 8 ssa name D.2376_763 type sizetype base (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8 step 8 but no associated candidate(s). If we add a candidate for it (9) we end up with Improved to: cost: 131 (complexity 0) cand_cost: 15 cand_use_cost: 35 (complexity 0) candidates: 4, 9 use:0 -- iv_cand:4, cost=(2,0) use:1 -- iv_cand:4, cost=(2,0) use:2 -- iv_cand:9, cost=(3,0) use:3 -- iv_cand:9, cost=(4,0) use:4 -- iv_cand:9, cost=(4,0) use:5 -- iv_cand:9, cost=(4,0) use:6 -- iv_cand:9, cost=(4,0) use:7 -- iv_cand:9, cost=(4,0) use:8 -- iv_cand:9, cost=(4,0) use:9 -- iv_cand:9, cost=(4,0) but with that change we now unroll the innermost loop twice, so I'm not sure it will pay off. The code generation differences even for the originally patch that caused the regression are only in scheduling and register allocation (so -fschedule-insns may recover it, or -fsched-pressure).
[Bug c++/52277] New: spell corrector for misspelled identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52277 Bug #: 52277 Summary: spell corrector for misspelled identifiers Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@gcc.gnu.org http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html#spell_checker The Ada FE has it, but I guess I cannot add a dependency on Ada, can I? http://gcc.gnu.org/ml/gcc/2010-04/msg00104.html
[Bug target/52238] -mms-bitfields: __attribute__ ((aligned (n))) ignored for struct members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52238
--- Comment #3 from Michael Kostylev michael.kostylev at gmail dot com
2012-02-16 13:26:24 UTC ---
Ok, let's modify the test case - s/char a;/char a:6;/:
struct {
char a:6;
char b __attribute__ ((aligned (16)));
} s;
int main()
{
return (__PTRDIFF_TYPE__)s.b 15;
}
The b member is still misaligned, moreover, its offset is equal to 0x11 after
patching.
[Bug tree-optimization/52275] The polyhedron test air.f90 is miscompiled with '-O2 -floop-flatten' after revision 184265
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52275 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 13:32:29 UTC --- If I apply the pseudo-patch at the end, air still works fine at -O3 or -O2 on x86_64-linux. So, what exactly is miscompiled with that patch applied? -O2 -fgraphite-identity? Something else?
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-16 13:39:21 UTC --- (In reply to comment #5) (In reply to comment #2) I don't understand what you mean by inlining, since '_Rb_tree_node_base' is a *type* not a function. This is a constructor What? I see only free functions, like _Rb_tree_increment, and pointers to types like _Rb_tree_node_base. But I see that probably you just had a typo in your original message, you meant that the _Rb_tree_increment(_Rb_tree_node_base*) call is not inlined in _Rb_tree_increment(const _Rb_tree_node_base*). Still, I don't see *what* really changed post-Benjamin split and *why*. Jakub may have already figured out that, I don't.
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-16 13:45:53 UTC --- By the way, I don't see anything wrong with explicitly marking _Rb_tree_increment(_Rb_tree_node_base*) inline if that helps in some special circumstances.
[Bug tree-optimization/52275] The polyhedron test air.f90 is miscompiled with '-O2 -floop-flatten' after revision 184265
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52275 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-16 13:46:30 UTC --- If I apply the pseudo-patch at the end, air still works fine at -O3 or -O2 on x86_64-linux. So, what exactly is miscompiled with that patch applied? -O2 -fgraphite-identity? Something else? Please read the beginning of the post: Revision 184265 fixes the ICE I saw on the 2005 polyhedron test air.f90. However as reported in comment #9 of pr50561, the test is miscompiled with '-O2 -floop-flatten' and higher optimization: Can it be clearer?
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-16 13:52:38 UTC --- Thanks Jakub that's definitely possible, and my knowledge of libtool is very weak anyway. My operative suggestion stands, I guess.
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-16 13:50:46 UTC --- ... besides the trivial fact that then isn't exported anymore. For that we can simply refactor the actual code and call it as-is or via the const_cast from the two exported _Rb_tree_increment.
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-16 13:59:20 UTC --- Created attachment 26676 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26676 Draft Something like this. I suppose either static or inline should do the trick. Maybe submitter can test both variants.
[Bug other/52278] New: [avr] inefficient register allocation for SUBREGs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278
Bug #: 52278
Summary: [avr] inefficient register allocation for SUBREGs
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization, ra
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr
Suppose the following small function compiled for AVR.
Remember AVR is 8-bit machine with int = HImode and UNITS_PER_WORD = 1.
int add (int val)
{
return val + 1;
}
The addition can be performed in one insn; val and return value are passed in
HI:24 as you can see in .ira dump:
(insn 6 3 19 2 (parallel [
(set (reg:HI 45)
(plus:HI (reg:HI 24 r24 [ val ])
(const_int 1 [0x1])))
(clobber (scratch:QI))
]) add.c:3 42 {addhi3_clobber}
(expr_list:REG_DEAD (reg:HI 24 r24 [ val ])
(nil)))
(insn 19 6 20 2 (set (reg:QI 24 r24)
(subreg:QI (reg:HI 45) 0)) add.c:4 18 {movqi_insn}
(nil))
(insn 20 19 14 2 (set (reg:QI 25 r25 [+1 ])
(subreg:QI (reg:HI 45) 1)) add.c:4 18 {movqi_insn}
(expr_list:REG_DEAD (reg:HI 45)
(nil)))
(insn 14 20 0 2 (use (reg/i:HI 24 r24)) add.c:4 -1
(nil))
IRA writes:
Pushing a0(r45,l0)(cost 0)
Popping a0(r45,l0) -- assign reg 18
Disposition:
0:r45 l018
i.e. it assigns pseudo HI:45 to hard register HI:18 and thus causes inefficient
code because it happily moves values around without need.
.reload generates additional move insns to satisfy the constraints of addhi3
which are basically =r, %0, rn i.e. addition is a 2-operand insn where op0
and op1 must be in the same hard register:
(insn 23 3 6 2 (set (reg:HI 18 r18 [45])
(reg:HI 24 r24 [ val ])) add.c:3 22 {*movhi}
(nil))
(insn 6 23 19 2 (parallel [
(set (reg:HI 18 r18 [45])
(plus:HI (reg:HI 18 r18 [45])
(const_int 1 [0x1])))
(clobber (scratch:QI))
]) add.c:3 42 {addhi3_clobber}
(nil))
(insn 19 6 20 2 (set (reg:QI 24 r24)
(reg:QI 18 r18 [45])) add.c:4 18 {movqi_insn}
(nil))
(insn 20 19 14 2 (set (reg:QI 25 r25 [+1 ])
(reg:QI 19 r19 [+1 ])) add.c:4 18 {movqi_insn}
(nil))
However, the machine could just as well do the addition in HI:24 directly like
so:
(parallel [(set (reg:HI 24 r24)
(plus:HI (reg:HI 24)
(const_int 1)))
(clobber (scratch:QI))]) {addhi3_clobber}
The code above is just a small example to show the problem, but the issue also
occurs with more complex code and not only for return and parameter registers.
== Command line ==
avr-gcc add.c -c -mmcu=avr4 -Os -save-temps -dp -da
== configure ==
../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --enable-languages=c,c++
--with-dwarf2 --enable-checking=yes,rtl
Thread model: single
gcc version 4.7.0 20120206 (experimental) (GCC)
[Bug target/52238] -mms-bitfields: __attribute__ ((aligned (n))) ignored for struct members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52238
--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-16 14:03:29
UTC ---
Hmm, right. The previous field needs to be cleared for ms-bitfields, too.
Index: stor-layout.c
===
--- stor-layout.c (revision 184287)
+++ stor-layout.c (working copy)
@@ -1141,15 +1141,14 @@
}
/* Does this field automatically have alignment it needs by virtue
- of the fields that precede it and the record's own alignment?
- We already align ms_struct fields, so don't re-align them. */
- if (known_align desired_align
- !targetm.ms_bitfield_layout_p (rli-t))
+ of the fields that precede it and the record's own alignment? */
+ if (known_align desired_align)
{
/* No, we need to skip space before this field.
Bump the cumulative size to multiple of field alignment. */
- if (DECL_SOURCE_LOCATION (field) != BUILTINS_LOCATION)
+ if (!targetm.ms_bitfield_layout_p (rli-t)
+ DECL_SOURCE_LOCATION (field) != BUILTINS_LOCATION)
warning (OPT_Wpadded, padding struct to align %q+D, field);
/* If the alignment is still within offset_align, just align
@@ -1171,7 +1170,8 @@
if (! TREE_CONSTANT (rli-offset))
rli-offset_align = desired_align;
-
+ if (targetm.ms_bitfield_layout_p (rli-t))
+rli-prev_field = NULL;
}
/* Handle compatibility with PCC. Note that if the record has any
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 13:48:59 UTC --- libtool apparently creates convenience libraries only with -fPIC stuff in it, instead of having two sets of objects for each source, one -fPIC and one non-fPIC. Not sure if it is possible to override that behavior somehow. So, when in 4.6 we had just libsupc++_convenience.la linked into libstdc++.la, only the libsupc++ objects were -fPIC in libstdc++.a and the rest, not coming from convenience library, was -fno-pic. Now that everything else comes also from convenience libraries, everything is -fPIC. Not sure what is desirable...
[Bug other/52278] [avr] inefficient register allocation for SUBREGs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-16 14:00:59 UTC --- Created attachment 26677 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26677 add.c
[Bug other/52278] [avr] inefficient register allocation for SUBREGs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-16 14:06:43 UTC --- Created attachment 26680 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26680 add.c.198r.reload
[Bug other/52278] [avr] inefficient register allocation for SUBREGs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278 --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-16 14:04:02 UTC --- Created attachment 26679 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26679 add.c.197r.ira
[Bug fortran/52279] New: Fortran translation issues issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279 Bug #: 52279 Summary: Fortran translation issues issues Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Blocks: 52274 A) gfc_check_conformance - but possibly others - have: if (gfc_check_conformance (op1, op2, elemental binary operation) != SUCCESS) and then in gfc_check_conformance: gfc_error (Different shape for %s at %L on dimension %d (%d and %d), _(buffer), op1-where, d + 1, There are two issues: The passed string is not marked as to be translated. One should use G_() [non-std-C string], N_(), or _(). And translating Different shape for at %L on dimension %d elemental binary operation properly is difficult without the context. B) gfc_check_intrinsic_standard case GFC_STD_F95: symstd_msg = new in Fortran 95; ... gfc_warning (Intrinsic '%s' (is %s) is used at %L, isym-name, _(symstd_msg), where); Again, the symstd_msg text does not end up in the .pot file. Additionally, translating (is %s) is rather difficult. At least the 'is ' should moved into symstd_msg; possibly the whole string. [For the latter: Be careful that %s etc. still get expanded correctly.] C) There are probably some more such items. D) In some cases, giving translation hints would help translators.
[Bug other/52278] [avr] inefficient register allocation for SUBREGs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-16 14:03:05 UTC --- Created attachment 26678 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26678 add.s Assembler output with -c -mmcu=avr4 -Os -save-temps -dp -da To see reasonable code, add -fno-split-wide-types
[Bug fortran/42693] Missing gcc-internal-format on messages from gfc_arith_error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42693 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org Blocks||52274 Depends on|52274 | --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-16 14:05:17 UTC --- (In reply to comment #1) a simple hack would be to use: + /* xgettext:gcc-internal-format */ I think the best would be to mark those lines with %L via G_() instead of _. There are plenty such lines. (Cf. also PR 52279)
[Bug tree-optimization/52275] The polyhedron test air.f90 is miscompiled with '-O2 -floop-flatten' after revision 184265
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52275 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-16 14:19:30 UTC --- This is the following subroutine that is miscompiled at '-O2 -floop-flatten': !*==SPECTOP.spg processed by SPAG 6.55Dc at 09:26 on 23 Sep 2005 ! ! other routines ! SUBROUTINE SPECTOP(Dr,N) IMPLICIT REAL*8(A-H,o-Z) DIMENSION d1(0:32,0:32) , Dr(0:32,0:32) , x(0:32) REAL*8 Dr ! ! PROGRAM TO COMPUTE THE CHEBYSHEV SPECTRAL OPERATOR ! ang = DBLE(1) s = DBLE(6) o = DBLE(1) t = DBLE(2) pi = t*DASIN(ang) DO i = 0 , N x(i) = DCOS(pi*DBLE(i)/DBLE(N)) ENDDO ! ! IF J=K ! DO j = 1 , N - 1 d1(j,j) = -x(j)/(t*(o-x(j)**2)) ENDDO d1(0,0) = (t*DBLE(N)**2+o)/s d1(N,N) = -d1(0,0) ! ! IF J.NE.K ! fctr1 = 1.0D0 DO k = 0 , N ck = 1.0D0 IF ( k.EQ.0 ) ck = t IF ( k.EQ.N ) ck = t fctr2 = o DO j = 0 , N cj = o IF ( j.EQ.0 ) cj = t IF ( j.EQ.N ) cj = t fctr = fctr1*fctr2 IF ( j.NE.k ) THEN d1(k,j) = ck*fctr/(cj*(x(k)-x(j))) ENDIF fctr2 = -o*fctr2 ENDDO fctr1 = -o*fctr1 ENDDO DO k = 0 , N DO j = 0 , N Dr(k,j) = d1(N-k,N-j) ENDDO ENDDO CONTINUE END
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #25 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-16 14:22:33 UTC --- (In reply to comment #23) I'm fine with the last patch, though, I think it needs Ian to approve. Wouldn't it make more sense to file a joint PR with the OpenBSD folks in order to have the use of ucontext purged from libgo (considering that neither BSD should have it now and that feature has been deprecated from POSIX)?
[Bug tree-optimization/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #6 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-02-16 14:42:36 UTC --- I've checked. The patch fixes the regression. Thanks.
[Bug tree-optimization/52275] The polyhedron test air.f90 is miscompiled with '-O2 -floop-flatten' after revision 184265
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52275 --- Comment #3 from Tobias Grosser grosser at gcc dot gnu.org 2012-02-16 14:00:29 UTC --- It seems there Sebastian himself sees the loop flatteing pass as currently unstable: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335#c8 I would propose to follow his suggestion, disable it for now and readd it as soon as graphite is moved to isl. If anybody else can contribute a patch that fixes the remaining loop flattening problems, I am obviously glad to have a look,
[Bug tree-optimization/43491] Unnecessary temporary for global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-16 14:43:51 UTC --- With tree hoisting we generate bb 2: pretmp.5_19 = data_0; pretmp.5_20 = data_3; i_21 = pretmp.5_19 + pretmp.5_20; if (data_3(D) != 0) goto bb 3; else goto bb 4; bb 3: bb 4: # v_1 = PHI v_7(D)(3), 2(2) # i_2 = PHI i_21(3), 5(2) D.1719_14 = v_1 * i_21; D.1718_15 = i_2 * D.1719_14; return D.1718_15; instead of bb 2: if (data_3(D) != 0) goto bb 4; else goto bb 3; bb 3: pretmp.5_19 = data_0; pretmp.5_21 = data_3; i_23 = pretmp.5_19 + pretmp.5_21; goto bb 5; bb 4: data_0.0_4 = data_0; data_3.1_5 = data_3; i_6 = data_0.0_4 + data_3.1_5; bb 5: # v_1 = PHI v_7(D)(4), 2(3) # i_2 = PHI i_6(4), 5(3) # i_24 = PHI i_6(4), i_23(3) D.1719_14 = v_1 * i_24; D.1718_15 = i_2 * D.1719_14; return D.1718_15; } I suppose that's good enough? See that PRE still inserts loads from register variables, not sure if you'd want to disallow that as well.
[Bug tree-optimization/52275] The polyhedron test air.f90 is miscompiled with '-O2 -floop-flatten' after revision 184265
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52275 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-16 14:52:17 UTC --- The subroutine SPECTOP has been the cause of pr42181. The two variants in comment #22 behave the same way when compiled with '-O2 -floop-flatten', i.e., the variant with if (j.ne.k) d1(k,j) = fctr/(x(k)-x(j)) is miscompiled.
[Bug ada/52280] New: FAIL: c974013 -- C974013 Abortable part did not execute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52280 Bug #: 52280 Summary: FAIL: c974013 -- C974013 Abortable part did not execute Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 splitting /test/gnu/gcc/objdir/gcc/testsuite/ada/acats/tests/c9/c974013.a into: c974013.adb BUILD c974013.adb gnatmake --GCC=/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -gnat ws -O2 -I/test/gnu/gcc/objdir/gcc/testsuite/ada/acats/support c974013.adb -largs --GCC=/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/objdir/gcc/xgcc -c -B/test/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/test /gnu/gcc/objdir/gcc/testsuite/ada/acats/support c974013.adb gnatbind -I/test/gnu/gcc/objdir/gcc/testsuite/ada/acats/support -x c974013.ali gnatlink c974013.ali -O2 --GCC=/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/obj dir/gcc/ RUN c974013 ,.,. C974013 ACATS 2.5 12-02-15 11:57:52 C974013 Asynchronous Select: Trigger is delay_until which completes before abortable part. * C974013 Abortable part did not execute. C974013 FAILED . FAIL: c974013
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-16 15:04:42 UTC --- Note, if we decide to do this at the level of tree.cc, we should consistently change _Rb_tree_decrement too.
[Bug c++/52281] New: No warnings generated for unused captures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52281
Bug #: 52281
Summary: No warnings generated for unused captures
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bootsare...@gmail.com
I would expect the code:
int main()
{
int i = 23;
auto x = [i]() {return 25;};
x();
return 0;
}
to issue a warning when compiled with -Wall -Wextra similar to unused
variables.
This seems similar to this:
struct foo {
int operator()() { return 42;}
int x;
};
gcc does not issue a warning here as well, although it might be useful.
[Bug rtl-optimization/52208] [4.7 Regression] Useless store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52208 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 15:34:35 UTC --- Author: jakub Date: Thu Feb 16 15:34:28 2012 New Revision: 184310 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184310 Log: PR rtl-optimization/52208 * ira-costs.c (scan_one_insn): Don't decrease mem_cost for MEMs with REG_EQUIV, if the MEM isn't general_operand. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #26 from Ian Lance Taylor ian at airs dot com 2012-02-16 15:48:18 UTC --- I think it would be great if somebody would tell me something I can used instead of makecontext/getcontext/setcontext. Unless somebody can come up with one, then I think the only alternative is to write our own processor-specific versions and distribute them with libgo. The functions were removed from POSIX not because there was any adequate replacement, but because they suffer from some design deficiencies.
[Bug c++/52282] New: [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
Bug #: 52282
Summary: [C++0x] ICE / confused by earlier errors with
decltype/constexpr
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andyg1...@hotmail.co.uk
The following code causes the compiler problems. The version I am using is gcc
4.7.0-20120210.
template typename T, T V
struct A
{
static constexpr T a() { return V; }
};
template typename T, T V
struct B
{
typedef T type;
static constexpr type b() { return V; }
};
template typename T, T V
struct C
{
static constexpr decltype(V) c() { return V; }
};
static_assert(Aint, 10::a() == 10, oops);
static_assert(Bint, 10::b() == 10, oops);
static_assert(Cint, 10::c() == 10, oops);
struct D
{
static constexpr int d() { return 10; }
};
static_assert((Aint(*)(), D::d::a())() == 10, oops);
static_assert((Bint(*)(), D::d::b())() == 10, oops); // line 30
static_assert((Cint(*)(), D::d::c())() == 10, oops);
The code as given above will give the following output:
1.cpp:30:1: error: non-constant condition for static assertion
1.cpp:30:38: error: expression ‘D::d’ does not designate a constexpr function
1.cpp:17: confused by earlier errors, bailing out
Commenting out the line 30 will produce an ICE instead:
1.cpp: In instantiation of ‘struct Cint (*)(), D::d’:
1.cpp:31:34: required from here
1.cpp:17:31: internal compiler error: in finish_decltype_type, at
cp/semantics.c:5277
There are two issues here: the first is, of course, the ICE; the second is that
gcc is not correctly determining the return type when it is abstracted as in
structs B and C and the type is a static function pointer.
Note that non-static member function pointers do not generate either issues,
although it is necessary to add const to the pointer type but not to the
corresponding function definition:
struct E
{
constexpr int e() { return 10; }
};
constexpr E e;
static_assert((e.*Aint(E::*)()const, E::e::a())() == 10, oops);
static_assert((e.*Bint(E::*)()const, E::e::b())() == 10, oops);
static_assert((e.*Cint(E::*)()const, E::e::c())() == 10, oops);
[Bug tree-optimization/52188] [4.7 regression] IPA-CP change broke libstdc++ symbol versioning on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52188 --- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org 2012-02-16 15:55:04 UTC --- First and foremost, sorry for the big delay but I could not have a look at this PR earlier. Nevertheless, I doubt that the decision of the new IPA-CP not to clone the function in question can be called a bug. Yes, if the heuristics or other early optimizations results change, the cloning decision might change again in the future - even in between minor versions if we are really unlucky.
[Bug go/52218] [4.7 Regression] libgo ftbfs on arm-linux-gnueabi (unknown case for SETCONTEXT_CLOBBERS_TLS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52218 --- Comment #3 from Matthias Klose doko at gcc dot gnu.org 2012-02-16 16:08:18 UTC --- delaying this until PR52266 can be fixed
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #27 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-16 16:22:02 UTC --- (In reply to comment #26) I think it would be great if somebody would tell me something I can used instead of makecontext/getcontext/setcontext. Unless somebody can come up with one, then I think the only alternative is to write our own processor-specific versions and distribute them with libgo. The functions were removed from POSIX not because there was any adequate replacement, but because they suffer from some design deficiencies. Would implementing cooperative threading with pthreads, perhaps with conditional variables, as described in... http://stackoverflow.com/questions/4298986/is-there-something-to-replace-the-ucontext-h-functions be appropriate?
[Bug c/52283] New: error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283
Bug #: 52283
Summary: error: case label does not reduce to an integer
constant for constant folded cast expr
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ch...@gcc.gnu.org
extern int u;
void b (int c)
{
switch (c)
{
case (int) ( 2 | ( (4 8 ) ? 8 : u ) ) :
break;
}
}
fails with
i.c:8:5: error: case label does not reduce to an integer constant
since GCC 4.6.2.
While is is legitimately a user error with respect to the standard, this brings
legacy issue for code that used to build with GCC 4.5. Note that GCC is usually
permissive with reduced integer constant use in case label, see PR39613.
This change seems to have appeared with the removal of the lines in
c-common.c:check_case_value
/* ??? Can we ever get nops here for a valid case value? We
shouldn't for C. */
STRIP_TYPE_NOPS (value);
so the check for INTEGER_CST now fails and fallthu into the error.
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #1 from chrbr at gcc dot gnu.org 2012-02-16 16:49:38 UTC --- Note that the TREE_NO_WARNING is introduced in convert_to_integer:596 while because of the unsigned-int type conversion in build_c_cast. A first attempt to fix is to set TREE_NO_WARNING on the constant (!CAN_HAVE_LOCATION_P) without creating the NOP_EXPR. But Richard explained: On 02/16/2012 01:58 PM, Richard Guenther wrote: You cannot have it on possibly shared tree nodes. CAN_HAVE_LOCATION_P tree nodes are not shared (the reverse is not true).
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #28 from Ian Lance Taylor ian at airs dot com 2012-02-16 16:50:13 UTC --- Using pthreads will be much less efficient than the current code using getcontext/setcontext. Writing machine-specific replacement code would be a much better idea than that.
[Bug translation/52284] New: translatable string typo: compatable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52284 Bug #: 52284 Summary: translatable string typo: compatable Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassig...@gcc.gnu.org ReportedBy: sti...@antcom.de gcc/config/rx/rx.opt:90: ... The default is to generate GAS compatable syntax. - ... compatible ...
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 17:01:53 UTC --- I'd say you should (when not pedantic) just attempt to handle TREE_NO_WARNING nops in the case handling code, as if the nops weren't there. I hope we'll eventually extend TREE_NO_WARNING to be a bit that thise tree should be looked up in some hash table on what warnings should be suppressed on it, so that TREE_NO_WARNING does only disable warnings that it wants to.
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-02-16 17:09:30 UTC --- On Thu, 16 Feb 2012, jakub at gcc dot gnu.org wrote: I hope we'll eventually extend TREE_NO_WARNING to be a bit that thise tree should be looked up in some hash table on what warnings should be suppressed on it, so that TREE_NO_WARNING does only disable warnings that it wants to. That won't help with the issue of not being able to set it on shared trees, of course; you'll need separate trees for each use of a constant or declaration for that.
[Bug target/52268] tls support should be added for darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268
--- Comment #1 from Mike Stump mikestump at comcast dot net 2012-02-16
17:15:47 UTC ---
If you could snapshot some codegen, say
void foo() {
static __thread int i = 42;
++i;
}
or somesuch, we could see if they wired it up the same was as gcc is normally
wired. I suspect it should be fairly close. I'm thinking this should be easy
to wire up.
[Bug libitm/52220] FAIL: libitm.c++/eh-1.C execution test due to Xcode 4 weakref linker bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52220 --- Comment #4 from Mike Stump mikestump at comcast dot net 2012-02-16 17:16:39 UTC --- Thanks.
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-02-16 17:31:04 UTC --- (In reply to comment #3) On Thu, 16 Feb 2012, jakub at gcc dot gnu.org wrote: I hope we'll eventually extend TREE_NO_WARNING to be a bit that thise tree should be looked up in some hash table on what warnings should be suppressed on it, so that TREE_NO_WARNING does only disable warnings that it wants to. That won't help with the issue of not being able to set it on shared trees, of course; you'll need separate trees for each use of a constant or declaration for that. What I don't understand is how Clang can track every constant / declaration separately and still consume ten times less memory than GCC. What is it that GCC is storing that takes so much space? In any case TREE_NO_WARNING is almost always a bad idea. It is indiscriminate, it silences any warning. It is unrelated to the warning code that it is trying to silence, so one has to track the logs to see why it was added. It imposes an overload that for most code is unnecessary (since most code is warning free). And many of its uses are a hack to workaround corner cases of other hacks, when the diagnostic code should just be smarter. What is the problem with stripping the nops *before giving the error* and if it still fails, give an error?
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-02-16 17:54:03 UTC --- On Thu, 16 Feb 2012, manu at gcc dot gnu.org wrote: What is the problem with stripping the nops *before giving the error* and if it still fails, give an error? NOPs are used to represent an intermediate expression that folded to an integer constant but is not an integer constant expression and cannot appear in one, as well as to carry TREE_NO_WARNING. So you need to be careful about where you strip them to avoid making something into an integer constant expression that should not be one; don't strip them too early. I think it would be OK to have a c_fully_fold_no_nop (which removes any TREE_NO_WARNING nop from the return from c_fully_fold) that is used in the relevant places (set_init_index, do_case, check_bitfield_type_and_width, build_enumerator at least) which have the pedwarn-if-pedantic logic for things folding to an integer constant where an integer constant expression is required.
[Bug c++/51415] [4.5/4.6/4.7 Regression] Broken diagnostic: 'vec_init_expr' not supported by dump_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51415 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug tree-optimization/52285] New: [4.7 Regression] libgcrypt _gcry_burn_stack slowdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285
Bug #: 52285
Summary: [4.7 Regression] libgcrypt _gcry_burn_stack slowdown
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
#define wipememory2(_ptr,_set,_len) do { \
volatile char *_vptr=(volatile char *)(_ptr); \
unsigned long _vlen=(_len); \
while(_vlen) { *_vptr=(_set); _vptr++; _vlen--; } \
} while(0)
#define wipememory(_ptr,_len) wipememory2(_ptr,0,_len)
__attribute__((noinline, noclone)) void
_gcry_burn_stack (int bytes)
{
char buf[64];
wipememory (buf, sizeof buf);
bytes -= sizeof buf;
if (bytes 0)
_gcry_burn_stack (bytes);
}
is one of the hot parts of gcrypt camellia256 ECB benchmark which apparently
slowed down in 4.7 compared to 4.6. The routine is called many times, usually
with bytes equal to 372.
The above first slowed down the whole benchmark from ~ 2040ms to ~ 2400ms (-O2
-march=corei7-avx -fPIC) in
http://gcc.gnu.org/viewcvs?root=gccview=revrev=178104
and then (somewhat surprisingly) became tiny bit faster again with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=181172 , which no longer tail
recursion optimizes the function (in this case suprisingly a win, but generally
IMHO a mistake).
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-02-16 18:25:30 UTC --- (In reply to comment #5) On Thu, 16 Feb 2012, manu at gcc dot gnu.org wrote: What is the problem with stripping the nops *before giving the error* and if it still fails, give an error? NOPs are used to represent an intermediate expression that folded to an integer constant but is not an integer constant expression and cannot appear in one, as well as to carry TREE_NO_WARNING. So you need to be careful about where you strip them to avoid making something into an integer constant expression that should not be one; don't strip them too early. Is this folding actually necessary for anything beyond diagnostics? I thought it was agreed that folding in the FEs was EVIL and we should stop doing it. I think it would be OK to have a c_fully_fold_no_nop (which removes any TREE_NO_WARNING nop from the return from c_fully_fold) that is used in the relevant places (set_init_index, do_case, check_bitfield_type_and_width, build_enumerator at least) which have the pedwarn-if-pedantic logic for things folding to an integer constant where an integer constant expression is required. I wouldn't be surprised if the compiler got noticeably faster by removing all early folding and all the workarounds and hacks that come with it, and replacing it by doing a temporary c_fully_fold at those specific places that needed it (and throwing away the result and keeping the original code around).
[Bug tree-optimization/52285] [4.7 Regression] libgcrypt _gcry_burn_stack slowdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 18:25:24 UTC --- While it will slow down this exact testcase even more, I think tailr/tailc passes should ignore CLOBBER stmts.
[Bug tree-optimization/52285] [4.7 Regression] libgcrypt _gcry_burn_stack slowdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 18:39:57 UTC --- This is also a libgcrypt bug, because clearly if it wants to burn some portion of the stack (assuming for security reasons), then 1) if it doesn't prevent tail recursion or tail call to itself, it doesn't do what it is trying to do, in particular it keeps overwriting with zeros the same portion of memory over and over 2) even if it isn't tail recursion/call optimized, on most targets it will still leave gaps on the stack not overwritten So, all in all, quite questionable way of burning cycles in the crypto library.
[Bug c/52286] New: wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52286 Bug #: 52286 Summary: wrong code bug Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: reg...@cs.utah.edu
[Bug c/52286] wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52286
John Regehr regehr at cs dot utah.edu changed:
What|Removed |Added
CC||chenyang at cs dot utah.edu
--- Comment #1 from John Regehr regehr at cs dot utah.edu 2012-02-16 18:48:18
UTC ---
[regehr@gamow 1]$ current-gcc -O0 small.c ; ./a.out
1
[regehr@gamow 1]$ current-gcc -O1 small.c ; ./a.out
0
[regehr@gamow 1]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r184311-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r184311-install
--program-prefix=r184311- --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20120216 (experimental) (GCC)
[regehr@gamow 1]$ cat small.c
int printf ( const char *, ... );
int c,
a,
b;
int
fn1 ( void )
{
return c 0;
}
int
main ( )
{
b = ( ~a | 0 = 0 ) 0x98685255F;
printf ( %d\n, ( ( b ) 0 ) );
return 0;
}
[Bug tree-optimization/52285] [4.7 Regression] libgcrypt _gcry_burn_stack slowdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 18:50:27 UTC --- Created attachment 26681 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26681 gcc47-pr52285.patch Patch to ignore clobber stmts in tailc/tailr passes. This turns this testcase back into a loop, for which the bad IVOPT decision matters.
[Bug c/52286] wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52286
--- Comment #2 from John Regehr regehr at cs dot utah.edu 2012-02-16 18:51:50
UTC ---
Sorry, previous one wasn't quite reduced.
int printf ( const char *, ... );
int a, b;
int main (void)
{
b = (~a | 0 = 0) 0x98685255F;
printf (%d\n, b 0);
return 0;
}
[Bug target/52268] tls support should be added for darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-02-16
Ever Confirmed|0 |1
--- Comment #2 from Iain Sandoe iains at gcc dot gnu.org 2012-02-16 18:53:33
UTC ---
somewhat different from the output generated, for example for x86-64-unk-linux
(-fPIC).
this is what clang version 3.1 (trunk 150612) : gives.
$ cat ../tests/thr-0.c
int foo (int f)
{
static __thread int ff ;
ff += f;
return ff;
}
$ ./install/bin/clang ../tests/thr-0.c -target x86_64-apple-darwin11 -S
$ more thr-0.s
.section__TEXT,__text,regular,pure_instructions
.globl _foo
.align 4, 0x90
_foo: ## @foo
.cfi_startproc
## BB#0:## %entry
pushq %rbp
Ltmp2:
.cfi_def_cfa_offset 16
Ltmp3:
.cfi_offset %rbp, -16
movq%rsp, %rbp
Ltmp4:
.cfi_def_cfa_register %rbp
subq$16, %rsp
movl%edi, -4(%rbp)
movl%edi, -8(%rbp) ## 4-byte Spill
movq_foo.ff@TLVP(%rip), %rdi
callq *(%rdi)
movl(%rax), %ecx
movl-8(%rbp), %edx ## 4-byte Reload
addl%edx, %ecx
movl%ecx, (%rax)
movl%ecx, %eax
addq$16, %rsp
popq%rbp
ret
.cfi_endproc
.tbss _foo.ff$tlv$init, 4, 2## @foo.ff
.section__DATA,__thread_vars,thread_local_variables
_foo.ff:
.quad __tlv_bootstrap
.quad 0
.quad _foo.ff$tlv$init
.subsections_via_symbols
=
$ ./install/bin/clang ../tests/thr-0.c -target i686-apple-darwin11 -S
$ more thr-0.s
.section__TEXT,__text,regular,pure_instructions
.globl _foo
.align 4, 0x90
_foo: ## @foo
## BB#0:## %entry
pushl %ebp
movl%esp, %ebp
subl$8, %esp
calll L0$pb
L0$pb:
popl%eax
movl8(%ebp), %ecx
movl%ecx, -4(%ebp)
movl_foo.ff@TLVP-L0$pb(%eax), %eax
movl%ecx, -8(%ebp) ## 4-byte Spill
calll *(%eax)
movl(%eax), %ecx
movl-8(%ebp), %edx ## 4-byte Reload
addl%edx, %ecx
movl%ecx, (%eax)
movl%ecx, %eax
addl$8, %esp
popl%ebp
ret
.tbss _foo.ff$tlv$init, 4, 2## @foo.ff
.section__DATA,__thread_vars,thread_local_variables
_foo.ff:
.long __tlv_bootstrap
.long 0
.long _foo.ff$tlv$init
.subsections_via_symbols
===
$ cat ../tests/thr-1.c
int foo (int f)
{
static __thread int ff = 1234;
ff += f;
return ff;
}
... much the same except
popq%rbp
ret
.cfi_endproc
.section__DATA,__thread_data,thread_local_regular
.align 2 ## @foo.ff
_foo.ff$tlv$init:
.long 1234## 0x4d2
.section__DATA,__thread_vars,thread_local_variables
_foo.ff:
.quad __tlv_bootstrap
.quad 0
.quad _foo.ff$tlv$init
--- and
popl%ebp
ret
.section__DATA,__thread_data,thread_local_regular
.align 2 ## @foo.ff
_foo.ff$tlv$init:
.long 1234## 0x4d2
.section__DATA,__thread_vars,thread_local_variables
_foo.ff:
.long __tlv_bootstrap
.long 0
.long _foo.ff$tlv$init
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 19:00:28 UTC --- (In reply to comment #6) Is this folding actually necessary for anything beyond diagnostics? I thought it was agreed that folding in the FEs was EVIL and we should stop doing it. Yes, in various places some folding is needed for language semantics, in other places for various extensions. The C FE does far less folding then it did. I wouldn't be surprised if the compiler got noticeably faster by removing all early folding and all the workarounds and hacks that come with it, and The C FE these days doesn't perform the folding right away, it fully folds only when needed (for some extension, or when passing down expressions to the gimplifier). And no, the C FE isn't anywhere on the radar compile time wise on the vast majority of code (the C++ FE on the other side does still a lot of folding (some unnecessary, some needed) early, on some sources the FE already shows in compile time usage, but the folding in it doesn't).
[Bug bootstrap/52287] New: [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287 Bug #: 52287 Summary: [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ber...@gcc.gnu.org, ebotca...@gcc.gnu.org Host: sparc-sun-solaris2.8 Target: sparc-sun-solaris2.8 Build: sparc-sun-solaris2.8 Between rev. 184203 and 184303, Solaris 8/SPARC bootstrap broke in stage2: $ cc1plus -fpreprocessed reginfo.ii -quiet -mcpu=v9 -g -O2 -fno-exceptions -fno-rtti -o reginfo.s /vol/gcc/src/hg/trunk/local/gcc/reginfo.c: In function 'int memory_move_secondary_cost(machine_mode, reg_class_t, bool)': /vol/gcc/src/hg/trunk/local/gcc/reginfo.c:716:1: internal compiler error: in ready_remove_first, at haifa-sched.c:1927 gdb finds (gdb) up #1 0x02ae1c64 in ready_remove_first (ready=0x346e558) at /vol/gcc/src/hg/trunk/local/gcc/haifa-sched.c:1927 1927 gcc_assert (QUEUE_INDEX (t) == QUEUE_READY); (gdb) p t $1 = (rtx) 0xf95db748 (gdb) pr (debug_insn 49 48 50 6 (var_location:SI from (reg/v:SI 119 [ rclass ])) -1 (nil)) I wonder if this could be related to 2012-02-14 Bernd Schmidt ber...@codesourcery.com * haifa-sched.c (prune_ready_list): Ensure that if there is a sched-group insn, it either remains alone or the entire list is pruned. Strangely, this doesn't occur on Solaris 9 and up. Rainer
[Bug c/52286] wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52286
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16
19:16:28 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=162943
Slightly adjusted testcase:
extern void abort (void);
int
main ()
{
int a, b;
asm volatile ( : =r (a) : 0 (0));
b = (~a | 1) -2038094497;
if (b = 0)
abort ();
return 0;
}
[Bug c/52286] [4.6/4.7 Regression] wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52286 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-16 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.3 Summary|wrong code bug |[4.6/4.7 Regression] wrong ||code bug Ever Confirmed|0 |1
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #32 from Anders F Björklund afb at users dot sourceforge.net 2012-02-16 19:28:22 UTC --- Then it's more about fixing library issues, like the macros used for TIOCNOTTY/TIOCSCTTY or st_atime/st_mtime/st_ctime and sysctl.
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #31 from Anders F Björklund afb at users dot sourceforge.net 2012-02-16 19:22:52 UTC --- Created attachment 26683 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26683 gcc-darwin_goc2c.patch
[Bug go/48501] 64bit-out.go, select5-out.go, tmp.go compilation times out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48501 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-16 19:25:56 UTC --- --- Comment #5 from Ian Lance Taylor ian at airs dot com 2012-02-14 18:06:55 UTC --- Should be fixed now. Let me know if you still see problems. Not with these three. Only Running target unix/-m64 FAIL: go.test/test/chan/doubleselect.go execution, -O2 -g WARNING: program timed out. times out consistently (64-bit only, Solaris 9 to 11). Rainer
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #30 from Anders F Björklund afb at users dot sourceforge.net 2012-02-16 19:22:25 UTC --- Created attachment 26682 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26682 gcc-gox_import.diff
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-02-16 19:24:10 UTC --- (In reply to comment #0) Note that non-static member function pointers do not generate either issues, although it is necessary to add const to the pointer type but not to the corresponding function definition: Adding const to the function type is required, because the constexpr specifier for any non-static member functions behaves as if the function were declared as const member function.
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #29 from Anders F Björklund afb at users dot sourceforge.net 2012-02-16 19:21:45 UTC --- It still needs to generate the extra underscore for Darwin, and it still needs to fix the bug mentioned in Comment #12.
[Bug c++/51415] [4.5/4.6/4.7 Regression] Broken diagnostic: 'vec_init_expr' not supported by dump_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51415 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2012-02-16 19:42:15 UTC --- Author: jason Date: Thu Feb 16 19:42:08 2012 New Revision: 184314 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184314 Log: PR c++/51415 * error.c (dump_expr): Handle lambda closures specifically. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-err1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog
[Bug go/48122] crypto/aes test fails on 32-bit Solaris 11/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48122 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-16 19:23:05 UTC --- --- Comment #2 from Ian Lance Taylor ian at airs dot com 2012-02-14 19:47:16 UTC --- I believe this is fixed now. The testsuite compilation now uses -fno-toplevel-reorder to ensure that the tests are run in the expected order. True, I just neglected to check and close those old PRs. Rainer
[Bug go/51874] Many libgo testsuite failures on IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|i386-pc-solaris2.1[01], |mips-sgi-irix6.5 |mips-sgi-irix6.5, | |sparc-sun-solaris2* | Status|WAITING |ASSIGNED Host|i386-pc-solaris2.1[01], |mips-sgi-irix6.5 |mips-sgi-irix6.5, | |sparc-sun-solaris2* | Summary|Many libgo testsuite|Many libgo testsuite |failures on Solaris, IRIX |failures on IRIX Build|i386-pc-solaris2.1[01], |mips-sgi-irix6.5 |mips-sgi-irix6.5, | |sparc-sun-solaris2* | Severity|major |normal --- Comment #13 from Rainer Orth ro at gcc dot gnu.org 2012-02-16 19:41:40 UTC --- No fundamental issues left on Solaris (either SPARC or x86), so making IRIX specific. While the big-endian chan patch improved IRIX results a bit, there's still something quite wrong. Need to investigate. Rainer
[Bug go/50654] Many Go tests fail on emutls targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50654 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-16 19:29:29 UTC --- --- Comment #2 from Ian Lance Taylor ian at airs dot com 2012-02-14 00:40:07 UTC --- Should be fixed on mainline. Although I only tested it on x86_64-unknown-linux-gnu built using --disable-tls to force the use of emutls. I got exactly the same set of failures on i386-pc-solaris2.11 with --disable-tls as on i386-pc-solaris2.8 with as/ld (i.e. emutls). Let me know if you still see problems. No, Solaris 8 and 9/x86 results are almost clean, and don't differ between emutls and native TLS. I'll file new PRs for the remaining problems if need be. Thanks. Rainer
[Bug middle-end/45472] [4.5/4.6/4.7 Regression] [Middle-end volatile semantics] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #19 from Jason Merrill jason at gcc dot gnu.org 2012-02-16
19:41:29 UTC ---
It seems to me that volatile reads/writes should get their own gimple
statements, not be part of a larger block move. So instead of
vv1 = vv2;
we should have
vv1.a ={v} vv2.a;
vv1.b ={v} vv2.b;
I agree with Paolo's comment in #12 that we want to copy the non-volatile parts
as a block when possible. It seems like breaking a simple struct assignment
into these separate statements would be best done in the gimplifier so that
front ends don't need to get this right independently.
Out of curiousity, what is the use case for a non-volatile struct object with
volatile members?
[Bug target/52205] unwinding through signal handler fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-16 19:46:02 UTC --- Fine with me (I won't make any of these changes myself though). I'll probably give it a whirl, but only after 4.7 has branched. For 4.8, there might be considerably simplifications possible since the old MxN libthread is gone then. Rainer
[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287 --- Comment #1 from Bernd Schmidt bernds at gcc dot gnu.org 2012-02-16 19:47:29 UTC --- Please attach the reginfo.ii file.
