[Bug fortran/43539] internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:995
--- Comment #2 from pault at gcc dot gnu dot org 2010-03-27 07:55 --- This is a bit odd. SIZEOF seems to be properly registered in intrinsic.c: add_sym_1 (sizeof, GFC_ISYM_SIZEOF, NO_CLASS, ACTUAL_NO, BT_INTEGER, ii, GFC_STD_GNU, gfc_check_sizeof, NULL, NULL, x, BT_UNKNOWN, 0, REQUIRED); make_generic (sizeof, GFC_ISYM_SIZEOF, GFC_STD_GNU); make_alias (c_sizeof, GFC_STD_F2008); Could somebody that is a bit more familiar with the handling of intrinsics take a look at this, please? Confirmed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-27 07:55:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43539
[Bug tree-optimization/43544] TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION can misoptimize when MD builtins overlap with standard builtins
--- Comment #3 from meissner at gcc dot gnu dot org 2010-03-27 10:27 --- Subject: Bug 43544 Author: meissner Date: Sat Mar 27 10:27:39 2010 New Revision: 157770 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157770 Log: PR 43544, change TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION to take a tree argument Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/rs6000/rs6000.c trunk/gcc/doc/tm.texi trunk/gcc/target.h trunk/gcc/targhooks.c trunk/gcc/targhooks.h trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43544
[Bug c/43381] [4.4 Regression] infinite loop in gcc.dg/parm-impl-decl-1.c with -g
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-27 10:41 --- Fixed on trunk sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.3 Known to work|4.3.4 |4.3.4 4.5.0 Summary|[4.4/4.5 Regression]|[4.4 Regression] infinite |infinite loop in|loop in gcc.dg/parm-impl- |gcc.dg/parm-impl-decl-1.c |decl-1.c with -g |with -g | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43381
[Bug middle-end/43548] internal compiler error: in ggc_set_mark, at ggc-page.c:1338
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-27 10:44 --- Created an attachment (id=20223) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20223action=view) preprocessed source Downloaded and attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43548
[Bug tree-optimization/43247] [4.3/4.4 Regression] Incorrect optimization while declaring array[1]
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-27 10:45 --- I very much doubt that the cited revision fixed anything here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
[Bug middle-end/43391] [4.5 Regression] make_decl_rtl failure for C++ on AIX and HPUX
--- Comment #5 from hubicka at ucw dot cz 2010-03-27 10:53 --- Subject: Re: [4.5 Regression] make_decl_rtl failure for C++ on AIX and HPUX Honza - ping. There is proposed patch sent to ML http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00789.html I've missed that Steve Ellcey already tested it. Does it seem OK then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43391
[Bug debug/43501] [4.4/4.5 Regression] ICE: Segmentation fault with -g due to too deep recursion
--- Comment #4 from zsojka at seznam dot cz 2010-03-27 10:57 --- Indeed, r157766 no longer crashes *** This bug has been marked as a duplicate of 43381 *** -- zsojka at seznam dot cz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43501
[Bug c/43381] [4.4 Regression] infinite loop in gcc.dg/parm-impl-decl-1.c with -g
--- Comment #7 from zsojka at seznam dot cz 2010-03-27 10:57 --- *** Bug 43501 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43381
[Bug tree-optimization/26854] [4.3/4.4/4.5 Regression] Inordinate compile times on large routines
--- Comment #116 from rguenth at gcc dot gnu dot org 2010-03-27 11:14 --- Given that parsing takes most of the time the compile-time indeed looks reasonable. That DF uses 20GB of ram at -O3 is still unfortunate, but the -O1 numbers look indeed good. I wonder if the parsing numbers are accurate as the initial report has like 9s parsing while the current ones are 200s. Can you explain that difference? (like, were you testing different source?) As is the testcase(s) are an interesting source of information - maybe we should gather those up on a page in the wiki just in case we end up closing this bug at some point (I suggest not to at the moment, the parsing times look odd and 20GB memory use doesn't sound reasonable). Did you ever test other compilers and see how they perform with respect to memory usage and compile time? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug c/43381] [4.4 Regression] infinite loop in gcc.dg/parm-impl-decl-1.c with -g
--- Comment #8 from jsm28 at gcc dot gnu dot org 2010-03-27 11:46 --- Subject: Bug 43381 Author: jsm28 Date: Sat Mar 27 11:46:07 2010 New Revision: 157772 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157772 Log: PR c/43381 * c-decl.c (get_parm_info): Assert that decl going in OTHERS has a nested binding iff it is a FUNCTION_DECL. (store_parm_decls_newstyle): Pass nested=true to bind for FUNCTION_DECLs amongst parameters. testsuite: * gcc.dg/parm-impl-decl-3.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/parm-impl-decl-3.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/c-decl.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43381
[Bug c/43381] [4.4 Regression] infinite loop in gcc.dg/parm-impl-decl-1.c with -g
--- Comment #9 from jsm28 at gcc dot gnu dot org 2010-03-27 11:47 --- Fixed for 4.4.4 and 4.5.0. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work|4.3.4 4.5.0 |4.3.4 4.4.4 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43381
[Bug middle-end/43391] [4.5 Regression] make_decl_rtl failure for C++ on AIX and HPUX
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-03-27 11:56 --- Subject: Bug 43391 Author: hubicka Date: Sat Mar 27 11:56:30 2010 New Revision: 157773 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157773 Log: PR middle-end/43391 * varasm.c (make_decl_rtl): Deal with COMMON flag to make notice_global_symbol work. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43391
[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime
--- Comment #11 from developer at sandoe-acoustics dot co dot uk 2010-03-27 11:59 --- It seems that objc_start_function is expecting a TREE in the objcpp case - so the error marked node is indeed unexpected. I've tried this on i686-darwin and i32-linux - but there are obviously a lot of affected platforms out there - would some of you like to try this? Index: gcc/objc/objc-act.c === --- gcc/objc/objc-act.c (revision 157761) +++ gcc/objc/objc-act.c (working copy) @@ -2391,11 +2398,17 @@ objc_push_parm (build_decl (input_location, PARM_DECL, NULL_TREE, void_type_node)); +#ifdef OBJCPLUS objc_start_function (get_identifier (TAG_GNUINIT), build_function_type (void_type_node, OBJC_VOID_AT_END), + NULL_TREE, NULL_TREE); +#else + objc_start_function (get_identifier (TAG_GNUINIT), + build_function_type (void_type_node, + OBJC_VOID_AT_END), NULL_TREE, objc_get_parm_info (0)); - +#endif body = c_begin_compound_stmt (true); add_stmt (build_function_call (input_location, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23716
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #15 from uros at gcc dot gnu dot org 2010-03-27 12:09 --- Subject: Bug 42113 Author: uros Date: Sat Mar 27 12:09:24 2010 New Revision: 157774 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157774 Log: PR target/42113 * config/alpha/alpha.md (*cmp_sadd_si): Change mode of scratch register to DImode. Split to DImode comparison operator. Use SImode subreg of scratch register in the multiplication. (*cmp_sadd_sidi): Ditto. (*cmp_ssub_si): Ditto. (*cmp_ssub_sidi): Ditto. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/alpha/alpha.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #16 from uros at gcc dot gnu dot org 2010-03-27 12:16 --- Subject: Bug 42113 Author: uros Date: Sat Mar 27 12:15:50 2010 New Revision: 157775 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157775 Log: PR target/42113 * config/alpha/alpha.md (*cmp_sadd_si): Change mode of scratch register to DImode. Split to DImode comparison operator. Use SImode subreg of scratch register in the multiplication. (*cmp_sadd_sidi): Ditto. (*cmp_ssub_si): Ditto. (*cmp_ssub_sidi): Ditto. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/alpha/alpha.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #17 from ubizjak at gmail dot com 2010-03-27 12:17 --- Fixed in a better way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug middle-end/43391] [4.5 Regression] make_decl_rtl failure for C++ on AIX and HPUX
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-27 12:45 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43391
[Bug tree-optimization/43528] ICE: in tree_low_cst, at tree.c:6198 with -mms-bitfields at x86_64-linux
--- Comment #9 from ubizjak at gmail dot com 2010-03-27 12:52 ---
This patch also works:
Index: stor-layout.c
===
--- stor-layout.c (revision 157756)
+++ stor-layout.c (working copy)
@@ -1346,11 +1346,12 @@ place_field (record_layout_info rli, tre
until we see a bitfield (and come by here again) we just skip
calculating it. */
if (DECL_SIZE (field) != NULL
- host_integerp (TYPE_SIZE (TREE_TYPE (field)), 0)
- host_integerp (DECL_SIZE (field), 0))
+ host_integerp (TYPE_SIZE (TREE_TYPE (field)), 1)
+ host_integerp (DECL_SIZE (field), 1))
{
- HOST_WIDE_INT bitsize = tree_low_cst (DECL_SIZE (field), 1);
- HOST_WIDE_INT typesize
+ unsigned HOST_WIDE_INT bitsize
+ = tree_low_cst (DECL_SIZE (field), 1);
+ unsigned HOST_WIDE_INT typesize
= tree_low_cst (TYPE_SIZE (TREE_TYPE (field)), 1);
if (typesize bitsize)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43528
[Bug target/43546] [4.4/4.5 Regression] ICE: in assign_stack_local_1, at function.c:353 with -mpreferred-stack-boundary=2 -msseregparm
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-27 12:53 --- No, sseregparm should be perfectly fine with x87 math - it only needs (obviously) SSE registers available. It's an ABI switch like regparm, whether math is done using SSE registers or x87 math doesn't and shouldn't matter. The workaround looks odd - it can't be the real solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43546
[Bug tree-optimization/43528] ICE: in tree_low_cst, at tree.c:6198 with -mms-bitfields at x86_64-linux
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-27 12:54
---
(In reply to comment #9)
This patch also works:
Index: stor-layout.c
===
--- stor-layout.c (revision 157756)
+++ stor-layout.c (working copy)
@@ -1346,11 +1346,12 @@ place_field (record_layout_info rli, tre
until we see a bitfield (and come by here again) we just skip
calculating it. */
if (DECL_SIZE (field) != NULL
- host_integerp (TYPE_SIZE (TREE_TYPE (field)), 0)
- host_integerp (DECL_SIZE (field), 0))
+ host_integerp (TYPE_SIZE (TREE_TYPE (field)), 1)
+ host_integerp (DECL_SIZE (field), 1))
{
- HOST_WIDE_INT bitsize = tree_low_cst (DECL_SIZE (field), 1);
- HOST_WIDE_INT typesize
+ unsigned HOST_WIDE_INT bitsize
+ = tree_low_cst (DECL_SIZE (field), 1);
+ unsigned HOST_WIDE_INT typesize
= tree_low_cst (TYPE_SIZE (TREE_TYPE (field)), 1);
if (typesize bitsize)
let's go with that variant then. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43528
[Bug objc++/23613] obj-c++.dg/isa-field-1.mm fails with the GNU runtime
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2010-03-27 13:10 --- see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01282.html hopefully, that's a reasonable way to fix. -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added CC||developer at sandoe- ||acoustics dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23613
[Bug tree-optimization/43528] ICE: in tree_low_cst, at tree.c:6198 with -mms-bitfields at x86_64-linux
--- Comment #11 from uros at gcc dot gnu dot org 2010-03-27 13:40 --- Subject: Bug 43528 Author: uros Date: Sat Mar 27 13:40:08 2010 New Revision: 157776 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157776 Log: PR tree-optimization/43528 * stor-layout.c (place_field): Check that constant fits into unsigned HWI when skipping calculation of MS bitfield layout. testsuite/ChangeLog: PR tree-optimization/43528 * gcc.target/i386/pr43528.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr43528.c Modified: trunk/gcc/ChangeLog trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43528
[Bug target/43546] [4.4/4.5 Regression] ICE: in assign_stack_local_1, at function.c:353 with -mpreferred-stack-boundary=2 -msseregparm
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-27 14:11 --- (In reply to comment #4) No, sseregparm should be perfectly fine with x87 math - it only needs (obviously) SSE registers available. It's an ABI switch like regparm, whether math is done using SSE registers or x87 math doesn't and shouldn't matter. Then you need to exam all code paths with -msseregparm to see if TARGET_SSEREGPARM check is needed when TARGET_SSE_MATH is checked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43546
[Bug tree-optimization/43247] [4.3/4.4 Regression] Incorrect optimization while declaring array[1]
--- Comment #8 from hjl dot tools at gmail dot com 2010-03-27 14:24 --- (In reply to comment #7) I very much doubt that the cited revision fixed anything here. If it is true, that only means that the bug is latent on trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
[Bug c++/43549] TR1 type_traits are much worse than C++0x type_traits
--- Comment #2 from pogonyshev at gmx dot net 2010-03-27 14:36 --- I'm sorry, but why? Isn't the compiler the same? What is the point of not providing good type traits if you can? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43549
[Bug objc++/27249] FAIL: obj-c++.dg/encode-8.mm execution test
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2010-03-27 14:38 --- shouldn't this be NeXT-specific - i.e. skipped for -fgnu-runtime, rather than XFAILED? -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added CC||developer at sandoe- ||acoustics dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27249
[Bug target/43546] [4.4/4.5 Regression] ICE: in assign_stack_local_1, at function.c:353 with -mpreferred-stack-boundary=2 -msseregparm
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-27 15:23 --- (In reply to comment #5) (In reply to comment #4) No, sseregparm should be perfectly fine with x87 math - it only needs (obviously) SSE registers available. It's an ABI switch like regparm, whether math is done using SSE registers or x87 math doesn't and shouldn't matter. Then you need to exam all code paths with -msseregparm to see if TARGET_SSEREGPARM check is needed when TARGET_SSE_MATH is checked. I don't follow. TARGET_SSEREGPARM does not mean you'll do SSE math. It merely says that you can expect incoming arguments in SSE registers instead of on stack. For -mpreferred-stack-boundary=2 how is the stack for incoming arguments of double type aligned? Also if we'd ever spill a double to stack with x87 math we'd run into exactly the same assert? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43546
[Bug target/43546] [4.4/4.5 Regression] ICE: in assign_stack_local_1, at function.c:353 with -mpreferred-stack-boundary=2 -msseregparm
--- Comment #7 from hjl dot tools at gmail dot com 2010-03-27 15:37 --- (In reply to comment #6) I don't follow. TARGET_SSEREGPARM does not mean you'll do SSE math. It merely says that you can expect incoming arguments in SSE registers instead of on stack. For -mpreferred-stack-boundary=2 how is the stack for incoming arguments of double type aligned? Also if we'd ever spill a double to stack with x87 math we'd run into exactly the same assert? TARGET_SSEREGPARM may put DF/SF in xmm registers for function parameters, which is very similar to TARGET_SSE_MATH which uses xmm for DF/SF, but more than just function parameters. BTW, -mpreferred-stack-boundary=2 -msse never worked before gcc 4.4. We have a bunch of related bug reports: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33721 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43546
[Bug middle-end/41674] [4.5 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main
--- Comment #12 from danglin at gcc dot gnu dot org 2010-03-27 15:43 --- Subject: Bug 41674 Author: danglin Date: Sat Mar 27 15:43:19 2010 New Revision: 157779 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157779 Log: PR middle-end/41674 * cgraphunit.c (cgraph_build_static_cdtor): If target doesn't have cdtors, set DECL_PRESERVE_P. * ipa.c (cgraph_externally_visible_p): Return true if declaration should be preseved. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/ipa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41674
[Bug middle-end/41674] [4.5 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main
--- Comment #13 from danglin at gcc dot gnu dot org 2010-03-27 15:53 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41674
[Bug tree-optimization/26854] [4.3/4.4/4.5 Regression] Inordinate compile times on large routines
--- Comment #117 from lucier at math dot purdue dot edu 2010-03-27 16:38 --- Subject: Re: [4.3/4.4/4.5 Regression] Inordinate compile times on large routines On Mar 27, 2010, at 7:14 AM, rguenth at gcc dot gnu dot org wrote: I wonder if the parsing numbers are accurate as the initial report has like 9s parsing while the current ones are 200s. Can you explain that difference? (like, were you testing different source?) Yes, different source (compiler.i instead of all.i), different (faster) machine. Perhaps gathering the detailed memory stats affect the parser time. Here are times for the original source file all.i using the same machine and compiler as in the immediately previous report for compiler.i: df liveinitialized regs: 45.00 ( 8%) usr 0.00 ( 0%) sys 45.04 ( 8%) wall 0 kB ( 0%) ggc parser: 19.60 ( 3%) usr 1.22 ( 7%) sys 21.25 ( 4%) wall 70217 kB ( 2%) ggc scheduling: 301.86 (52%) usr 0.00 ( 0%) sys 301.87 (51%) wall8739 kB ( 0%) ggc TOTAL : 579.8817.55 597.653393985 kB Glancing at top, the maximum reported memory usage was 13GB. I'll attach the detailed results for all.i next As is the testcase(s) are an interesting source of information - maybe we should gather those up on a page in the wiki just in case we end up closing this bug at some point (I suggest not to at the moment, the parsing times look odd and 20GB memory use doesn't sound reasonable). Did you ever test other compilers and see how they perform with respect to memory usage and compile time? No, none that were not a gcc derivative. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug target/43546] [4.4/4.5 Regression] ICE: in assign_stack_local_1, at function.c:353 with -mpreferred-stack-boundary=2 -msseregparm
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-27 16:38 ---
Just to clarify, the issue is that
(insn 6 5 7 2 t.i:2 (set (reg:DF 21 xmm0)
(float_extend:DF (mem/u/c/i:SF (symbol_ref/u:SI (*.LC0) [flags 0x2])
[0 S4 A32]))) 99 {*extendsfdf2_i387} (expr_list:REG_EQUAL (const_double:DF
-2147483648 [0x8000] 1.0e+0 [0x0.8p+1])
(nil)))
with
(define_insn *extendsfdf2_i387
[(set (match_operand:DF 0 nonimmediate_operand =f,m)
(float_extend:DF (match_operand:SF 1 nonimmediate_operand fm,f)))]
TARGET_80387
* return output_387_reg_move (insn, operands);
[(set_attr type fmov)
(set_attr mode SF,XF)])
requires a reload for the x87 register to xmm0 move. The
(define_insn *extendsfdf2_sse
[(set (match_operand:DF 0 nonimmediate_operand =x)
(float_extend:DF (match_operand:SF 1 nonimmediate_operand xm)))]
TARGET_SSE2 TARGET_SSE_MATH
%vcvtss2sd\t{%1, %d0|%d0, %1}
[(set_attr type ssecvt)
(set_attr prefix maybe_vex)
(set_attr mode DF)])
alternative is not enabled, both because just -msse is supplied and
SSE math is not enabled. But I fail to see why we can't go through
unaligned memory if the user asks us to - which puts the finger
at the assert that triggers (and maybe reload if it can not properly
deal with less aligned stack slots).
Testcase that doesn't need -msseregparm:
extern void __attribute__((sseregparm)) bar(double);
void foo() { bar(1.0); }
commenting the assert yields odd
foo:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
fld1
fstpl -8(%ebp)
movlps -8(%ebp), %xmm0
callbar
leave
ret
obviously w/o -msse2 there's no movsd, thus the odd code.
And the handed out secondary memory has correct alignment:
insn 6 5 11 2 t.i:2 (set (reg:DF 8 st)
(float_extend:DF (mem/u/c/i:SF (symbol_ref/u:SI (*.LC0) [flags 0x2])
[0 S4 A32]))) 99 {*extendsfdf2_i387} (expr_list:REG_EQUAL (const_double:DF
-2147483648 [0x8000] 1.0e+0 [0x0.8p+1])
(nil)))
(insn 11 6 12 2 t.i:2 (set (mem/c:DF (plus:SI (reg/f:SI 6 bp)
(const_int -8 [0xfff8])) [0 S8 A32])
(reg:DF 8 st)) 74 {*movdf_nointeger} (nil))
(insn 12 11 7 2 t.i:2 (set (reg:DF 21 xmm0)
(mem/c:DF (plus:SI (reg/f:SI 6 bp)
(const_int -8 [0xfff8])) [0 S8 A32])) 74 {*movdf_nointeger}
(nil))
(call_insn 7 12 10 2 t.i:2 (call (mem:QI (symbol_ref:SI (bar) [flags 0x41]
function_decl 0xb77a4c80 bar) [0 S1 A8])
(const_int 0 [0x0])) 484 {*call_0} (nil)
(expr_list:REG_DEP_TRUE (use (reg:DF 21 xmm0))
(nil)))
so why are we using assign_stack_local here and not assign_stack_local_1 (...,
true)? Here, at
#3 0x0846d729 in get_secondary_mem (x=0xb77a96f0, mode=DFmode, opnum=0,
type=RELOAD_FOR_OUTPUT) at /home/richard/src/trunk/gcc/reload.c:608
608 = assign_stack_local (mode, GET_MODE_SIZE (mode), 0);
(gdb) l
603 {
604 #ifdef SECONDARY_MEMORY_NEEDED_RTX
605 secondary_memlocs[(int) mode] = SECONDARY_MEMORY_NEEDED_RTX
(mode);
606 #else
607 secondary_memlocs[(int) mode]
608 = assign_stack_local (mode, GET_MODE_SIZE (mode), 0);
609 #endif
610 }
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43546
[Bug target/43546] [4.4/4.5 Regression] ICE: in assign_stack_local_1, at function.c:353 with -mpreferred-stack-boundary=2 -msseregparm
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-27 16:39 --- In fact reduce_alignment_ok is _only_ used in the assert. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43546
[Bug tree-optimization/26854] [4.3/4.4/4.5 Regression] Inordinate compile times on large routines
--- Comment #118 from lucier at math dot purdue dot edu 2010-03-27 16:44 --- Created an attachment (id=20224) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20224action=view) time/memory report compiling all.i with -O3 These are the detailed time and memory statistics reported when compiling all.i with -O3 -fschedule-insns on x86-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug libfortran/43532] Segfault using shape intrinsic function with deferred-shape array
--- Comment #1 from pault at gcc dot gnu dot org 2010-03-27 17:59 --- With the function calls interchanged, the problem goes away. ie. with: write (*,*) shape(this%myarray) /= shape(array) ! SEGFAULT I can't see from the code yet why this is happening but can confirm the bug. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-27 17:59:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43532
[Bug tree-optimization/43505] [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3
--- Comment #9 from hubicka at gcc dot gnu dot org 2010-03-27 18:30 --- Have patch in testing. Problem is that inliner is copying the clone info including the replacement when producing clone of clone that leads to transformations sometimes being applied multiple times. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-03-24 09:52:14 |2010-03-27 18:30:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505
[Bug tree-optimization/42906] [4.5 Regression] Empty loop not removed
--- Comment #26 from hubicka at gcc dot gnu dot org 2010-03-27 18:31 --- Patch queued for next stage1 -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-30 20:56:15 |2010-03-27 18:31:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
[Bug fortran/43266] ICE on invalid: in ensure_not_abstract_walker, at fortran/resolve.c:10290
--- Comment #2 from pault at gcc dot gnu dot org 2010-03-27 18:45 --- Replacing the gcc_assert with if (!overriding || !overriding-n.tb) return FAILURE; Fixes the problem. This looks like one ICE too far :-) It might be best, I suppose, to limit the above to overriding and to retain the assert for its being a typebound procedure, if found. Confirmed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-27 18:45:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43266
[Bug fortran/43210] Initializer of huge static arrays should be improved
--- Comment #3 from pault at gcc dot gnu dot org 2010-03-27 18:47 --- Confirmed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-27 18:47:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210
[Bug fortran/43178] Pointless resetting to NULL for local ALLOCATABLEs
--- Comment #16 from pault at gcc dot gnu dot org 2010-03-27 18:53 --- What is the status of this one Tobias? I'll confirm it whilst I'm here :-) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-27 18:53:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43178
[Bug fortran/42958] Weird temporary array allocation
--- Comment #7 from pault at gcc dot gnu dot org 2010-03-27 18:55 --- Tobias, Can this be closed now? Certainly, it can be confirmed! Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-27 18:55:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug target/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #25 from ghazi at gcc dot gnu dot org 2010-03-27 18:56 --- Subject: Bug 39254 Author: ghazi Date: Sat Mar 27 18:56:08 2010 New Revision: 157780 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157780 Log: Backport: 2009-06-16 Jorn Rennecke joern.renne...@arc.com Janis Johnson janis...@us.ibm.com PR target/39254 * config/rs6000/rs6000.c (rs6000_emit_move): Don't emit a USE for the symbol ref of a constant that is the source of a move - nor for any other not-obvious-label-ref constants. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug target/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #26 from ghazi at gcc dot gnu dot org 2010-03-27 19:03 --- Completed full bootstrap and testsuite on powerpc-unknown-linux-gnu with extra -fpic/-fPIC passes. The only difference was that the testcase va-arg-trap-1.c was fixed. Installed on 4.4 branch. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.4.4 | Known to work|4.5.0 |4.4.4 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug fortran/42958] Weird temporary array allocation
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-27 19:05 ---
I suppose I should have provided a testcase. The FE now produces control-flow
free allocation like:
D.1612 = D.1601 - D.1600;
atmp.5.dtype = 537;
atmp.5.dim[0].stride = 1;
atmp.5.dim[0].lbound = 0;
atmp.5.dim[0].ubound = D.1612;
D.1616 = D.1612 0;
D.1617 = D.1612 + 1;
D.1618 = D.1616 ? 0 : D.1617 * 8;
D.1619 = (void * restrict) __builtin_malloc
(MAX_EXPR D.1618, 1);
D.1620 = D.1619;
atmp.5.data = D.1620;
atmp.5.offset = 0;
but there's still the conditional on negative D.1612. Also deallocation is
D.1621 = (void *) atmp.5.data;
if (D.1621 != 0B)
{
__builtin_free (D.1621);
}
where the check for NULL is not necessary (though the middle end might
be able to remove that condition).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug fortran/42958] Weird temporary array allocation
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-27 19:06 --- Created an attachment (id=20225) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20225action=view) testcase from tonto -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug fortran/42958] Weird temporary array allocation
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-27 19:08 --- The gimplifier of course transforms the COND_EXPRs back to control flow, thus the CFG looks like D.1616 = D.1612 0; D.1617 = D.1612 + 1; if (D.1616 != 0) goto bb 32; else goto bb 33; bb 32: iftmp.17 = 0; goto bb 34; bb 33: iftmp.17 = D.1617 * 8; bb 34: D.1618 = iftmp.17; D.1795 = MAX_EXPR D.1618, 1; D.1619 = __builtin_malloc (D.1795); the question is if the check for negative size is really necessary for compiler-generated allocations of array temporaries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug fortran/43146] Character constant declared in a module does not transfer correctly
--- Comment #13 from pault at gcc dot gnu dot org 2010-03-27 19:11 --- Can we close this one, guys? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
[Bug fortran/42958] Weird temporary array allocation
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-03-27 19:12 --- The middle-end ends up with the following optimized: D.1776_95 = D.1775_94 - D.1591_90; if (D.1776_95 = 0) goto bb 34; else goto bb 33; bb 33: D.1620_204 = __builtin_malloc (D.1795_11); D.1796_281 = iy.dim[1].stride; ... goto bb 35; bb 34: D.1620_135 = __builtin_malloc (1); goto bb 38; bb 35: the loop code bb 38: Invalid sum of incoming frequencies 1062, should be 900 # D.1620_374 = PHI D.1620_204(37), D.1620_135(34) if (D.1620_374 != 0B) goto bb 39; else goto bb 40; bb 39: __builtin_free (D.1620_374); so we are able to prove that if we end up allocating 1 byte only then the loop isn't executed and we just free it (another missed middle-end optimization, p = malloc(1); free (p); isn't optimized away). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug c++/43549] TR1 type_traits are much worse than C++0x type_traits
--- Comment #3 from paolo dot carlini at oracle dot com 2010-03-27 19:27 --- Because maintaining more code is a burden, and TR1, now that C++1x is around the corner is just history, from now on will be only *minimally* maintained. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43549
[Bug c++/43549] TR1 type_traits are much worse than C++0x type_traits
--- Comment #4 from pogonyshev at gmx dot net 2010-03-27 19:33 --- From info: ...some of which have been implemented in an experimental C++0x mode in GCC. Instead of maintaining a separate piece of code you could have one just include another so that they are the same and be done with it. With current situation _default_ mode is worse than it could be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43549
[Bug fortran/43551] New: [4.4/4.5 Regression] Quantum Espresso miscompiled
Quantum Espresso (http://www.quantum-espresso.org/download.php) is miscompiled, cf. http://www.democritos.it/pipermail/pw_forum/2010-March/016356.html Fetch code, configure with F77=gfortran F90=gfortran and compile. Run the example02 and compare the output for ph.x si.dynG with the reference, with an other compiler or with gfortran 4.3. Compare e.g. the Dielectric constant matrix. The error is about 10%; for the Effective charges it is even larger. I am currently hunting the regression and then will try to reduce the code. -- Summary: [4.4/4.5 Regression] Quantum Espresso miscompiled Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551
[Bug fortran/43551] [4.4/4.5 Regression] Quantum Espresso miscompiled
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-27 19:41 --- This is very little information. What target, what set of optimization options? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551
[Bug fortran/43551] [4.4/4.5 Regression] Quantum Espresso miscompiled
--- Comment #2 from burnus at gcc dot gnu dot org 2010-03-27 19:52 --- Working: 2009-04-05-r145558 Failing: 2009-04-06-r145580 Changelog shows a couple of I/O patches - and indeed if one uses the working version with the current 4.4.4 libgfortran the bug is also present. Now, I need to find a minimal example. The I/O patch I suspect is: PR fortran/38654 http://gcc.gnu.org/viewcvs?view=revrevision=145571 -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551
[Bug c++/43549] TR1 type_traits are much worse than C++0x type_traits
--- Comment #5 from paolo dot carlini at oracle dot com 2010-03-27 20:00 --- Evidently, you never studied the actual specs: the C++1x traits are different, in many *incompatible* ways, eg is_lvalue_reference / is_rvalue_reference vs is_reference. Many C++1x traits don't even compile in C++98 mode. And about the various introspection traits which you mentioned, changing those now would break *a lot* of applications which assumed for *many* years essentially PODness for yes, as the TR1 specs allowed. No way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43549
[Bug c++/29615] Class can't be friends of itself?
--- Comment #5 from redi at gcc dot gnu dot org 2010-03-27 20:14 ---
With current versions this is only a warning not an error, changing keywords
from rejects-valid to diagnostic
(In reply to comment #3)
There is no other way to make a member-variable accessible only from all
objects which are of the same type. Am I wrong?
Yes.
(In reply to comment #4)
The error doesn't occur if the friend is a template instance, so it really
doesn't hurt anyone. But it's weird.
template int z
class F {
friend class F0; // error only if 0 removed
};
Well in that case it isn't friends with itself, so not really weird.
This shows that being a template has nothing to do with it:
template int z
class F {
friend class Fz;
};
warning: class Fz is implicitly friends with itself
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|rejects-valid |diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29615
[Bug c++/29615] Class can't be friends of itself?
--- Comment #6 from redi at gcc dot gnu dot org 2010-03-27 20:19 --- I think the warning is reasonable, but it would be nice if it could be disabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29615
[Bug fortran/43551] [4.4/4.5 Regression] Quantum Espresso miscompiled
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-27 20:56 --- No success so far; I will try it tomorrow. To reproduce: Fetch, as written in comment 0, the source code and untar it. ./configure F77=gfortran F90=gfortran FFLAGS_NOOPT='-O0 -g' BLAS_LIBS=-lblas LAPACK_LIBS=-llapack FFLAGS='-O1 -g' make pwall cd ../espresso-4.1.1; ln -s ../espresso-4.1.2/bin . cd examples/example02; ./run_example # abort while: running the phonon calculation at Gamma for Si... You now need and should have: a) results/si.phG.in b) $HOME/tmp/si.wfc and $HOME/tmp/si.save (You can delete all other files under $HOME/tmp/ and under results.) Those files are identical with failing and working libgfortran. Run now: ../../../bin/ph.x si.phG.in The wrong output is in ./si.dynG, stdout and in $HOME/tmp/_phsi.phsave/data-file.xml* Wrong output can for instance be found in *.xml.1 for item DIELECTRIC_CONSTANT The first value should be around 1.380642769884322E+001 and wrong is around 1.283252593899003E+001. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551
[Bug fortran/43146] Character constant declared in a module does not transfer correctly
--- Comment #14 from kargl at gcc dot gnu dot org 2010-03-27 21:22 --- (In reply to comment #13) Can we close this one, guys? Paul Sure. I think that we've demonstrated that it is a gentoo issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #18 from jakub at gcc dot gnu dot org 2010-03-27 21:39 --- The first patch is now in, so this isn't a -fcompare-debug failure anymore. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug fortran/43551] [4.4/4.5 Regression] Quantum Espresso miscompiled
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-27 21:43 --- Just another data point: I have disabled the format caching (format_cache_ok = false in io/format.c), but it did not seem to help (on the trunk). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551
[Bug libfortran/43551] [4.4/4.5 Regression] Quantum Espresso miscompiled
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-27 21:55 --- Fortran. P4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |libfortran Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551
[Bug tree-optimization/43505] [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505
[Bug libfortran/43551] [4.4/4.5 Regression] Quantum Espresso miscompiled
--- Comment #6 from burnus at gcc dot gnu dot org 2010-03-27 22:22 --- The XML reading seems to be OK - at least I have added some write statements to iotk_dat.spp (at the dat = lines; then make update before clean build) and the output is the same for the 2009-04-05 and the trunk libgfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551
[Bug debug/43552] New: FAIL: gcc.dg/guality/pr41353-1.c with -flto and -fwhopr
FAIL: gcc.dg/guality/pr41353-1.c -O2 -flto line 28 i == 37 FAIL: gcc.dg/guality/pr41353-1.c -O2 -flto line 28 i1 == 2 * 37 FAIL: gcc.dg/guality/pr41353-1.c -O2 -flto line 28 i2 == 3 * 37 FAIL: gcc.dg/guality/pr41353-1.c -O2 -fwhopr line 28 i == 37 FAIL: gcc.dg/guality/pr41353-1.c -O2 -fwhopr line 28 i1 == 2 * 37 FAIL: gcc.dg/guality/pr41353-1.c -O2 -fwhopr line 28 i2 == 3 * 37 Executing on host: /home/dave/gnu/gcc-4.5/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .5/objdir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c -O2 -flto -g -lm -o ./pr41353-1.exe(timeout = 300) PASS: gcc.dg/guality/pr41353-1.c -O2 -flto (test for excess errors)Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc/objdir/gcc::/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/.libs:/home/dave/gnu/ gcc/objdir/hppa-linux/libmudflap/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libs sp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libgomp/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc PASS: gcc.dg/guality/pr41353-1.c -O2 -flto execution test Spawning: gdb -nx -nw -quiet -x pr41353-1.gdb ./pr41353-1.exe Reading symbols from /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.e xe...done. Breakpoint 1 at 0x10544: file /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/gualit y/pr41353-1.c, line 17. Breakpoint 1, f2 (i=37, j=65)at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c:21 21 f2 (int i, int j) $1 = 17 $2 = 17 A debugging session is active. Inferior 1 [process 31467] will be killed. Quit anyway? (y or n) [answered Y; input not from terminal] PASS: gcc.dg/guality/pr41353-1.c -O2 -flto line 17 vari == 17 Spawning: gdb -nx -nw -quiet -x pr41353-1.gdb ./pr41353-1.exe Reading symbols from /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.exe...done. Breakpoint 1 at 0x10544: file /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c, line 17. Breakpoint 1, f2 (i=37, j=65) at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c:21 21 f2 (int i, int j) /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.gdb:3: Error in sourced command file: No symbol vari1 in current context. (gdb) UNSUPPORTED: gcc.dg/guality/pr41353-1.c -O2 -flto line 17 vari1 == 2 * 17 Spawning: gdb -nx -nw -quiet -x pr41353-1.gdb ./pr41353-1.exe Reading symbols from /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.exe...done. Breakpoint 1 at 0x10544: file /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c, line 17. Breakpoint 1, f2 (i=37, j=65) at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c:21 21 f2 (int i, int j) /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.gdb:3: Error in sourced command file: No symbol vari2 in current context. (gdb) UNSUPPORTED: gcc.dg/guality/pr41353-1.c -O2 -flto line 17 vari2 == 3 * 17 Spawning: gdb -nx -nw -quiet -x pr41353-1.gdb ./pr41353-1.exe Reading symbols from /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.exe...done. Breakpoint 1 at 0x10544: file /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c, line 17. Breakpoint 1, f2 (i=37, j=65) at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c:21 21 f2 (int i, int j) /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.gdb:3: Error in sourced command file: No symbol vari3 in current context. (gdb) UNSUPPORTED: gcc.dg/guality/pr41353-1.c -O2 -flto line 17 vari3 == 2 * 17 Spawning: gdb -nx -nw -quiet -x pr41353-1.gdb ./pr41353-1.exe Reading symbols from /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.exe...done. Breakpoint 1 at 0x10544: file /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c, line 17. Breakpoint 1, f2 (i=37, j=65) at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c:21 21 f2 (int i, int j) /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.gdb:3: Error in sourced command file: No symbol vari4 in current context. (gdb) UNSUPPORTED: gcc.dg/guality/pr41353-1.c -O2 -flto line 17 vari4 == 3 * 17 Spawning: gdb -nx -nw -quiet -x pr41353-1.gdb ./pr41353-1.exe Reading symbols from /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.exe...done. Breakpoint 1 at 0x10544: file /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c, line 17. Breakpoint 1, f2 (i=37, j=65) at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c:21 21 f2 (int i, int j) /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.gdb:3: Error in sourced command file: No symbol vari5 in current context. (gdb) UNSUPPORTED: gcc.dg/guality/pr41353-1.c -O2 -flto line 17 vari5 == 4 * 17 Spawning: gdb -nx -nw -quiet -x pr41353-1.gdb ./pr41353-1.exe Reading symbols from /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41353-1.exe...done. Breakpoint 1 at 0x10544: file /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr41353-1.c, line 17.
[Bug c/43553] New: libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
While testing the proposed patch to eliminate race conditions in indirect value
profiling...
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00892.html
I found that the many profile testcases failed due unresolved symbols such
as...
__emutls_v.__gcov_indirect_call_counters and
___emutls_v.__gcov_indirect_call_callee.
A review of the later stage libgcc builds revealed that the -DHAVE_CC_TLS flag
was passed
without the associated -DUSE_EMUTLS. The current test for setting -DHAVE_CC_TLS
is based
on the test program...
__thread int a; int b; int main() { return a = b; }
which while it fails under the Apple system gcc 4.2.1 compiler with the
error...
thread_test.c:1: error: thread-local storage not supported for this target
compiles without error and runs fine under the newly built xgcc compiler (due
to
the emutls support). The easy fix appears to be...
2010-03-27 Jack Howarth howa...@bromo.med.uc.edu
* config.host (tmake_file): Add t-emutls for *-*-darwin*.
* t-emutls: New file.
Index: libgcc/config.host
===
--- libgcc/config.host (revision 157779)
+++ libgcc/config.host (working copy)
@@ -597,6 +597,12 @@
esac
case ${host} in
+*-*-darwin*)
+ tmake_file=${tmake_file} t-emutls
+ ;;
+esac
+
+case ${host} in
i[34567]86-*-darwin* | x86_64-*-darwin* | \
i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
i[34567]86-*-linux* | x86_64-*-linux* | \
Index: libgcc/config/t-emutls
===
--- libgcc/config/t-emutls (revision 0)
+++ libgcc/config/t-emutls (revision 0)
@@ -0,0 +1,2 @@
+# Use emulated thread-local storage
+INTERNAL_CFLAGS += -DUSE_EMUTLS
which bootstraps fine on both x86_64-apple-darwin9 and x86_64-apple-darwin10
with the proposed race condition patch...
Index: gcc/tree-profile.c
===
--- gcc/tree-profile.c (revision 157765)
+++ gcc/tree-profile.c (working copy)
@@ -82,6 +82,7 @@
TREE_PUBLIC (ic_void_ptr_var) = 0;
DECL_ARTIFICIAL (ic_void_ptr_var) = 1;
DECL_INITIAL (ic_void_ptr_var) = NULL;
+ DECL_TLS_MODEL (ic_void_ptr_var) = decl_default_tls_model (ic_void_ptr_var);
varpool_finalize_decl (ic_void_ptr_var);
gcov_type_ptr = build_pointer_type (get_gcov_type ());
@@ -93,6 +94,7 @@
TREE_PUBLIC (ic_gcov_type_ptr_var) = 0;
DECL_ARTIFICIAL (ic_gcov_type_ptr_var) = 1;
DECL_INITIAL (ic_gcov_type_ptr_var) = NULL;
+ DECL_TLS_MODEL (ic_gcov_type_ptr_var) = decl_default_tls_model
(ic_gcov_type_ptr_var);
varpool_finalize_decl (ic_gcov_type_ptr_var);
}
with no regressions in the testsuite (particularly the profile section). I
assume when the race
condition fix is committed other targets that use emutls will need to be added
to the
case statement.
--
Summary: libgcc built with -DHAVE_CC_TLS against xgcc when emutls
in use
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: *-apple-darwin*
GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-03-28 02:07 --- I based my proposed patch roughly on the orginal patch that introduced the use of -DHAVE_CC_TLS. Author: hjl Date: Fri Jul 6 14:00:46 2007 New Revision: 126416 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126416 Log: config/ 2007-07-06 H.J. Lu hongjiu...@intel.com * tls.m4 (GCC_CHECK_CC_TLS): New. libgcc/ 2007-07-06 H.J. Lu hongjiu...@intel.com * config.host (tmake_file): Add t-tls for i[34567]86-*-linux* and x86_64-*-linux*. * config/t-tls: New file. * Makefile.in (INTERNAL_CFLAGS): Add @set_have_cc_...@. * configure.ac: Include ../config/enable.m4 and ../config/tls.m4. Use GCC_CHECK_CC_TLS to check if assembler supports TLS and substitute set_have_cc_tls. * configure: Regenerated. libbid/ 2007-07-06 H.J. Lu hongjiu...@intel.com Updated from Intel BID library: * bid_conf.h (BID_THREAD): Defined only if both HAVE_CC_TLS and USE_TLS are defined. Added: trunk/libgcc/config/t-tls Modified: trunk/config/ChangeLog trunk/config/tls.m4 trunk/libgcc/ChangeLog trunk/libgcc/Makefile.in trunk/libgcc/config.host trunk/libgcc/config/libbid/ChangeLog trunk/libgcc/config/libbid/bid_conf.h trunk/libgcc/configure trunk/libgcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-03-28 02:16 --- Created an attachment (id=20226) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20226action=view) proposed patch to pass -DUSE_EMUTLS via libgcc/config/t-emutls on darwin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug libfortran/43551] [4.4/4.5 Regression] I/O regression (wrong values with Quantum Espresso)
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-03-28 03:02 --- I am not able to help here until probably Monday night. Turning off format caching is very easy for debugging purposes. I will keep an eye on this until I can get to a workstation I can use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-03-28 04:39 --- Regression testing of t-emutls.diff patch on x86_64-apple-darwin9 and x86_64-apple-darwin10 at... http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02419.html http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02428.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug c++/42315] [4.3/4.4/4.5 Regression] ICE with invalid array initializer
--- Comment #1 from simartin at gcc dot gnu dot org 2010-03-28 05:16 --- Confirmed. Seems to be due to: http://gcc.gnu.org/viewcvs/trunk/gcc/toplev.c?r1=117578r2=118362diff_format=h -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-28 05:16:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42315
[Bug c++/40405] [4.3/4.4/4.5 Regression] ICE with invalid initialization of template member
--- Comment #3 from simartin at gcc dot gnu dot org 2010-03-28 05:17 --- Seems to be due to: http://gcc.gnu.org/viewcvs/trunk/gcc/toplev.c?r1=117578r2=118362diff_format=h -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40405
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-03-28 05:49 --- Created an attachment (id=20227) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20227action=view) revised proposed patch to pass -DUSE_EMUTLS via libgcc/config/t-emutls on darwin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
