[Bug target/48723] ICE in ix86_expand_prologue() with -fstack-check + function returning struct, on corei7-avx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48723 --- Comment #9 from Zdenek Sojka zsojka at seznam dot cz 2011-04-26 06:10:02 UTC --- This task is in state RESOLVED FIXED, but the testcase still ICEs in current trunk (r172940, x86_64-linux) as the fix was reverted. Where can I track this ICE? Thanks
[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48734 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.26 06:14:36 Component|c |tree-optimization CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 Summary|ICE in |[4.6/4.7 Regression] ICE in |eliminate_redundant_compari |eliminate_redundant_compari |son, at |son, at |tree-ssa-reassoc.c:1321 |tree-ssa-reassoc.c:1321 Target Milestone|--- |4.6.1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 06:14:36 UTC --- Related to PR45059, caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=159189
[Bug target/48769] New: [4.7 Regression] Multiple failures in libjava for -m64 on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48769 Summary: [4.7 Regression] Multiple failures in libjava for -m64 on powerpc-apple-darwin9 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ia...@gcc.gnu.org Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 Between revisions 172592 and 172898 multiple failures appeared in libjava for -m64 on powerpc-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg02373.html). My G5 will be down for at least the next two weeks and I'll be out of town for this period of time, so I'll unable to do further testing before mid May.
[Bug libfortran/48589] Invalid G0/G0.d editing for NaN/infinity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48589 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-26 06:40:41 UTC --- Tested ok on snapshot 20110423.
[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48734
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26
06:56:46 UTC ---
Reduced testcase:
unsigned int
foo (int x, unsigned int y, unsigned int z)
{
z = (x == -__INT_MAX__ - 1 ? x : -x) y;
z = (x == -__INT_MAX__ - 1 ? x : -x) y;
z = (x == -__INT_MAX__ - 1 ? x : -x) y;
return z;
}
The problem is that fold (from maybe_fold_and_comparisons) in this case
canonicalizes the comparison in:
/* The following case also applies to X signed_max+1
and X = signed_max+1 because previous transformations. */
if (code == LE_EXPR || code == GT_EXPR)
{
tree st;
st = signed_type_for (TREE_TYPE (arg1));
return fold_build2_loc (loc,
code == LE_EXPR ? GE_EXPR : LT_EXPR,
type, fold_convert_loc (loc, st, arg0),
build_int_cst (st, 0));
}
to include the extra cast to the signed cast and eliminate_redundant_comparison
is prepared to handle just one operation instead of two. I think expecting
fold to return some particular form of result is just wrong assumption, it will
break sooner or later, so while the code could perhaps handle on extra cast or
something similar, it needs to give up on elimination if the returned
expression can't be handled.
[Bug target/48723] ICE in ix86_expand_prologue() with -fstack-check + function returning struct, on corei7-avx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48723 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ubizjak at gmail dot com Resolution|FIXED | AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot ||gnu.org --- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2011-04-26 07:27:17 UTC --- .
[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48734 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 07:37:58 UTC --- Created attachment 24099 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24099 gcc46-pr48734.patch Untested fix.
[Bug c/44828] [4.3/4.4 Regression] possible integer wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Known to work|| Resolution||FIXED Target Milestone|4.3.6 |4.5.1 Known to fail|| --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 07:40:15 UTC --- Fixed for 4.5.1+.
[Bug tree-optimization/43781] [4.6 Regression] ice: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43781 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 08:11:42 UTC --- This has been fixed or made latent by http://gcc.gnu.org/viewcvs?root=gccview=revrev=159100
[Bug rtl-optimization/48757] internal compiler error: in compensate_edge, at reg-stack.c:2788
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48757 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||i686-pc-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.26 08:13:21 CC||ubizjak at gmail dot com Ever Confirmed|0 |1 Known to fail||4.5.3, 4.6.1, 4.7.0 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-04-26 08:13:21 UTC --- Confirmed with current mainline (-O2 -m32), we ICE in reg-stack.c, compensate_edge: /* We don't support abnormal edges. Global takes care to avoid any live register across them, so we should never have to insert instructions on such edges. */ gcc_assert (! (e-flags EDGE_ABNORMAL)); Where _.f.210r.stack shows that we want to compensate abnormal edges from bb 8: Edge 8-13: no changes needed Edge 8-9: correcting stack to empty Edge 8-12: correcting stack to empty Edge 8-11: correcting stack to empty ... ;; End of basic block 8 - ( 13 9 12 11) ;; lr out 7 [sp] 10 [st(2)] 11 [st(3)] ;; live out 7 [sp] 10 [st(2)] 11 [st(3)] ;; Succ edge 13 [25.0%] (ab,loop_exit) ;; Succ edge 9 [25.0%] (ab,loop_exit) ;; Succ edge 12 [25.0%] (ab,loop_exit) ;; Succ edge 11 [25.0%] (ab) Apparently, global does not work as expected.
[Bug rtl-optimization/48757] [4.5/4.6/4.7 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2788
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48757 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.5.3
[Bug tree-optimization/48768] [4.6/4.7 Regression] ICE in get_expr_operands()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48768
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.04.26 08:35:09
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.6.1
Summary|ICE in get_expr_operands() |[4.6/4.7 Regression] ICE in
||get_expr_operands()
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26
08:35:09 UTC ---
Smaller testcase for -O -g:
int a, b;
int
bar (void)
{
int i, j = 1;
for (i = 0; i != 10; i++)
{
lab:
if (i)
{
int *k = j;
}
else if (j)
goto lab;
}
return 1;
}
inline int
foo (int x)
{
unsigned int c = x;
int d = x;
if (bar ())
for (; c; c++)
while (x = 0)
if (foo (d) = 0)
{
d = bar ();
a = b ? b : 1;
}
return 0;
}
Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=160124
[Bug rtl-optimization/48757] [4.5/4.6/4.7 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2788
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48757 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Known to work||4.4.7 Summary|internal compiler error: in |[4.5/4.6/4.7 Regression] |compensate_edge, at |internal compiler error: in |reg-stack.c:2788|compensate_edge, at ||reg-stack.c:2788 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-04-26 08:33:43 UTC --- Regression from 4.4.
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 08:44:18 UTC --- (In reply to comment #9) I guess, in the 4.6.1 time frame we can only workaround the issue in C++03 mode by doing the piecewise work in the body. I can maybe help for the compiler work too but I need more guidance: is there an agreement about the C1X inspired builtin suggested by Joseph? In case, can I have a more specific reference? I'm adding in CC Richi too, in case he has additional tips and/or hints about the builtin work.. A __builtin_complex builtin should be almost trivial. It would be purely frontend sugar for frontends that lack a way to specify a complex value component-wise. The frontend would be resposible for lowering it to a COMPLEX_EXPR. I don't think the middle-end wants to deal with __builtin_complex as it already has a perfect matching tree code. Now I understand C++0x might have a proper syntax already, so I'm not sure how it relates to this (C++) bug. What changed in 4.6 is that we put complex values in registers even at -O0. You should be able to reproduce any issue in this bug in older releases with optimization turned on (given that the library implementation didn't change).
[Bug fortran/48588] [4.6/4.7 Regression] ICE (segfault) in gfc_get_nodesc_array_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48588 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-26 08:41:38 UTC --- Author: burnus Date: Tue Apr 26 08:41:31 2011 New Revision: 172953 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172953 Log: 2011-04-26 Tobias Burnus bur...@net-b.de PR fortran/48588 * parse.c (resolve_all_program_units): Skip modules. (translate_all_program_units): Handle modules. (gfc_parse_file): Defer code generation for modules. * module.c (fix_mio_expr): Commit created symbol. 2011-04-26 Tobias Burnus bur...@net-b.de PR fortran/48588 * gfortran.dg/whole_file_33.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/whole_file_33.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/module.c branches/gcc-4_6-branch/gcc/fortran/parse.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/48588] [4.6/4.7 Regression] ICE (segfault) in gfc_get_nodesc_array_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48588 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-26 08:42:48 UTC --- FIXED on the trunk (4.7) and on the 4.6 branch (for 4.6.1). Thanks for the report Andres!
[Bug lto/48683] [4.7 Regression] 252.eon in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48683 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2011-04-26 08:48:25 UTC --- Looking at our periodic tester results, it seems that it builds now and it started building at the same time 483.xalancbmk did. So I believe it indeed was a duplicate of PR 48585. *** This bug has been marked as a duplicate of bug 48585 ***
[Bug tree-optimization/43781] [4.6 Regression] ice: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43781 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 08:47:22 UTC --- I'd say made latent.
[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585 --- Comment #17 from Martin Jambor jamborm at gcc dot gnu.org 2011-04-26 08:48:25 UTC --- *** Bug 48683 has been marked as a duplicate of this bug. ***
[Bug debug/48768] [4.6/4.7 Regression] ICE in get_expr_operands()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48768 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 09:01:42 UTC --- Created attachment 24100 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24100 gcc46-pr48768.patch Untested fix.
[Bug tree-optimization/48714] gcc -O hangs gobbling memory, while gcc -O -fno-tree-fre finishes quickly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48714 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 09:20:14 UTC --- Dup. *** This bug has been marked as a duplicate of bug 48694 ***
[Bug tree-optimization/48694] [4.7 Regression] possible memory hog bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48694 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 09:20:14 UTC --- *** Bug 48714 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/48694] [4.7 Regression] possible memory hog bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48694 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 09:21:47 UTC --- Author: rguenth Date: Tue Apr 26 09:21:44 2011 New Revision: 172954 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172954 Log: 2011-04-26 Richard Guenther rguent...@suse.de PR middle-end/48694 * tree.h (OEP_CONSTANT_ADDRESS_OF): New operand_equal_flag. * fold-const.c (operand_equal_p): For TREE_CONSTANT ADDR_EXPRs compare the operands with OEP_CONSTANT_ADDRESS_OF. Treat trees with TREE_SIDE_EFFECTS equal when OEP_CONSTANT_ADDRESS_OF is set. * gcc.dg/torture/pr48694-1.c: New testcase. * gcc.dg/torture/pr48694-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr48694-1.c trunk/gcc/testsuite/gcc.dg/torture/pr48694-2.c Modified: trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h
[Bug fortran/48112] [4.6/4.7 Regression] generic interface to external function in module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48112 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-26 09:18:31 UTC --- Seems as if the regression has been introduced in by one of the 16 commits between: Working: 2010-05-13-r159362 Failing: 2010-05-18-r159523 Janus, I have the feeling that it is caused either by Rev. 159506 or by Rev. 159476 (PR 44044); both are your commits. I quickly scanned the commits (all 16) but nothing looked suspicious. I think, one should start a regression hunt to narrow it down to a single commit.
[Bug tree-optimization/48694] [4.7 Regression] possible memory hog bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48694 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 09:22:01 UTC --- Fixed.
[Bug target/48767] compiler error: Segmentation fault with set void in va_arg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48767 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added Target|sh4-linux-gnu |sh*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.26 09:26:30 Component|c |target Host|sh4-linux-gnu | Ever Confirmed|0 |1 Build|sh4-linux-gnu | --- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-04-26 09:26:30 UTC --- This is a target problem. The patch below will fix it. BTW, I'm not sure that it's an invalid use of void or not in C, though g++ treats it as invalid. * config/sh/sh.c (sh_gimplify_va_arg_expr): Don't call targetm.calls.must_pass_in_stack for void type. --- ORIG/trunk/gcc/config/sh/sh.c2011-04-23 09:43:19.0 +0900 +++ trunk/gcc/config/sh/sh.c2011-04-26 10:40:25.0 +0900 @@ -8062,9 +8062,14 @@ sh_gimplify_va_arg_expr (tree valist, tr HOST_WIDE_INT size, rsize; tree tmp, pptr_type_node; tree addr, lab_over = NULL, result = NULL; - int pass_by_ref = targetm.calls.must_pass_in_stack (TYPE_MODE (type), type); + bool pass_by_ref; tree eff_type; + if (!VOID_TYPE_P (type)) +pass_by_ref = targetm.calls.must_pass_in_stack (TYPE_MODE (type), type); + else +pass_by_ref = false; + if (pass_by_ref) type = build_pointer_type (type);
[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48742 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.26 09:39:19 Ever Confirmed|0 |1
[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48752 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/48749] [4.7 Regression] internal compiler error: tree check: expected field_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48749 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Version|unknown |4.7.0 Target Milestone|--- |4.7.0
[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48742 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.4.4 Target Milestone|--- |4.5.4 Summary|Internal error in |[4.5/4.6/4.7 Regression] |glimplify_expr |Internal error in ||glimplify_expr
[Bug rtl-optimization/48757] [4.5/4.6/4.7 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2788
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48757 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 2011-04-26 09:54:14 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=152448
[Bug testsuite/48753] [4.7 Regression] FAIL: gcc.dg/tree-prof/val-prof-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48753 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 10:03:14 UTC --- Author: rguenth Date: Tue Apr 26 10:03:12 2011 New Revision: 172955 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172955 Log: 2011-04-26 Richard Guenther rguent...@suse.de PR testsuite/48753 * gcc.dg/tree-prof/val-prof-2.c: Adjust. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-prof/val-prof-2.c
[Bug testsuite/48753] [4.7 Regression] FAIL: gcc.dg/tree-prof/val-prof-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48753 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 10:03:27 UTC --- Fixed.
[Bug middle-end/48761] Indirect inlining needs to perform type checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48761 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.26 10:05:37 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 10:05:37 UTC --- We need to delay this checking to expand_call_inline ().
[Bug preprocessor/48740] Raw C++0x strings and trigraphs mix badly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48740 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 10:04:22 UTC --- Author: jakub Date: Tue Apr 26 10:04:18 2011 New Revision: 172956 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172956 Log: 2011-04-26 Jakub Jelinek ja...@redhat.com Backported from mainline 2011-04-24 Jakub Jelinek ja...@redhat.com PR preprocessor/48740 * lex.c (lex_raw_string): When raw string ends with ??) followed by raw prefix and , ensure it is preprocessed with ??) rather than ??]. * c-c++-common/raw-string-11.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/c-c++-common/raw-string-11.c Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/libcpp/ChangeLog branches/gcc-4_5-branch/libcpp/lex.c
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-26 10:03:41 UTC --- Thanks. Thus, since the original issue boils down to a C++ front-end issue only, I guess we have to wait for Jason' opinion whether we can avoid adding a builtin and go the way proposed by Gaby or not. I would really like to see this fixed for 4.6.1 too, I hope we can figure out something suited, minimally invasive and/or restricted to the C++0x codepath...
[Bug lto/48763] Inliner type ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48763 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.26 10:09:29 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 10:09:29 UTC --- Well. That specific place isn't proper now that the decls can be compatible but the call stmt can use a different type for calling. Any checking should extend/factor gimple_check_call_matching_types.
[Bug lto/48763] Inliner type ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48763 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 10:08:55 UTC --- *** Bug 48761 has been marked as a duplicate of this bug. ***
[Bug middle-end/48761] Indirect inlining needs to perform type checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48761 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 10:08:55 UTC --- dup *** This bug has been marked as a duplicate of bug 48763 ***
[Bug tree-optimization/48694] [4.7 Regression] possible memory hog bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48694 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 10:12:18 UTC --- Author: rguenth Date: Tue Apr 26 10:12:14 2011 New Revision: 172957 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172957 Log: 2011-04-26 Richard Guenther rguent...@suse.de PR middle-end/48694 * tree.h (OEP_CONSTANT_ADDRESS_OF): New operand_equal_flag. * fold-const.c (operand_equal_p): For TREE_CONSTANT ADDR_EXPRs compare the operands with OEP_CONSTANT_ADDRESS_OF. Treat trees with TREE_SIDE_EFFECTS equal when OEP_CONSTANT_ADDRESS_OF is set. * gcc.dg/torture/pr48694-1.c: New testcase. * gcc.dg/torture/pr48694-2.c: Likewise. Modified: trunk/gcc/ChangeLog
[Bug preprocessor/48248] [4.5 Regression] Wrong error message location when compiling preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 10:14:37 UTC --- Author: rguenth Date: Tue Apr 26 10:14:34 2011 New Revision: 172959 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172959 Log: 2011-04-26 Richard Guenther rguent...@suse.de PR preprocessor/48248 * c-ppoutput.c (maybe_print_line): Always optimize newlines for output size with -P. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-ppoutput.c
[Bug fortran/48112] [4.6/4.7 Regression] generic interface to external function in module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48112
--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-26
10:18:23 UTC ---
Rev. 159475 works, Rev. 159476 fails, which is the following commit:
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159476
Log:
2010-05-17 Janus Weil ja...@gcc.gnu.org
PR fortran/44044
* resolve.c (resolve_fl_var_and_proc): Move error messages here from ...
(resolve_fl_variable_derived): ... this place.
(resolve_symbol): Make sure function symbols (and their result
variables) are not resolved twice.
The crucial part of the patch is:
+ /* Avoid double resolution of function result symbols. */
+ if ((sym-result || sym-attr.result) (sym-ns != gfc_current_ns))
+return;
* * *
If one places a break point, one sees first:
(gdb) p sym-name
$5 = 0x2ab40ea8 test1
(gdb) p sym-ns-sym_root-name
$8 = 0x2ab40ea8 test1
(gdb) p ((sym-result || sym-attr.result) (sym-ns != gfc_current_ns))
$10 = 0
and then next:
(gdb) p sym-name
$14 = 0x2ab40ea0 test
(gdb) p sym-ns-sym_root-name
$15 = 0x2ab40ea0 test
(gdb) p gfc_current_ns-sym_root-name
$16 = 0x2ab40ea8 test1
And hence:
(gdb) p ((sym-result || sym-attr.result) (sym-ns != gfc_current_ns))
$17 = 1
and finally:
(gdb) p sym-name
$26 = 0x2ab40ea8 test1
(gdb) p sym-ns-sym_root-name
$27 = 0x2ab40ea8 test1
(gdb) p gfc_current_ns-sym_root-name
$28 = 0x2ab40ea0 test
(gdb) p ((sym-result || sym-attr.result) (sym-ns != gfc_current_ns))
$25 = 1
Seemingly, the ICE occurs unless both resolutions happen.
(I wonder whether one could use {sym-ns,gfc_current_namespace}-resolved to
decide whether one should continue or not; currently, one finds the values -1
and 0.)
[Bug middle-end/48770] New: [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48770 Summary: [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 24101 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24101 reduced testcase (from g++.dg/bprob/g++-bprob-1.C) Compiler output: $ rm *.gcda $ g++ -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop testcase.C $ valgrind -q ./a.out ==5350== Invalid read of size 8 ==5350==at 0x400D51: test_goto2(int) (testcase.C:10) ==5350==by 0x400D7E: main (testcase.C:14) ==5350== Address 0x8 is not stack'd, malloc'd or (recently) free'd Segmentation fault Fails only when compiled as C++ code. Tested revisions: r172940 - fail 4.6 r172337 - OK
[Bug preprocessor/48740] Raw C++0x strings and trigraphs mix badly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48740 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 10:39:43 UTC --- Fixed.
[Bug tree-optimization/48764] [4.5/4.6/4.7 Regression] wrong-code bug in gcc-4.5.x, related to __restrict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48764
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Known to work||4.4.4, 4.6.0
Keywords||wrong-code
Last reconfirmed||2011.04.26 10:43:12
Ever Confirmed|0 |1
Summary|wrong-code bug in |[4.5/4.6/4.7 Regression]
|gcc-4.5.x, related to |wrong-code bug in
|__restrict |gcc-4.5.x, related to
||__restrict
Target Milestone|--- |4.5.4
Known to fail||4.5.2
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26
10:43:12 UTC ---
The bug is that we somehow think after inlining
void FooBar::load(Loader) (struct FooBar * const this, struct Loader l)
{
...
bb 2:
D.3062_2 = this_1(D)-c1;
D.3079_9 = l_3(D)-buffer;
this_11 = (struct Buffer * const restrict) D.3079_9;
D.3083_12 = this_11-p;
memcpy (D.3062_2, D.3083_12, 1);
D.3083_13 = this_11-p;
D.3082_14 = D.3083_13 + 1;
this_11-p = D.3082_14;
D.3063_4 = this_1(D)-c2;
D.3064_5 = l_3(D)-D.2415;
self_15 = (struct Loader ) D.3064_5;
D.3087_16 = self_15-buffer;
this_17 = (struct Buffer * const restrict) D.3087_16;
D.3091_18 = this_17-p;
memcpy (D.3063_4, D.3091_18, 1);
D.3091_19 = this_17-p;
D.3090_20 = D.3091_19 + 1;
this_17-p = D.3090_20;
return;
this_11 and this_17 only point to (different) objects. The restrict
machinery should be robust against inlining effects because it should
inherhit the arguments points-to set as well. In this case we have
l_3(D), points-to non-local, points-to vars: { }
self_15, points-to non-local, points-to vars: { }
though, and we explicitly ignore those:
/* If both pointers are restrict-qualified try to disambiguate
with restrict information. */
if (TYPE_RESTRICT (TREE_TYPE (ptr1))
TYPE_RESTRICT (TREE_TYPE (ptr2))
!pt_solutions_same_restrict_base (pi1-pt, pi2-pt))
return false;
/* Return true if both points-to solutions PT1 and PT2 for two restrict
qualified pointers are possibly based on the same pointer. */
bool
pt_solutions_same_restrict_base (struct pt_solution *pt1,
struct pt_solution *pt2)
{
/* If we deal with points-to solutions of two restrict qualified
pointers solely rely on the pointed-to variable bitmap intersection.
For two pointers that are based on each other the bitmaps will
intersect. */
if (pt1-vars_contains_restrict
pt2-vars_contains_restrict)
{
gcc_assert (pt1-vars pt2-vars);
return bitmap_intersect_p (pt1-vars, pt2-vars);
}
return true;
}
because all incoming restrict qualified pointers also point to NONLOCAL
(so restrict would be useless if we don't ignore that fact).
4.4 handles restrict in a completely different way.
4.6 and 4.7 manage to make more must-aliasing appearant which avoids
this issue to manifest in a miscompilation, but the issue itself is
latent.
[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48742
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 2011-04-26
11:03:50 UTC ---
Shorter testcase:
int
foo (void)
{
return 1 / 0 0;
}
Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=145254
C_MAYBE_CONST_EXPR leaking to gimplification.
[Bug tree-optimization/48764] [4.5/4.6/4.7 Regression] wrong-code bug in gcc-4.5.x, related to __restrict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48764
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26
11:17:59 UTC ---
The following fixes it (partially, global vars need similar treatment) at the
cost of extra decls and points-to bits.
We have to give what we point to a name, not only rely in the nonlocal glob.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 172817)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -4727,8 +4727,27 @@ intra_create_variable_infos (void)
}
for (p = get_vi_for_tree (t); p; p = p-next)
- if (p-may_have_pointers)
- make_constraint_from (p, nonlocal_id);
+ {
+ if (p-may_have_pointers)
+ {
+ struct constraint_expr lhsc, rhsc;
+ tree heapvar;
+ heapvar = create_tmp_var_raw (TREE_TYPE (TREE_TYPE (t)),
+ PARM_PT);
+ DECL_EXTERNAL (heapvar) = 1;
+ get_var_ann (heapvar)-is_heapvar = 1;
+ add_referenced_var (heapvar);
+ lhsc.var = p-id;
+ lhsc.type = SCALAR;
+ lhsc.offset = 0;
+ rhsc.var = get_vi_for_tree (heapvar)-id;
+ rhsc.type = ADDRESSOF;
+ rhsc.offset = 0;
+ process_constraint (new_constraint (lhsc, rhsc));
+
+ make_constraint_from (p, nonlocal_id);
+ }
+ }
if (POINTER_TYPE_P (TREE_TYPE (t))
TYPE_RESTRICT (TREE_TYPE (t)))
make_constraint_from_restrict (get_vi_for_tree (t), PARM_RESTRICT);
it would be nice if we could avoid allocating decls for such things
(in principle we could simply allocate a DECL_UID only).
[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48742
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26
11:27:10 UTC ---
The problem is that first build_binary_op wraps 1 / 0 into C_MAYBE_CONST_EXPR,
if (!in_late_binary_op)
{
if (!op0_maybe_const || TREE_CODE (op0) != INTEGER_CST)
op0 = c_wrap_maybe_const (op0, !op0_maybe_const);
if (!op1_maybe_const || TREE_CODE (op1) != INTEGER_CST)
op1 = c_wrap_maybe_const (op1, !op1_maybe_const);
}
and later on the whole GT_EXPR with C_MAYBE_CONST_EXPR op0 and INTEGER_CST op1
is wrapped in yet another C_MAYBE_CONST_EXPR:
else if (TREE_CODE (ret) != INTEGER_CST int_operands
!in_late_binary_op)
ret = note_integer_operands (ret);
Apparently, c_fully_fold_internal doesn't handle nested C_MAYBE_CONST_EXPRs
though, if it finds one, it doesn't recurse on the content and just returns it.
Joseph?
[Bug tree-optimization/48766] [4.3/4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.1.2 Keywords||ice-on-valid-code Last reconfirmed||2011.04.26 11:29:36 Ever Confirmed|0 |1 Summary|Infinite recursion in |[4.3/4.4/4.5/4.6/4.7 |fold_binary_loc() |Regression] Infinite ||recursion in ||fold_binary_loc() Target Milestone|--- |4.3.6 Known to fail||4.3.4 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 11:29:36 UTC --- Confirmed.
[Bug target/42210] avr: optimizing assignment to a bit field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42210 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-04-26 11:35:23 UTC --- Created attachment 24102 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24102 extended testcase Added testcase with some more variations of setting bits in I/O theme.
[Bug debug/48768] [4.6/4.7 Regression] ICE in get_expr_operands()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48768 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 11:35:01 UTC --- Ugh. Well, ok I suppose.
[Bug target/48769] [4.7 Regression] Multiple failures in libjava for -m64 on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48769 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/48732] Nested loops with small iteration count gobble time in tree reassociation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48732 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 12:13:50 UTC --- With -O1 we do not perform expensive control-dependend DCE and thus do not end up removing the empty loops. We do however remove the dead store in the innermost loop which then causes us to compute that completely unrolling all loops is profitable (we basically see it's all dead code that will be produced). Now, unfortunately before removing all that dead code we perform re-association on the induction variable increment chains ... of which there are a lot (8 ^ n ones and more, actually). We've known for quite some time that not doing constant propagation and dead code elimination on the unrolled loop bodies isn't the best idea (induction variable analysis is also pessimized by not doing CSE on those). The only CCP-like pass after loop opts is VRP which does not run at -O2, or DOM and both runs after re-assoc (though I don't see a particularly good reason for that fact). Scheduling DOM right after loop opts fixes this. But a more proper fix would be to do cleanups closer to unrolling.
[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48734 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 12:15:13 UTC --- Looks good to me.
[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48770 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug lto/48763] Inliner type ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48763 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-26 12:56:30 UTC --- I would say that PR48761 testcase is not 100% dup of this one. One tests that cgraph merging check type compatibility of direct call edges, the second tests that ipa-prop does type compatibility check when turing indirect edge to direct. I guess only way to go is to stomp call expression types to the callgraph edges. Doable, but ugly since it will add need to store types into callgraph sections that are currently simple blocks. Or to make inliner and ipa-prop to handle all cases, even those not type compatible, right? This is not really my area, so I would hope someone to beat me on this problem :))
[Bug c/48731] regression: __attribute__((flatten)) produces error with function calling variadic functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48731 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 12:59:33 UTC --- Author: rguenth Date: Tue Apr 26 12:59:22 2011 New Revision: 172963 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172963 Log: 2011-04-26 Richard Guenther rguent...@suse.de PR tree-optimization/48731 * ipa-inline.c (cgraph_flatten): Test if function is inlinable. * gcc.dg/torture/pr48731.c: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr48731.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/ipa-inline.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c/48731] regression: __attribute__((flatten)) produces error with function calling variadic functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48731 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 13:00:58 UTC --- Author: rguenth Date: Tue Apr 26 13:00:53 2011 New Revision: 172964 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172964 Log: 2011-04-26 Richard Guenther rguent...@suse.de PR tree-optimization/48731 * gcc.dg/torture/pr48731.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr48731.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48752 --- Comment #9 from Jan Hubicka hubicka at ucw dot cz 2011-04-26 13:06:08 UTC --- Looks like the issue is somehow caused by caller being a global constructor. Hmm, yes, it is entirely possible - when new functions are added, we need to analyze them. I tought it is happening now, but it is not. I will check it. Honza
[Bug lto/48763] Inliner type ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48763 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 13:05:32 UTC --- (In reply to comment #4) I would say that PR48761 testcase is not 100% dup of this one. One tests that cgraph merging check type compatibility of direct call edges, the second tests that ipa-prop does type compatibility check when turing indirect edge to direct. The issue is the same, it will manifest in all IPA passes, with and without LTO now that we happily create direct calls from originally mismatching indirect calls. I guess only way to go is to stomp call expression types to the callgraph edges. Doable, but ugly since it will add need to store types into callgraph sections that are currently simple blocks. Or to make inliner and ipa-prop to handle all cases, even those not type compatible, right? This is not really my area, so I would hope someone to beat me on this problem :)) We should defer detection of incompatibilities to when we see the call stmt, thus expand_call_inline. We shouldn't worry about this disturbing inliner heuristics too much. IPA optimizations should do propagation as-if things match, deal with missing arguments (or missing arg slots) properly by giving up and do the same checking when applying a transform. I don't think trying to move more information to WPA stages on the edges is the way to go.
[Bug c/48731] regression: __attribute__((flatten)) produces error with function calling variadic functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48731 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 13:01:55 UTC --- Fixed.
[Bug testsuite/48753] [4.7 Regression] FAIL: gcc.dg/tree-prof/val-prof-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48753 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-04-26 13:17:23 UTC --- On Linux/ia32, revision 172962 gave FAIL: gcc.dg/tree-prof/val-prof-2.c scan-tree-dump optimized n_[0-9]* \+ 4294967295
[Bug lto/48763] Inliner type ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48763 --- Comment #6 from Jan Hubicka hubicka at ucw dot cz 2011-04-26 13:20:24 UTC --- We should defer detection of incompatibilities to when we see the call stmt, thus expand_call_inline. We shouldn't worry about this disturbing inliner Undoing the inliner decisions at expand_call_inline is not trivial. 1) We would have to turn inline clone back to offline copy of the function if one doesn't exist. 2) Doing so would resoult in duplicated offline copies of function when such copy really exist but WPA made it static and put into a different partition. 3) With the inliner analysis being able to figure out what references and calls will be optimized out in particular inline clone based on knowledge of its argument, there is no way to output those references (they might refer things not exported from different WPA partitions). So the offline clone would have to be clone with the constants figured out by the inliner propagated in. I am not sure if those are all problems, but I guess we can go this way, but it is remarkably ugly. Also we need smilar kind of validation for ipa-prop. Jump functions will get confused on calls with mismatching types. This would mean that the constant propagation trick above might fail making things even more messy (ie. propagating constant into a structure argument or so). Honza
[Bug tree-optimization/48766] [4.3/4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||iant at google dot com --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-04-26 13:26:19 UTC --- It is caused by revision 121254: http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00960.html which adds -fstrict-overflow.
[Bug testsuite/48753] [4.7 Regression] FAIL: gcc.dg/tree-prof/val-prof-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48753 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 13:31:21 UTC --- Author: jakub Date: Tue Apr 26 13:31:17 2011 New Revision: 172966 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172966 Log: PR testsuite/48753 * gcc.dg/tree-prof/val-prof-2.c: Adjust for 32-bit HWI. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-prof/val-prof-2.c
[Bug debug/48768] [4.6/4.7 Regression] ICE in get_expr_operands()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48768 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 13:35:24 UTC --- Author: jakub Date: Tue Apr 26 13:35:21 2011 New Revision: 172968 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172968 Log: PR debug/48768 * tree-ssa.c (insert_debug_temp_for_var_def): If degenerate_phi_result is error_mark_node, set value to NULL. * gcc.dg/pr48768.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr48768.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa.c
[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-26 13:36:50 UTC --- Works with: 2010-09-28-r164677
[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48734 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 13:33:55 UTC --- Author: jakub Date: Tue Apr 26 13:33:49 2011 New Revision: 172967 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172967 Log: PR tree-optimization/48734 * tree-ssa-reassoc.c (eliminate_redundant_comparison): Give up if return value from maybe_fold_*_comparsions isn't something the code is prepared to handle. * gcc.c-torture/compile/pr48734.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr48734.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug testsuite/48753] [4.7 Regression] FAIL: gcc.dg/tree-prof/val-prof-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48753 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 13:40:05 UTC --- Fixed.
[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48734 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 13:44:54 UTC --- Author: jakub Date: Tue Apr 26 13:44:51 2011 New Revision: 172969 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172969 Log: PR tree-optimization/48734 * tree-ssa-reassoc.c (eliminate_redundant_comparison): Give up if return value from maybe_fold_*_comparsions isn't something the code is prepared to handle. * gcc.c-torture/compile/pr48734.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/compile/pr48734.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa-reassoc.c
[Bug debug/48768] [4.6/4.7 Regression] ICE in get_expr_operands()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48768 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 13:48:46 UTC --- Fixed.
[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48734 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 13:48:10 UTC --- Fixed.
[Bug libstdc++/48771] New: [C++0x] is_literal_type incorrect for references to non-literal types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48771
Summary: [C++0x] is_literal_type incorrect for references to
non-literal types
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
gcc 4.7.0 20110423 (experimental) in C++0x mode rejects the following code:
//---
#include type_traits
struct NonLiteral {
NonLiteral();
~NonLiteral();
};
static_assert(std::is_literal_typeNonLiteral::value, Error); // #1
static_assert(std::is_literal_typeNonLiteral::value, Error); // #2
//---
because both assertions fire. This code should be accepted, because as of the
FDIS all reference types are literal types (similar to pointers).
[Bug fortran/48112] [4.6/4.7 Regression] generic interface to external function in module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48112 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-26 13:50:53 UTC --- (In reply to comment #4) The crucial part of the patch is: + /* Avoid double resolution of function result symbols. */ + if ((sym-result || sym-attr.result) (sym-ns != gfc_current_ns)) +return; If one backs out that part, one gets the diagnostic messages twice for class_20.f03 - which was a general issue, unrelated to BT_CLASS. * * * A variant combining both issues (this PR and class_20.f03) is: module module_m type t end type t interface test function test1( ) result( test ) import class(t) :: test end function test1 end interface test end module module_m For that program, only one error should be printed - and no ICE in module writing ... * * * Draft patch; note that resolve_fl_var_and_proc is *only* about diagnostics: --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -9888,0 +9889,5 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag) + /* Avoid double diagnostics of function result symbols. */ + if ((sym-result || sym-attr.result) !sym-attr.dummy + (sym-ns != gfc_current_ns)) +return SUCCESS; + @@ -11977,5 +11981,0 @@ resolve_symbol (gfc_symbol *sym) - /* Avoid double resolution of function result symbols. */ - if ((sym-result || sym-attr.result) !sym-attr.dummy - (sym-ns != gfc_current_ns)) -return;
[Bug debug/48768] [4.6/4.7 Regression] ICE in get_expr_operands()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48768 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 13:47:17 UTC --- Author: jakub Date: Tue Apr 26 13:47:13 2011 New Revision: 172970 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172970 Log: PR debug/48768 * tree-ssa.c (insert_debug_temp_for_var_def): If degenerate_phi_result is error_mark_node, set value to NULL. * gcc.dg/pr48768.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48768.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa.c
[Bug fortran/45586] [4.6/4.7 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #54 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-26 14:07:03 UTC --- (In reply to comment #53) reduced testcase for 4.7 Does not fail here - can you still reproduce it? (It might have been fixed by the patch for PR 48588. If it still occurs, I will try harder.)
[Bug c++/48771] [C++0x] is_literal_type incorrect for references to non-literal types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48771 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.26 14:10:31 CC||jason at gcc dot gnu.org Component|libstdc++ |c++ Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-26 14:10:31 UTC --- This is really a C++ front-end issue, not a library issue, because it just boils down to __is_literal_type and in turn to the internal literal_type_p, which apparently should be updated to reflect the FDIS concept.
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #14 from Gabriel Dos Reis gdr at gcc dot gnu.org 2011-04-26
14:12:35 UTC ---
(In reply to comment #12)
(In reply to comment #9)
I guess, in the 4.6.1 time frame we can only workaround the issue in C++03
mode
by doing the piecewise work in the body. I can maybe help for the compiler
work
too but I need more guidance: is there an agreement about the C1X inspired
builtin suggested by Joseph? In case, can I have a more specific reference?
I'm adding in CC Richi too, in case he has additional tips and/or hints
about
the builtin work..
A __builtin_complex builtin should be almost trivial. It would be purely
frontend sugar for frontends that lack a way to specify a complex value
component-wise. The frontend would be resposible for lowering it to
a COMPLEX_EXPR. I don't think the middle-end wants to deal with
__builtin_complex as it already has a perfect matching tree code.
Agreed -- except since __builtin_complex is already a perfect match,
the front-end should just accept either
_M_value{r,i}
or
_M_value(r,i)
if it wanted to be C++03 compatible too. Either way, you say, there
is no need to involve the middle end.
Now I understand C++0x might have a proper syntax already, so I'm not sure
how it relates to this (C++) bug.
What changed in 4.6 is that we put complex values in registers even at -O0.
that is fine (and appreciated!). It is unrelated to the bug though.
You should be able to reproduce any issue in this bug in older releases
with optimization turned on (given that the library implementation didn't
change).
The bug is a source-level bug; the source code is written that way because
we don't have yet a good way to initialize at once GCC builtin COMPLEX_EXPR.
-- Gaby
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #15 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-04-26 14:30:50 UTC --- On Mon, 25 Apr 2011, john at johnmaddock dot co.uk wrote: Sorry to be dumb, but doesn't the result of the C code violate section G.5.2 in C99 - which is to say that no matter what the value of the imaginary part of an expression, it never changes the real part - even if that is a NaN? I can't make any sense of that sentence - what is the it you are saying is changing a real part but shouldn't be? In NaN * 1.0fi, the first operand is real and the second is complex (*not* imaginary, GCC doesn't have imaginary types), so the real part of the result is NaN*0 which is NaN and the imaginary part is NaN*1 which is also NaN. Adding 0 then results in a real part of 0+NaN, which is NaN, and an imaginary part of NaN. This is in accordance with how mixed real/complex arithmetic works in C99 - implemented for C in 4.5 and I think for C++ in 4.6 (with associated removal of bogus optimizations that tried to treat values of complex type as being real or imaginary values if one part was zero). The built-in function semantics would be those of CMPLXF, CMPLX and CMPLXL in 7.3.9.3 in the C1X DIS (N1569).
[Bug c++/48771] [C++0x] is_literal_type incorrect for references to non-literal types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48771
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
||com
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-26
14:39:36 UTC ---
The below patchlet fixes the problem and passes the testsuite.
Jason, let me know if you consider it safe, for 4_6-branch too, in case.
Paolo.
//
Index: testsuite/g++.dg/ext/is_literal_type1.C
===
--- testsuite/g++.dg/ext/is_literal_type1.C(revision 0)
+++ testsuite/g++.dg/ext/is_literal_type1.C(revision 0)
@@ -0,0 +1,11 @@
+// PR c++/48771
+// { dg-do compile }
+// { dg-options -std=c++0x }
+
+struct NonLiteral {
+ NonLiteral();
+ ~NonLiteral();
+};
+
+static_assert(__is_literal_type(NonLiteral), Error);
+static_assert(__is_literal_type(NonLiteral), Error);
Index: cp/semantics.c
===
--- cp/semantics.c(revision 172961)
+++ cp/semantics.c(working copy)
@@ -5331,7 +5331,8 @@ float_const_decimal64_p (void)
bool
literal_type_p (tree t)
{
- if (SCALAR_TYPE_P (t))
+ if (SCALAR_TYPE_P (t)
+ || TREE_CODE (t) == REFERENCE_TYPE)
return true;
if (CLASS_TYPE_P (t))
return CLASSTYPE_LITERAL_P (t);
[Bug tree-optimization/48772] New: [4.7 Regression] ICE: SIGSEGV in walk_non_aliased_vuses (gimple.h:1100) with -O -fnon-call-exceptions -fno-tree-ccp -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48772 Summary: [4.7 Regression] ICE: SIGSEGV in walk_non_aliased_vuses (gimple.h:1100) with -O -fnon-call-exceptions -fno-tree-ccp -fno-tree-dce Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 24103 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24103 reduced testcase (from g++.dg/torture/pr44535.C) Compiler output: $ gcc -O -fnon-call-exceptions -fno-tree-ccp -fno-tree-dce testcase.C ==25341== Invalid read of size 1 ==25341==at 0xB0BE03: walk_non_aliased_vuses (gimple.h:1100) ==25341==by 0xB80E8C: vn_reference_lookup (tree-ssa-sccvn.c:1697) ==25341==by 0xB6DD99: eliminate (tree-ssa-pre.c:4341) ==25341==by 0xB7103D: execute_pre (tree-ssa-pre.c:4921) ==25341==by 0x984C55: execute_one_pass (passes.c:1555) ==25341==by 0x984F34: execute_pass_list (passes.c:1610) ==25341==by 0x984F46: execute_pass_list (passes.c:1611) ==25341==by 0xACCBAA: tree_rest_of_compilation (tree-optimize.c:423) ==25341==by 0xCAFB42: cgraph_expand_function (cgraphunit.c:1576) ==25341==by 0xCB205B: cgraph_optimize (cgraphunit.c:1635) ==25341==by 0xCB25E9: cgraph_finalize_compilation_unit (cgraphunit.c:1096) ==25341==by 0x5BD42D: cp_write_global_declarations (decl2.c:4002) ==25341==by 0xA71A87: toplev_main (toplev.c:591) ==25341==by 0x644AB6C: (below main) (in /lib64/libc-2.11.3.so) ==25341== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==25341== testcase.C: In function 'int main()': testcase.C:26:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48742
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-26 14:50:47 UTC ---
There shouldn't be nested C_MAYBE_CONST_EXPR. The code you quote
if (!in_late_binary_op)
{
if (!op0_maybe_const || TREE_CODE (op0) != INTEGER_CST)
op0 = c_wrap_maybe_const (op0, !op0_maybe_const);
if (!op1_maybe_const || TREE_CODE (op1) != INTEGER_CST)
op1 = c_wrap_maybe_const (op1, !op1_maybe_const);
}
is to avoid the result of folding getting folded again and to track how
constant that result is. But if int_operands I don't think this wrapping
of the operands is needed because the code after return_build_binary_op:
will deal with wrapping the result.
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-26 14:54:12 UTC --- Thanks Joseph for the explanation and the references. Now maybe I'm digressing in terms of the C++ issue we are facing, but I'm wondering: at some point, even for C99, shouldn't we support imaginary types?
[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48770 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2011-04-26 14:57:08 UTC --- (gdb) disassemble ... 0x00400d06 +18:addq $0x1,(%rax) 0x00400d0a +22:mov$0x8,%eax 0x00400d0f +27:test %edi,%edi 0x00400d11 +29:jne0x400d51 test_goto2(int)+93 ... 0x00400d50 +92:retq = 0x00400d51 +93:mov(%rax),%rcx 0x00400d54 +96:add$0x1,%rcx 0x00400d58 +100: mov0x202461(%rip),%rdx# 0x6031c0 0x00400d5f +107: mov$0x1,%eax 0x00400d64 +112: jmp0x400d15 test_goto2(int)+33 In the asm output, the problem is apparent (comparing trunk and 4.6 output) - the only difference is: 73,75c73,76 mov rcx, QWORD PTR [rax]# *.LPBX1_I_lsm.7, *.LPBX1 add rcx, 1 # *.LPBX1_I_lsm.7, mov rdx, QWORD PTR .LPBX1[rip+32] # *.LPBX1_I_lsm.6, *.LPBX1 --- lea rax, .LPBX1[rip+24] # tmp113, mov rcx, QWORD PTR [rax]# *.LPBX1, *.LPBX1 add rcx, 1 # *.LPBX1_I_lsm.4, mov rdx, QWORD PTR .LPBX1[rip+32] # *.LPBX1_I_lsm.3, *.LPBX1 Instruction lea is missing, and rax contains value 8.
[Bug rtl-optimization/48773] New: Dataflow and REG_DEAD notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48773 Summary: Dataflow and REG_DEAD notes Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: mfort...@gmail.com Hello all, I have recently been updating an out of tree target from GCC 4.2.4 to GCC 4.3.5 and have noticed that REG_DEAD notes can get out of sync at the end of multiple passes. (i.e. be attached to instructions where the register does not die) The first pass that appears to get REG_DEAD notes out of sync is GCSE. This gets fixed and broken multiple times as some of the later passes solve the DF note problem via df_analyze, some delete all notes and some get the notes out of sync again. When the second schedule pass (sched2) runs the DF note problem is solved at the start but then instructions can be re-ordered and notes are once again left out of sync. In my case this causes (an admittedly old) peephole to be applied incorrectly and bad code is generated. It seems to be that each pass, which may get notes out of sync, should run the note problem before finishing. With some experimentation I have seen that running df_analyze to solve the note problem at the end of some passes leads to an apparent improvement in the code. It would therefore seem that some passes use REG_DEAD information without first solving the REG_DEAD problem. This sounds reasonable as I would expect each pass to end leaving notes valid. Is the behaviour I have described here intentional? If so, could someone explain the rationale? I can't see any changes in this area (up to trunk) and I have seen REG_DEAD notes get out of sync with at least one in-tree target for which I could provide a testcase if that is useful (GCC 4.5.1). This issue is quite general though so I believe a large amount of code should trigger the notes to get out of sync. This clearly does not lead to actual bugs in most cases otherwise it would have already been reported. regards, Matthew
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #17 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-04-26 15:03:49 UTC --- As far as I can see, the main (only?) use of imaginary types is for this issue of constructing complex values. In addition, you need to define for each target the ABI for argument passing and return of imaginary types (and in particular how _Imaginary float is passed in variable arguments - it is *not* promoted to _Imaginary double, whereas float is promoted to double in variable arguments at the C language level before the ABI comes into play, so whereas targets don't need to allow for unpromoted float in variable arguments they do need to allow for unpromoted _Imaginary float). But, given that, it would indeed be nice to support imaginary types.
[Bug tree-optimization/48772] [4.7 Regression] ICE: SIGSEGV in walk_non_aliased_vuses (gimple.h:1100) with -O -fnon-call-exceptions -fno-tree-ccp -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48772 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.26 15:09:22 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 15:09:22 UTC --- Mine. We are destroying the virtual operand web as it was present during value-numbering by updating stmts during elimination. In this case by updating a call stmt that was promoted from an indirect virtual call to a direct call.
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 Jiangning Liu jiangning.liu at arm dot com changed: What|Removed |Added CC||jiangning.liu at arm dot ||com --- Comment #35 from Jiangning Liu jiangning.liu at arm dot com 2011-04-26 15:13:41 UTC --- I verified that two patches in #38644 (back end) and #30282 (middle end) both work for attached cases. Here comes my two cents, 1) The concept of red zone is to control whether instructions can write memory below current stack frame or not, and it is only being supported by ABIs for some particular ISAs, so it shouldn't be enabled in middle end by default for all targets. At this point, middle end should be fixed to avoid doing things unwanted in general for all targets. 2) Red zone is an orthogonal concept to prologue/epilogue, so it is not good to fix this issue in prologue/epilogue back end code. At this point, we shouldn't simply fix it in back end by adding barrier to implicitly disable red zone. Instead, some hooks should be abstracted in middle end to support it in scheduling dependence (middle end code). Back end like X86-64 should enable it through hooks by itself. The key here is red zone should be a clean feature to be supported in middle end. Exposing this kind of stuff to back end through hooks can improve code quality for middle end and avoid bringing the bugs to back-end. This bug has long history, and it is being now or has ever been exposed on ARM, POWER and X86(with some options combination). Fixing it in middle end is not only a bug fix, but a simple infrastructure improvement. Due to the long duration and the extensive impact for different targets, I don't see good reason of not fixing it in mainline ASAP.
[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in glimplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48742 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-26 15:16:05 UTC --- Created attachment 24104 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24104 gcc46-pr48742.patch So do you mean something like this? Haven't bootstrapped/regtested it yet...
[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48750 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-26 15:19:12 UTC --- Seth, Tom, if you get a chance to test the changes I propose in Comment 7 (suitably, trivially tweaked for 4.4.x), please let me know as soon as possible. If Johannes cannot provide feedback on this issue over the next few days I mean to go ahead with my patch, likely for 4.6.x too, and work on a other similar tweaks in the same spirit elsewhere in the parallel code (luckily we have only an handful of operator new / operator delete pairs needing attention).
[Bug c/48742] [4.5/4.6/4.7 Regression] Internal error in gimplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48742 --- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-04-26 15:24:13 UTC --- On Tue, 26 Apr 2011, jakub at gcc dot gnu.org wrote: Created attachment 24104 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24104 gcc46-pr48742.patch So do you mean something like this? Haven't bootstrapped/regtested it yet... Yes, that patch looks right.
[Bug rtl-optimization/48774] New: gcc-4.6.0 optimization regression on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48774
Summary: gcc-4.6.0 optimization regression on
x86_64-unknown-linux-gnu
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mariah.le...@gmail.com
/* gcc-4.6.0 optimization regression on x86_64-unknown-linux-gnu:
% gcc -O1 -funroll-loops -o foo foo.c
foo
order= 11
%
% gcc -O2 -funroll-loops -o foo foo.c
foo # hangs
make: *** [bad] Interrupt
%
% gcc-4.5.1 -O2 -funroll-loops -o foo foo.c
foo
order=11
%
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.0/x86_64-Linux-core2-fc/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /usr/local/gcc-4.6.0/src/gcc-4.6.0/configure
--enable-languages=c,c++,fortran --with-gnu-as
--with-gnu-as=/usr/local/binutils-2.21/x86_64-Linux-core2-fc-gcc-4.5.1-rh/bin/as
--with-gnu-ld
--with-ld=/usr/local/binutils-2.21/x86_64-Linux-core2-fc-gcc-4.5.1-rh/bin/ld
--with-gmp=/usr/local/mpir-2.3.0/x86_64-Linux-core2-fc-gcc-4.5.1-rh
--with-mpfr=/usr/local/mpfr-3.0.0/x86_64-Linux-core2-fc-mpir-2.3.0-gcc-4.5.1-rh
--with-mpc=/usr/local/mpc-0.9/x86_64-Linux-core2-fc-mpir-2.3.0-mpfr-3.0.0-gcc-4.5.1-rh
--prefix=/usr/local/gcc-4.6.0/x86_64-Linux-core2-fc
Thread model: posix
gcc version 4.6.0 (GCC)
%
Apologies that this code is so long, but I can not find any way
to shorten it further and still demonstrate the bug.
*/
#include stdio.h
#include stdlib.h
#include string.h
#define SIZE 12
unsigned long int ss[SIZE][2];
#define SET_BIT_MASK(x) ((unsigned long)1(x))
#define SET_ELEMENT_CONTAINS(e,v) ((e)SET_BIT_MASK(v))
#define SET_CONTAINS_FAST(s,a) (SET_ELEMENT_CONTAINS((s)[0], (a)))
#define SET_CONTAINS(s,a) (((a)SET_MAX_SIZE(s))?SET_CONTAINS_FAST(s,a):0)
#define SET_MAX_SIZE(s) ((s)[-1])
typedef struct graph graph_t;
struct graph {
int n;
unsigned long *edges[SIZE];
} gg;
#define GRAPH_IS_EDGE(g,i,j) \
(((j)(((g)-edges[(0)]))[-1])?SET_CONTAINS_FAST((g)-edges[(i)],j):0)
/*
SET_CONTAINS((g)-edges[(i)], (j))
*/
int bar(graph_t *g) {
int i,j,v;
int tmp_used[SIZE];
int degree[SIZE];
int order[SIZE];
int maxdegree,maxvertex=0;
int samecolor;
for (i = 0; i SIZE; i++) {
order[i] = 0;
degree[i] = 0;
}
for (i=0; i g-n; i++) {
for (j=0; j g-n; j++) {
if ((i==j) GRAPH_IS_EDGE(g,i,j)) {
exit(0);;
}
if (GRAPH_IS_EDGE(g,i,j)) degree[i]++;
}
}
v=0;
while (v SIZE) {
memset(tmp_used,0,SIZE * sizeof(int));
do {
maxdegree=0;
samecolor=0;
for (i=0; i SIZE; i++) {
if (!tmp_used[i] degree[i] = maxdegree) {
maxvertex=i;
maxdegree=degree[i];
samecolor=1;
}
}
if (samecolor) {
order[v]=maxvertex;
degree[maxvertex]=-1;
v++;
for (i=0; i SIZE; i++) {
if (GRAPH_IS_EDGE(g,maxvertex,i)) {
tmp_used[i]=1;
degree[i]--;
}
}
}
} while (samecolor);
}
return order[0];
}
graph_t *make_graph() {
graph_t *g;
int i;
for (i=0; i SIZE; i++) {
ss[i][0] = SIZE;
}
ss[0][1] = 2114;
ss[1][1] = 37;
ss[2][1] = 1034;
ss[3][1] = 532;
ss[4][1] = 296;
ss[5][1] = 82;
ss[6][1] = 161;
ss[7][1] = 2368;
ss[8][1] = 656;
ss[9][1] = 1288;
ss[10][1] = 2564;
ss[11][1] = 1153;
g = gg;
g-n=SIZE;
for (i=0; i SIZE; i++) {
g-edges[i]=(ss[i][1]);
}
return g;
}
int main(int argc, char **argv) {
graph_t *g;
int order;
g = make_graph();
order = bar(g);
printf(order= %d\n, order);
return 0;
}
[Bug target/48754] FAIL: gcc.dg/binop-xor(1|3).c scan-tree-dump-times optimized bb[^]* *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48754 --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-04-26 16:25:49 UTC --- Created attachment 24105 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24105 -fdump-tree-optimized for mips-sgi-irix6.5, N32 ABI
[Bug target/48754] FAIL: gcc.dg/binop-xor(1|3).c scan-tree-dump-times optimized bb[^]* *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48754 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|powerpc*-*-*|powerpc*-*-*, mips*-*-* CC||ro at gcc dot gnu.org --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2011-04-26 16:24:41 UTC --- All five tests also fail on IRIX 6.5, both N32 and N64 ABIs: FAIL: gcc.dg/binop-xor1.c scan-tree-dump-times optimized bb[^]* 5 FAIL: gcc.dg/binop-xor1.c scan-tree-dump-times optimized \\^ 1 FAIL: gcc.dg/binop-xor2.c scan-tree-dump-times optimized \\^ 1 FAIL: gcc.dg/binop-xor3.c scan-tree-dump-times optimized bb[^]* 1 FAIL: gcc.dg/binop-xor3.c scan-tree-dump-times optimized \\^ 1 FAIL: gcc.dg/binop-xor4.c scan-tree-dump-times optimized \\^ 1 FAIL: gcc.dg/binop-xor5.c scan-tree-dump-times optimized \\^ 1 FAIL: gcc.dg/binop-xor5.c scan-tree-dump-times optimized 1 I'm attaching the corresponding dumps.
[Bug middle-end/48663] [4.7 regression] final.c:dump_basic_block_info breaks several Tru64 UNIX tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48663 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-04-26 16:29:40 UTC --- Indeed, the error is gone as of r172821.
[Bug tree-optimization/48775] New: gcc.dg/pr48616.c FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48775 Summary: gcc.dg/pr48616.c FAILs on Tru64 UNIX Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ja...@gcc.gnu.org Host: alpha-dec-osf5.1b Target: alpha-dec-osf5.1b Build: alpha-dec-osf5.1b The new gcc.dg/pr48616.c tests fails on Tru64 UNIX: FAIL: gcc.dg/pr48616.c (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr48616.c:10:5: warning: requested alignment for 'e' is greater than implemented alignment of 16 [enabled by default] /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr48616.c:9:5: warning: requested alignment for 'd' is greater than implemented alignment of 16 [enabled by default] /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr48616.c:8:5: warning: requested alignment for 'c' is greater than implemented alignment of 16 [enabled by default] /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr48616.c:7:5: warning: requested alignment for 'b' is greater than implemented alignment of 16 [enabled by default] /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr48616.c:6:5: warning: requested alignment for 'a' is greater than implemented alignment of 16 [enabled by default]
[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-26 17:06:03 UTC --- Works: 2010-10-15-r165507 (a5b23678e24cec2da289a54ae62f98f7b1301c36) Fails: 2010-10-23-r165882 (2dfbcd30bb4e761a9c5144a0656b8dfc6336ed37)
[Bug target/48604] [4.5/4.6/4.7 regression] wrong code with -frename-registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48604 Edmar Wienskoski edmar at freescale dot com changed: What|Removed |Added CC||edmar at freescale dot com --- Comment #4 from Edmar Wienskoski edmar at freescale dot com 2011-04-26 17:31:38 UTC --- You may want to take a look at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
[Bug fortran/48438] Several gfortran tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48438
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-04-26 17:36:51 UTC ---
- large_real_kind_2.F90
Fails for CTEST_POWER(0.0, 5.4), which is:
abs(0.0**5.4 - 0.0**5.4)/(0.0**5.4) eps
where x is complex(kind=16) (selected_real_kind (precision (0.0_8) + 1))
and 8 is complex(8).
The numeric expression gives 0.0/0.0 = NaN - and NaN eps gives
here FALSE - but on Tru64 seemingly SIGABRT?
No, the SIGFPE already happens in the cpow (0.0, 0.0, 5.4, 0.0) call.
If I compile with -mieee instead, I get SIGFPE for
75 CTEST_POWER (0.0,1.0)
complex(3) states:
cpow(), cpowf() sqrt(a**2 + b**2)overflow
max_float
cpow(), cpowf() c/2 * ln(a**2 + b**2)overflow
max_float
cpow(), cpowf() c/2 * ln(a**2 + b**2) - overflow
(d * atan2(b,c))
max_float
__
Value Name Data Type Hexadecimal Value Decimal Value
__
max_floatF_FLOAT 7FFF1.701411e38
G_FLOAT 7 8.988465674311579e307
S_FLOAT 7F7F3.402823e38
T_FLOAT 7FEF
F_FLOAT and G_FLOAT is the VAX single resp. double format, while S_FLOAT
and T_FLOAT are IEEE single and double.
Rainer
[Bug target/48258] Add VSX support for float/double vector reductions improve float insert/extract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48258 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org 2011-04-26 17:48:34 UTC --- Author: meissner Date: Tue Apr 26 17:48:29 2011 New Revision: 172981 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172981 Log: PR target/48258, improve vector reduction on power7 Added: trunk/gcc/testsuite/gcc.target/powerpc/pr48258-1.c trunk/gcc/testsuite/gcc.target/powerpc/pr48258-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/vector.md trunk/gcc/config/rs6000/vsx.md trunk/gcc/testsuite/ChangeLog
