[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 --- Comment #13 from rguenther at suse dot de rguenther at suse dot de 2013-03-05 09:05:04 UTC --- On Mon, 4 Mar 2013, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04 16:18:21 UTC --- So, can the Ada FE be changed to use that? Hacks like this belong with a comment in the FE that needs them IMHO. The 2 other related hacks are in stor-layout.c line 2214 and 2236 though and there are a lot of calls to size_binop in the Ada front-end. IMO this one is really benign compared to the others. Note the hacks all boil down to the fact that FEs use signed array domains but unsigned sizetype TYPE_DOMAIN. The C and C++ FE were adjusted to use (unsigned) [1, 0] for zero-sized arrays - I believe the current hacks are all because of Ada (and yes, I invented them to not need to fiddle with the Ada FE when removing TYPE_IS_SIZETYPE). There is still the Ada FE bug I opened that shows that arrays with [0, USIZETYPE_MAX] vs. [SSIZETYPE_MIN, SSIZETYPE_MAX] do not work. Independent of any hacks to fix the current error to address that you need to work to fix the signedness issue (which may of course require middle-end adjustments). If you don't want overflow you can as well re-set TREE_OVERFLOW on the result ... (just to give another option).
[Bug tree-optimization/56096] Sub-optimal code generated for conditional shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56096 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-05 Component|target |tree-optimization Ever Confirmed|0 |1 --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org 2013-03-05 09:06:22 UTC --- Confirmed. This is a generic problem with the way the tree optimizers and expand work.
[Bug target/56470] [4.8 Regression] ICE output_operand: invalid shift operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56470 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 09:14:46 UTC --- If the folder or GIMPLE passes see it is a shift by 32, they fold it away (with or without a warning), so the fact that it is a constant larger than bitsize of the shifted operand has to be seen only during RTL optimizations.
[Bug lto/56515] [4.8 Regression] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 09:20:36 UTC --- Author: rguenth Date: Tue Mar 5 09:20:30 2013 New Revision: 196452 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196452 Log: 2013-03-05 Richard Biener rguent...@suse.de PR lto/56515 * tree-inline.c (remap_blocks_to_null): New function. (expand_call_inline): When expanding a call stmt without an associated block inline remap all callee blocks to NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c
[Bug lto/56515] [4.8 Regression] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 09:21:10 UTC --- Fixed.
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #28 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 09:38:03 UTC --- Author: jakub Date: Tue Mar 5 09:37:56 2013 New Revision: 196453 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196453 Log: PR middle-end/56461 * tree-vect-stmts.c (free_stmt_vec_info_vec): Call free_stmt_vec_info on any left-over stmt_vec_info in the vector. * tree-vect-loop.c (vect_create_epilog_for_reduction): Release inner_phis vector. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-stmts.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #29 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 09:38:52 UTC --- Author: jakub Date: Tue Mar 5 09:38:48 2013 New Revision: 196454 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196454 Log: PR middle-end/56461 * tree-ssa-loop-niter.c (bb_queue): Remove typedef. (discover_iteration_bound_by_body_walk): Change queues to vecvecbasic_block and queue to vecbasic_block. Fix up spelling in comment. Call safe_push on queues[bound_index] directly. Release queues[queue_index] in every iteration unconditionally. Release bounds vector. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #30 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 09:39:49 UTC --- Author: jakub Date: Tue Mar 5 09:39:43 2013 New Revision: 196455 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196455 Log: PR middle-end/56461 * tree-vect-slp.c (vect_supported_load_permutation_p): Free load_index sbitmap even if some bit in it isn't set. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/56531] New: SLP load permutations cannot share the load between and inside SLP instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56531 Bug #: 56531 Summary: SLP load permutations cannot share the load between and inside SLP instances Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: missed-optimization, wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Blocks: 56270 SLP load permutations are currently severely restricted (only 000..111... is supported) and they do not share the load (ICE before the fix for PR56270). This is because vinfo-vectorized_stmt of the underlying group load includes the very first permutation of the very first SLP instance. The fix here is to make vinfo-vectorized_stmt the group load itself and hook in the permutation only on the consumer.
[Bug tree-optimization/56531] SLP load permutations cannot share the load between and inside SLP instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56531 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-05 Blocks||53947 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 09:53:42 UTC --- Mine.
[Bug tree-optimization/56270] [4.6/4.7/4.8 Regression] loop over array of struct float causes compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56270 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 09:54:43 UTC --- Author: rguenth Date: Tue Mar 5 09:54:29 2013 New Revision: 196458 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196458 Log: 2013-03-05 Richard Biener rguent...@suse.de PR tree-optimization/56270 * tree-vect-slp.c (vect_schedule_slp): Clear vectorized stmts of loads after scheduling an SLP instance. * gcc.dg/vect/slp-38.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/slp-38.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/56270] [4.6/4.7 Regression] loop over array of struct float causes compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56270 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] loop |loop over array of struct |over array of struct float |float causes compiler |causes compiler error: |error: segmentation fault |segmentation fault --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 09:55:18 UTC --- Fixed on trunk sofar.
[Bug c++/56530] Bogus warning with -Wsign-conversion (again)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56530 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-05 10:02:10 UTC --- Mainline and current 4_7-branch are fine. Not sure which patch fixed it.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 10:02:41 UTC --- (In reply to comment #15) (In reply to comment #13) A guess is that you end up creating SSA names during code transform in different order - which can result from walking a hashtable to do things (which might be in different order when it doesn't have the same number of entries). I have verified in the debugger that SRA does not create any new SSA names on its own, all of them are created by renaming after the pass finishes (i.e. by TODO_update_ssa). Note that if you process debug stmts _at all_ (thus end up creating new SSA names because of them) then this will break as well. I'm not sure what you mean. SRA does not process debug stmts but it now creates them. The re-namer is apparently clever enough not to create a PHI node and thus a new SSA name because of debug statements, yet it manages to create them in a different order, probably because it sees uses were there are none without debug statements. Can that be the case? Is creating such uses really a bug? Awww. ISTR SRA creates new decls that are renamed by the SSA renamer. SSA rewriting creates those SSA names when visiting definition sites (this is why it doesn't create PHI nodes for debug uses ... hopefully). Renaming is performed in DOM order, but DOM order has DOM children unordered - can you check if rewrite_update_enter_block visits basic-blocks in different order -g vs. -g0?
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 10:04:11 UTC --- Can you create a testcase that pinpoints the different forwprop results?
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 --- Comment #24 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 10:18:01 UTC --- (In reply to comment #23) How can the patch cause a name collision when all the patch does is avoid creating a new decl...? They are static and thus should be mangled. They clearly aren't. Well, and if we want a new decl just to re-assign a unique name here then we want to copy over alignment information. That is, LTO should handle constant-pool entries by _not_ streaming the decl then. Honza, how are those supposed to make the symtab - WPA - LTRANS transition anyway? The irony being that the initial implementation didn't stream the DECL but was changed because the varpool was just starting to being streamed as well. :-) Yes, we do refer to the in the IL so we need to stream them (in some way). The question is why we don't hit lto-lang.c:lto_set_decl_assembler_name mangling of !TREE_PUBLIC decls when streaming in the decl for the constant pool entries (or when computing the assembler name at some point). I suppose we never compute decl-assembler-name for the constant pool entries but emit them in a special way? At least build_constant_desc seems to create a raw SYMBOL_RER using the raw created label? But then, as we don't stream the constant-descs, the RTL should refer to unique labels (but DECL_NAME and the SYMBOL_REF symbol do not agree). Which means that eventually the following would fix it: Index: gcc/varasm.c === --- gcc/varasm.c(revision 196451) +++ gcc/varasm.c(working copy) @@ -3124,6 +3124,11 @@ build_constant_desc (tree exp, tree decl else align_variable (decl, 0); } + /* If we already had a decl for this constant pool entry adjust its + label to be unique within this translation unit and to make it + consistent with the symbol-ref symbol we use below. */ + else + DECL_NAME (decl) = get_identifier (label); /* Now construct the SYMBOL_REF and the MEM. */ if (use_object_blocks_p ()) can you check that? Thanks.
[Bug middle-end/56526] [4.8 regression] false positive for maybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |4.8.0
[Bug middle-end/56525] [4.8 Regression] Access to ggc_freed memory in flow_loops_find
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56525 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-05 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 10:23:38 UTC --- Mine.
[Bug lto/56532] New: valgrind errors with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56532 Bug #: 56532 Summary: valgrind errors with -flto Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org valgrind --leak-check=full --track-origins=yes --db-attach=yes ./cc1plus pr46984.C -O -fipa-cp -fno-early-inlining -flto -quiet gives: ==5852== Conditional jump or move depends on uninitialised value(s) ==5852==at 0x1205C84: bp_pack_var_len_unsigned(bitpack_d*, unsigned long) (data-streamer.c:36) ==5852==by 0xB2144D: lto_output_edge(lto_simple_output_block*, cgraph_edge*, lto_symtab_encoder_d*) (lto-cgraph.c:277) ==5852==by 0xB2285F: output_outgoing_cgraph_edges(cgraph_edge*, lto_simple_output_block*, lto_symtab_encoder_d*) (lto-cgraph.c:651) ==5852==by 0xB22F9E: output_symtab() (lto-cgraph.c:840) ==5852==by 0xB2DCD1: lto_output() (lto-streamer-out.c:1000) ==5852==by 0xB730F7: ipa_write_summaries_2(opt_pass*, lto_out_decl_state*) (passes.c:2408) ==5852==by 0xB731E6: ipa_write_summaries_1(lto_symtab_encoder_d*) (passes.c:2438) ==5852==by 0xB733B6: ipa_write_summaries() (passes.c:2492) ==5852==by 0x893292: ipa_passes() (cgraphunit.c:1905) ==5852==by 0x8936B7: compile() (cgraphunit.c:1991) ==5852==by 0x8939B7: finalize_compilation_unit() (cgraphunit.c:2119) ==5852==by 0x647071: cp_write_global_declarations() (decl2.c:4318) ==5852== Uninitialised value was created by a client request ==5852==at 0x7F654A: ggc_internal_alloc_stat(unsigned long) (ggc-page.c:1339) ==5852==by 0x886F18: cgraph_create_edge_1(cgraph_node*, cgraph_node*, gimple_statement_d*, long, int) (cgraph.c:793) ==5852==by 0x88714F: cgraph_create_edge(cgraph_node*, cgraph_node*, gimple_statement_d*, long, int) (cgraph.c:838) ==5852==by 0x88F6BF: cgraph_analyze_function(cgraph_node*) (cgraphunit.c:630) ==5852==by 0x8906C8: cgraph_analyze_functions() (cgraphunit.c:964) ==5852==by 0x8939A8: finalize_compilation_unit() (cgraphunit.c:2110) ==5852==by 0x647071: cp_write_global_declarations() (decl2.c:4318) ==5852==by 0xC63E12: compile_file() (toplev.c:557) ==5852==by 0xC65DB5: do_compile() (toplev.c:1876) ==5852==by 0xC65F20: toplev_main(int, char**) (toplev.c:1952) ==5852==by 0x12EC1CD: main (main.c:36) 273 uid = (!gimple_has_body_p (edge-caller-symbol.decl) 274 ? edge-lto_stmt_uid : gimple_uid (edge-call_stmt)); gimple_has_body_p is false (edge-call_stmt is NULL, DECL_STRUCT_FUNCTION (edge-caller-symbol.decl) is NULL), and lto_stmt_uid is clearly uninitialized. When run under gdb rather than valgrind where you can't make interior calls: b lto-cgraph.c:273 if !gimple_has_body_p (edge-caller-symbol.decl) edge-lto_stmt_uid == 0xafafafaf shows (gdb) p debug_generic_stmt (edge-caller-symbol.decl) _ZThn528_N1D3fooEv (gdb) p debug_generic_stmt (edge-callee-symbol.decl) *.LTHUNK0 Which also shows why I haven't seen any such failures in gcc/testsuite/gcc/gcc.log, while tons of them in gcc/testsuite/g++/g++.log - bet only thunks don't have body here and the code doesn't count with those.
[Bug c++/56530] Bogus warning with -Wsign-conversion (again)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56530 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-05 Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-05 10:43:49 UTC --- The fix for c++/53650 did it. I guess we can add a testcase with 1 (instead of 0, as the existing one) and close the PR.
[Bug target/56484] [4.8 Regression] ICE in assign_by_spills, at lra-assigns.c:1268
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56484
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05
11:06:26 UTC ---
Actually, looking more at this, I'd say combiner is innocent here, the problem
is earlier , during ce1 pass, which transforms:
16: ax:SI=call [`output_play'] argc:0
REG_DEAD di:DI
REG_DEAD si:SI
17: r60:SI=ax:SI
REG_DEAD ax:SI
18: flags:CCGOC=cmp(r59:SI,0)
19: pc={(flags:CCGOC=0)?L21:pc}
REG_DEAD flags:CCGOC
REG_BR_PROB 0x1c84
20: NOTE_INSN_BASIC_BLOCK 4
6: r60:SI=r59:SI
REG_DEAD r59:SI
21: L21:
22: NOTE_INSN_BASIC_BLOCK 5
into:
16: ax:SI=call [`output_play'] argc:0
REG_DEAD di:DI
REG_DEAD si:SI
17: r60:SI=ax:SI
REG_DEAD ax:SI
18: flags:CCGOC=cmp(r59:SI,0)
53: flags:CCGOC=cmp(r59:SI,0)
54: r60:SI={(flags:CCGOC=0)?ax:SI:r59:SI}
22: NOTE_INSN_BASIC_BLOCK 4
i.e. does what combiner tries to avoid with hard registers. I don't understand
why it can't use r60:SI instead of ax:SI.
[Bug c++/56530] Bogus warning with -Wsign-conversion (again)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56530 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-03-05 11:14:36 UTC --- Author: paolo Date: Tue Mar 5 11:14:28 2013 New Revision: 196459 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196459 Log: 2013-03-05 Paolo Carlini paolo.carl...@oracle.com PR c++/56530 * g++.dg/warn/Wsign-conversion-2.C: New. Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/56530] Bogus warning with -Wsign-conversion (again)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56530 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-03-05 11:15:23 UTC --- Author: paolo Date: Tue Mar 5 11:15:17 2013 New Revision: 196460 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196460 Log: 2013-03-05 Paolo Carlini paolo.carl...@oracle.com PR c++/56530 * g++.dg/warn/Wsign-conversion-2.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/Wsign-conversion-2.C
[Bug c++/56530] Bogus warning with -Wsign-conversion (again)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56530 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.3 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-05 11:17:03 UTC --- Done.
[Bug tree-optimization/56521] [4.8 Regression] Uninitialized value_id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56521 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 11:36:30 UTC --- Mine.
[Bug rtl-optimization/56484] [4.8 Regression] ICE in assign_by_spills, at lra-assigns.c:1268
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56484 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 #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 11:48:49 UTC --- Created attachment 29583 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29583 gcc48-pr56484.patch Untested fix.
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #31 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 12:01:44 UTC --- I'm going to close this now, the lots has certainly decreased. I have still http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01341.html http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00044.html memory leak fixes waiting for review, but with those and what is already in trunk e.g. none of the gcc.dg/vect/*.c tests leak any memory on x86_64-linux with -O3 -mavx.
[Bug target/55295] [SH] Add support for fipr instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org 2013-03-05 12:28:22
UTC ---
(In reply to comment #4)
Why is a new ABI important?
Because currently, there is no way to pass something like
struct { float x, y, z, w };
as function arguments in registers, although the default SH ABI could allow
passing up to 3 of such vectors. The same applies to
typedef float v4sf __attribute__ ((vector_size (16)));
or
std::arrayfloat, 4
However, code that does that will be incompatible with existing calling
conventions etc, thus a new (additional and optional) ABI.
4.9? That sounds like it could be years off... :(
4.8 is about to be released soon. 4.9 should follow at around the same time
next year. Of course you can still grab the current development version and
use it anytime.
I'm not sure what you mean by 'inline-asm style intrinsics'?
Something like:
static inline void* get_gbr (void) throw ()
{
void* retval;
__asm__ volatile (stc gbr, %0 : =r (retval) : );
return retval;
}
Last time I used inline-asm blocks in GCC it totally broke the optimisation.
It
wouldn't reorder across inline-asm blocks, and it couldn't eliminate any
redundant load/stores appearing within the block in the event the value was
already resident.
Can you give me a small demonstration of what you mean?
I found whenever I touch inline-asm, the block just grows and grows in scope
upwards until my whole tight routine is written in asm... but that was some
years back, GCC3 era.
Yes, there are some limits of what the compiler can do with an asm block. It
won't analyze the contents of the asm block, only the placeholders. Thus it
usually can't eliminate redundant loads/stores.
I'll report examples here as I find compelling situations.
But on a tangent, can you explain this behaviour? It's really ruining my code:
float testfunc(float v, float v2)
{
return v*v2 + v;
}
Compiled with: -O3 -mfused-madd
testfunc:
.LFB1:
.cfi_startproc
mov.l.L3,r1 ;
lds.l@r1+,fpscr ; - why does it mess with fpscr?
add#-4,r1
fmovfr5,fr0
add#4,r1 ; - +4 after -4... redundant?
fmacfr0,fr4,fr0
rts
lds.l@r1+,fpscr
.L4:
.align 2
.L3:
.long__fpscr_values
.cfi_endproc
There's a lot of rubbish in there... I expect:
testfunc:
.LFB1:
.cfi_startproc
fmovfr5,fr0
fmacfr0,fr4,fr0
rts
.cfi_endproc
The fpscr value is changed because its default setting is to operate on
double-precision float values. This is the default configuration of the
compiler. You can change it by using e.g. -m4-single, which will assume that
FPSCR setting is configured for single-precision at function entry/return.
The +4 -4 thing is a known problem and stems from the fact that the FPSCR
load/store insns are available only as post-inc/pre-dec.
I'm also noticing that -ffast-math is inhibiting fmac emission in some cases:
Compiled with: -O3 -mfused-madd -ffast-math
testfunc:
.LFB1:
.cfi_startproc
mov.l.L3,r1
lds.l@r1+,fpscr
fldi1fr0 ; what is a 1.0 doing here?
add#-4,r1
add#4,r1
faddfr4,fr0 ; v+1 ??
fmulfr5,fr0 ; (v+1)*v2 ?? That's not what the code does...
rts
lds.l@r1+,fpscr
What's going on there? That doesn't even look correct...
The transformation is legitimate, although unlucky, since using fmac would be
better in this case.
The original expression 'v*v2 + v' is converted to '(1 + v2)*v' and that's what
the code does. Probably you compiled for little endian and got confused by the
floating point register ordering for arguments. It goes like ...
fr5 = arg 0
fr4 = arg 1
fr7 = arg 2
fr6 = arg 3
...
This is another reason for adding a new ABI, BTW.
[Bug target/56533] New: Linker problem on avr with lto and main function inside archive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533
Bug #: 56533
Summary: Linker problem on avr with lto and main function
inside archive
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: matth...@stdin.nl
When trying to add lto to my Arduino program, it stopped compiling complaining
about missing symbols. I've managed to reduce the problem to below minimal
example. Note that removing anything from below example makes the problem
disappear. In particular, the problem disappears when:
* any of the linker options is removed: -mmcu=atmega328p -Os -flto
-fwhole-program
* the -flto compiler option is removed
* using normal gcc (amd64) instead of avr-gcc
* linking main.o instead of main.a
* declaring realmain as externally_visible in realmain.c
Note that in this example, the actual main() function is inside an archive,
which is probably the reason for this bug / problem.
$ avr-gcc --version
avr-gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ avr-ld --version
GNU ld (GNU Binutils) 2.20.1.20100303
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later
version.
This program has absolutely no warranty.
$ cat main.c
int realmain(void);
int main(void)
{
return realmain();
}
$ cat realmain.c
int realmain(void) {
}
$ cat do
#!/bin/sh
set -x
rm -f main.a
/usr/bin/avr-gcc -c main.c -o main.o
/usr/bin/avr-ar rcs main.a main.o
/usr/bin/avr-gcc -c -flto realmain.c -o realmain.o
/usr/bin/avr-gcc -mmcu=atmega328p -Os -flto -fwhole-program realmain.o
main.a
$ ./do
+ rm -f main.a
+ /usr/bin/avr-gcc -c main.c -o main.o
+ /usr/bin/avr-ar rcs main.a main.o
+ /usr/bin/avr-gcc -c -flto realmain.c -o realmain.o
+ /usr/bin/avr-gcc -mmcu=atmega328p -Os -flto -fwhole-program realmain.o
main.a
main.a(main.o): In function `main':
main.c:(.text+0x8): undefined reference to `realmain'
collect2: error: ld returned 1 exit status
[Bug target/56533] Linker problem on avr with lto and main function inside archive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 12:38:51 UTC --- + /usr/bin/avr-gcc -mmcu=atmega328p -Os -flto -fwhole-program realmain.o main.a please provide the console output produced when adding -v to the above commandline. I suspect that you fall foul of using -fwhole-program without making the whole program visible to gcc via -flto by means of not using a compiler that can handle LTO of static archives. In general, don't use -fwhole-program with -flto, -flto is smart enough to discover things more intelligently.
[Bug middle-end/56525] [4.8 Regression] Access to ggc_freed memory in flow_loops_find
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56525 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 12:51:35 UTC --- Author: rguenth Date: Tue Mar 5 12:51:28 2013 New Revision: 196462 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196462 Log: 2013-03-05 Richard Biener rguent...@suse.de PR middle-end/56525 * loop-init.c (fix_loop_structure): Remove loops in two stages, not freeing them until the end. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-init.c
[Bug middle-end/56525] [4.8 Regression] Access to ggc_freed memory in flow_loops_find
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56525 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 12:52:41 UTC --- Fixed.
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-03-05 Ever Confirmed|0 |1
[Bug target/55295] [SH] Add support for fipr instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295 --- Comment #6 from Manu Evans turkeyman at gmail dot com 2013-03-05 12:53:26 UTC --- Awesome, thanks for the info and help! Strange -m4-single won't work with my toolchain, it says 'not compatible with this configuration' _ Looking forward to all these fixes! :)
[Bug target/56533] Linker problem on avr with lto and main function inside archive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 --- Comment #2 from Matthijs Kooijman matthijs at stdin dot nl 2013-03-05 12:55:47 UTC --- + /usr/bin/avr-gcc -v -mmcu=atmega328p -Os -flto -fwhole-program realmain.o main.a Using built-in specs. COLLECT_GCC=/usr/bin/avr-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper Target: avr Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr Thread model: single gcc version 4.7.2 (GCC) COMPILER_PATH=/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/../../../avr/bin/ LIBRARY_PATH=/usr/lib/gcc/avr/4.7.2/avr5/:/usr/lib/gcc/avr/4.7.2/../../../avr/lib/avr5/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/../../../avr/lib/ COLLECT_GCC_OPTIONS='-v' '-mmcu=atmega328p' '-Os' '-flto' '-fwhole-program' /usr/lib/gcc/avr/4.7.2/collect2 -flto -m avr5 -Tdata 0x800100 /usr/lib/gcc/avr/4.7.2/../../../avr/lib/avr5/crtm328p.o -L/usr/lib/gcc/avr/4.7.2/avr5 -L/usr/lib/gcc/avr/4.7.2/../../../avr/lib/avr5 -L/usr/lib/gcc/avr/4.7.2 -L/usr/lib/gcc/avr/4.7.2/../../../avr/lib realmain.o main.a -lgcc -lc -lgcc /usr/bin/avr-gcc @/tmp/ccYrSTvi.args Using built-in specs. COLLECT_GCC=/usr/bin/avr-gcc Target: avr Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr Thread model: single gcc version 4.7.2 (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-mmcu=atmega328p' '-Os' '-fwhole-program' '-fltrans-output-list=/tmp/ccZEu3t3.ltrans.out' '-fwpa' /usr/lib/gcc/avr/4.7.2/lto1 -quiet -dumpbase realmain.o -mmcu=atmega328p -auxbase realmain -Os -version -fwhole-program -fltrans-output-list=/tmp/ccZEu3t3.ltrans.out -fwpa @/tmp/ccOsOe32 GNU GIMPLE (GCC) version 4.7.2 (avr) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU GIMPLE (GCC) version 4.7.2 (avr) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COMPILER_PATH=/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/../../../avr/bin/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/../../../avr/bin/ LIBRARY_PATH=/usr/lib/gcc/avr/4.7.2/avr5/:/usr/lib/gcc/avr/4.7.2/../../../avr/lib/avr5/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/../../../avr/lib/ COLLECT_GCC_OPTIONS='-c' '-v' '-mmcu=atmega328p' '-Os' '-fwhole-program' '-fltrans-output-list=/tmp/ccZEu3t3.ltrans.out' '-fwpa' /usr/bin/avr-gcc @/tmp/ccoysJBM.args Using built-in specs. COLLECT_GCC=/usr/bin/avr-gcc Target: avr Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr Thread model: single gcc version 4.7.2 (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-mmcu=atmega328p' '-Os' '-fwhole-program' '-fltrans-output-list=/tmp/ccZEu3t3.ltrans.out' '-fltrans' '-o' '/tmp/ccZEu3t3.ltrans0.ltrans.o' /usr/lib/gcc/avr/4.7.2/lto1 -quiet -dumpbase ccZEu3t3.ltrans0.o -mmcu=atmega328p -auxbase-strip /tmp/ccZEu3t3.ltrans0.ltrans.o -Os -version -fwhole-program -fltrans-output-list=/tmp/ccZEu3t3.ltrans.out -fltrans @/tmp/ccAudUT3 -o /tmp/ccyDScYi.s GNU GIMPLE (GCC) version 4.7.2 (avr) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU GIMPLE (GCC) version 4.7.2 (avr) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-c' '-v' '-mmcu=atmega328p' '-Os' '-fwhole-program' '-fltrans-output-list=/tmp/ccZEu3t3.ltrans.out' '-fltrans' '-o' '/tmp/ccZEu3t3.ltrans0.ltrans.o' /usr/lib/gcc/avr/4.7.2/../../../avr/bin/as -mmcu=atmega328p -mno-skip-bug -o /tmp/ccZEu3t3.ltrans0.ltrans.o
[Bug target/56533] Linker problem on avr with lto and main function inside archive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 --- Comment #3 from Matthijs Kooijman matthijs at stdin dot nl 2013-03-05 13:06:18 UTC --- Seems I made a wrong observation in my original report: When I link main.o instead of main.a, the problem does _not_ go away. In fact, I can remove a few more flags then, while still keeping the problem around: $ ./do + rm -f main.a main.o realmain.o + /usr/bin/avr-gcc -c main.c -o main.o + /usr/bin/avr-gcc -c -flto realmain.c -o realmain.o + /usr/bin/avr-gcc -flto -fwhole-program realmain.o main.o main.o: In function `main': main.c:(.text+0x8): undefined reference to `realmain' collect2: error: ld returned 1 exit status main.c and realmain.c are the same as before. However, adding -flto to the main.c compilation makes the problem disappear again. I suspect that this means that without -flto, main.o is passed straight to the linker and with -flto it is included in link-time optimization, which would mean your previous analysis still holds. $ ./do + rm -f *.a main.o realmain.o + /usr/bin/avr-gcc -c -flto main.c -o main.o + /usr/bin/avr-gcc -c -flto realmain.c -o realmain.o + /usr/bin/avr-gcc -flto -fwhole-program realmain.o main.o
[Bug c++/56534] New: [4.7/4.8 Regression] ICE Segfault on invalid code in check_elaborated_type_specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56534 Bug #: 56534 Summary: [4.7/4.8 Regression] ICE Segfault on invalid code in check_elaborated_type_specifier Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@abeckmann.de The following line of invalid code causes an ICE Segfault, this is a regression from 4.6 behavior: = 8 = template struct template rebind = 8 = $ g++-4.7.x -v -c ice-segfault.cpp Using built-in specs. COLLECT_GCC=/opt/software/x86_64/gcc-4.7.x/bin/g++-4.7.x Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4_7-branch/configure --prefix=/opt/software/x86_64/gcc-4.7.x --program-suffix=-4.7.x --enable-languages=c,c++,fortran --enable-checking Thread model: posix gcc version 4.7.3 20130304 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /opt/software/x86_64/gcc-4.7.x/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/cc1plus -quiet -v -imultilib . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE ice-segfault.cpp -quiet -dumpbase ice-segfault.cpp -mtune=generic -march=x86-64 -auxbase ice-segfault -version -o /tmp/ccr5sP7L.s GNU C++ (GCC) version 4.7.3 20130304 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.3 20130304 (prerelease), GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu ignoring nonexistent directory /opt/software/x86_64/gcc-4.7.x/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /opt/software/x86_64/gcc-4.7.x/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3 /opt/software/x86_64/gcc-4.7.x/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/x86_64-unknown-linux-gnu/. /opt/software/x86_64/gcc-4.7.x/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/backward /opt/software/x86_64/gcc-4.7.x/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include /usr/local/include /opt/software/x86_64/gcc-4.7.x/include /opt/software/x86_64/gcc-4.7.x/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++ (GCC) version 4.7.3 20130304 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.3 20130304 (prerelease), GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 52ed9e0a10a946085ed136449fb02111 ice-segfault.cpp:1:37: internal compiler error: Segmentation fault Please submit a full bug report, $ g++-trunk -v -c ice-segfault.cpp Using built-in specs. COLLECT_GCC=/opt/software/x86_64/gcc-trunk/bin/g++-trunk Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/opt/software/x86_64/gcc-trunk --program-suffix=-trunk --enable-languages=c,c++,fortran --enable-checking Thread model: posix gcc version 4.8.0 20130302 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /opt/software/x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus -quiet -v -imultilib . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE ice-segfault.cpp -quiet -dumpbase ice-segfault.cpp -mtune=generic -march=x86-64 -auxbase ice-segfault -version -o /tmp/ccVB908D.s GNU C++ (GCC) version 4.8.0 20130302 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.0 20130302 (experimental), GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu ignoring nonexistent directory /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0 /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu/. /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include /usr/local/include /opt/software/x86_64/gcc-trunk/include /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++ (GCC) version 4.8.0 20130302 (experimental) (x86_64-unknown-linux-gnu) compiled by
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #25 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05
13:19:53 UTC ---
Btw, I cannot reproduce the issue with
t.c:
void bar (int *);
void foo (void)
{
int a[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0 };
bar (a);
}
t2.c
void bar (int *);
void baz (void)
{
int a[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, 0 };
bar (a);
}
t3.c:
void bar (int *a) { __builtin_printf (%d\n, a[25]); }
int main()
{
foo ();
baz ();
return 0;
}
and
gcc t.c t2.c t3.c -flto
I see three .LC0 being streamed in at WPA stage, shipped to a single
LTRANS unit and there getting .LC0, .LC1, and .LC2 symbols by means
of the existing build_constant_desc (they have all .LCO DECL_NAME decls,
but hey - even that would be fixed by my suggested patch.
Trying LTO Ada bootstrap now. But I really fail to see how it should
break.
[Bug c++/56534] [4.7/4.8 Regression] ICE Segfault on invalid code in check_elaborated_type_specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56534 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-05 13:31:14 UTC --- Looks like a Dup of PR55786.
[Bug target/56533] Linker problem on avr with lto and main function inside archive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 13:41:01 UTC --- Yes. You are not using a linker-plugin which would end up basically ignoring -fwhole-program. With -fwhole-program you are basically lieing to GCC.
[Bug c++/56534] [4.7/4.8 Regression] ICE Segfault on invalid code in check_elaborated_type_specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56534 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |4.7.3
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-05 13:43:57 UTC --- This failure has re-appeared at r196444 on x86_64-apple-darwin12... FAIL: g++.dg/debug/dwarf2/thunk1.C -std=gnu++98 scan-assembler-times LFB3 5 FAIL: g++.dg/debug/dwarf2/thunk1.C -std=gnu++11 scan-assembler-times LFB3 5
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #10 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-05 13:48:03 UTC --- Created attachment 29584 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29584 m32 thunk1.s -std=gnu++98 on x86_64-apple-darwin12 at r196444 Generated with... /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++ -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130304/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C -fno-diagnostics-show-caret -nostdinc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/include/x86_64-apple-darwin12.2.0 -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/include -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130304/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130304/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130304/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -g -fpic -fno-dwarf2-cfi-asm -S -m32 -o thunk1.s
[Bug debug/56510] [4.7/4.8 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 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 #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 13:50:28 UTC --- Created attachment 29585 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29585 gcc48-pr56510.patch Untested fix.
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #26 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05
13:51:28 UTC ---
The question is why we don't hit lto-lang.c:lto_set_decl_assembler_name
mangling of !TREE_PUBLIC decls when streaming in the decl for the constant
pool entries (or when computing the assembler name at some point).
I suppose we never compute decl-assembler-name for the constant pool entries
but emit them in a special way?
Right, see make_decl_rtl:
/* If this variable belongs to the global constant pool, retrieve the
pre-computed RTL or recompute it in LTO mode. */
if (TREE_CODE (decl) == VAR_DECL DECL_IN_CONSTANT_POOL (decl))
{
SET_DECL_RTL (decl, output_constant_def_1 (DECL_INITIAL (decl),
decl, 1));
return;
}
At least build_constant_desc seems to create a raw SYMBOL_RER using the raw
created label? But then, as we don't stream the constant-descs, the RTL
should refer to unique labels (but DECL_NAME and the SYMBOL_REF symbol do not
agree).
I think the problem is that, with your patch, the DECLs are not unified when
they have the same DECL_INITIAL (decl), even if they have the same RTL in the
end.
[Bug fortran/56535] New: ICE: in build2_stat, at tree.c:3885 when compiling with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56535 Bug #: 56535 Summary: ICE: in build2_stat, at tree.c:3885 when compiling with -fsanitize=address Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ja...@redhat.com, ja...@gcc.gnu.org The following tests FAIL: gfortran.dg/allocate_alloc_opt_10.f90 -O* (internal compiler error) FAIL: gfortran.dg/class_allocate_1.f03 -O* (internal compiler error) FAIL: gfortran.dg/class_allocate_12.f90 -O* (internal compiler error) FAIL: gfortran.dg/class_allocate_3.f03 -O* (internal compiler error) FAIL: gfortran.dg/class_allocate_6.f03 -O* (internal compiler error) FAIL: gfortran.dg/class_defined_operator_1.f03 -O* (internal compiler error) FAIL: gfortran.dg/typebound_operator_9.f03 -O* (internal compiler error) fail to compile with -fsanitize=address. The error is the same ... internal compiler error: in build2_stat, at tree.c:3885 Reduced test case from class_allocate_1.f03 implicit none type t1 integer :: comp = 5 class(t1),pointer :: cc end type type, extends(t1) :: t2 integer :: j end type class(t1),pointer :: cp, cp2 allocate(t2 :: cp2) allocate(cp, source = cp2) deallocate(cp) deallocate(cp2) end
[Bug lto/56536] New: GCC with LTO and `-march=pentium3' tries to generate SSE2 code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56536 Bug #: 56536 Summary: GCC with LTO and `-march=pentium3' tries to generate SSE2 code Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 29586 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29586 Testcase Fails with error: '__builtin_ia32_cvtps2dq' needs isa option -m32 -msse2.
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #27 from rguenther at suse dot de rguenther at suse dot de
2013-03-05 13:58:15 UTC ---
On Tue, 5 Mar 2013, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #26 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05
13:51:28 UTC ---
The question is why we don't hit lto-lang.c:lto_set_decl_assembler_name
mangling of !TREE_PUBLIC decls when streaming in the decl for the constant
pool entries (or when computing the assembler name at some point).
I suppose we never compute decl-assembler-name for the constant pool entries
but emit them in a special way?
Right, see make_decl_rtl:
/* If this variable belongs to the global constant pool, retrieve the
pre-computed RTL or recompute it in LTO mode. */
if (TREE_CODE (decl) == VAR_DECL DECL_IN_CONSTANT_POOL (decl))
{
SET_DECL_RTL (decl, output_constant_def_1 (DECL_INITIAL (decl),
decl, 1));
return;
}
At least build_constant_desc seems to create a raw SYMBOL_RER using the raw
created label? But then, as we don't stream the constant-descs, the RTL
should refer to unique labels (but DECL_NAME and the SYMBOL_REF symbol do
not
agree).
I think the problem is that, with your patch, the DECLs are not unified when
they have the same DECL_INITIAL (decl), even if they have the same RTL in the
end.
Hmm, but when I use the same contents for the two arrays in my simple
testcase I do get only a single .LC0 output referenced from two places.
We will end up sharing the same RTL for both (unmerged) DECLs - but
I don't see how this can be a problem? Maybe we fail to set
TREE_ASM_WRITTEN on the duplicate and output it anyway via other
mechanisms?
But I can reproduce the Ada LTO bootstrap failure ...
[Bug c++/56537] New: [C++11] lambda expression treats members as const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56537
Bug #: 56537
Summary: [C++11] lambda expression treats members as const
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: martin.vgag...@gmx.net
The following code won't compile on GCC 4.7.2:
#include vector
templatetypename T struct Foo {
std::vectorint member;
Foo() {
auto f = [this]() {
#if 0
this-
#endif
member.push_back(42);
};
};
};
void bar() { Fooint foo; }
The compiler reports:
foo.cc: In lambda function:
foo.cc:9:26: error: no matching function for call to
‘std::vectorint::push_back(int) const’
foo.cc:9:26: note: candidates are:
In file included from …/4.7.2/include/g++-v4/vector:65:0,
from foo.cc:1:
…/4.7.2/include/g++-v4/bits/stl_vector.h:881:7: note: void std::vector_Tp,
_Alloc::push_back(const value_type) [with _Tp = int; _Alloc =
std::allocatorint; std::vector_Tp, _Alloc::value_type = int] near match
…/4.7.2/include/g++-v4/bits/stl_vector.h:881:7: note: no known conversion for
implicit ‘this’ parameter from ‘const std::vectorint*’ to ‘std::vectorint*’
…/4.7.2/include/g++-v4/bits/stl_vector.h:899:7: note: void std::vector_Tp,
_Alloc::push_back(std::vector_Tp, _Alloc::value_type) [with _Tp = int;
_Alloc = std::allocatorint; std::vector_Tp, _Alloc::value_type = int] near
match
…/4.7.2/include/g++-v4/bits/stl_vector.h:899:7: note: no known conversion for
implicit ‘this’ parameter from ‘const std::vectorint*’ to ‘std::vectorint*’
But the this parameter in this case is a Foo* const, not a const
std::vectorint*. There are several ways to avoid this problem: one can
enable the this- prefix currently disabled using the preprocessor. Or one
can make the whole lambda mutable. But as this appears to be a strange corner
case only encountered in the interplay of several templates, I doubt that this
is intended behaviour.
[Bug c++/56537] [C++11] lambda expression treats members as const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56537 Martin von Gagern Martin.vGagern at gmx dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Martin von Gagern Martin.vGagern at gmx dot net 2013-03-05 14:10:14 UTC --- Looks like a duplicate of bug #54277. Sorry for the noise, but I mixed up my searches and missed that hit while writing the report. *** This bug has been marked as a duplicate of bug 54277 ***
[Bug c++/54277] Template class member referred to with implicit this inside lambda is incorrectly const-qualified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54277 Martin von Gagern Martin.vGagern at gmx dot net changed: What|Removed |Added CC||Martin.vGagern at gmx dot ||net --- Comment #4 from Martin von Gagern Martin.vGagern at gmx dot net 2013-03-05 14:10:14 UTC --- *** Bug 56537 has been marked as a duplicate of this bug. ***
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2013-03-05 14:21:02 UTC --- It seems that darwin doesn't do PIC the way ELF targets do, so this test should be skipped.
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #28 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05
14:23:19 UTC ---
Hmm, but when I use the same contents for the two arrays in my simple
testcase I do get only a single .LC0 output referenced from two places.
We will end up sharing the same RTL for both (unmerged) DECLs - but
I don't see how this can be a problem? Maybe we fail to set
TREE_ASM_WRITTEN on the duplicate and output it anyway via other
mechanisms?
We simply fail to set TREE_ASM_WRITTEN on the DECL_INITIAL (decl) because it is
not shared anymore. So probably:
Index: varasm.c
===
--- varasm.c(revision 196416)
+++ varasm.c(working copy)
@@ -3112,7 +3112,6 @@ build_constant_desc (tree exp, tree decl
LTO mode. Instead we set the flag that will be recognized in
make_decl_rtl. */
DECL_IN_CONSTANT_POOL (decl) = 1;
- DECL_INITIAL (decl) = desc-value;
/* ??? CONSTANT_ALIGNMENT hasn't been updated for vector types on most
architectures so use DATA_ALIGNMENT as well, except for strings. */
if (TREE_CODE (exp) == STRING_CST)
@@ -3125,6 +3124,8 @@ build_constant_desc (tree exp, tree decl
align_variable (decl, 0);
}
+ DECL_INITIAL (decl) = desc-value;
+
/* Now construct the SYMBOL_REF and the MEM. */
if (use_object_blocks_p ())
{
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #29 from rguenther at suse dot de rguenther at suse dot de
2013-03-05 14:26:00 UTC ---
On Tue, 5 Mar 2013, rguenther at suse dot de wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #27 from rguenther at suse dot de rguenther at suse dot de
2013-03-05 13:58:15 UTC ---
On Tue, 5 Mar 2013, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #26 from Eric Botcazou ebotcazou at gcc dot gnu.org
2013-03-05 13:51:28 UTC ---
The question is why we don't hit lto-lang.c:lto_set_decl_assembler_name
mangling of !TREE_PUBLIC decls when streaming in the decl for the constant
pool entries (or when computing the assembler name at some point).
I suppose we never compute decl-assembler-name for the constant pool
entries
but emit them in a special way?
Right, see make_decl_rtl:
/* If this variable belongs to the global constant pool, retrieve the
pre-computed RTL or recompute it in LTO mode. */
if (TREE_CODE (decl) == VAR_DECL DECL_IN_CONSTANT_POOL (decl))
{
SET_DECL_RTL (decl, output_constant_def_1 (DECL_INITIAL (decl),
decl, 1));
return;
}
At least build_constant_desc seems to create a raw SYMBOL_RER using the
raw
created label? But then, as we don't stream the constant-descs, the RTL
should refer to unique labels (but DECL_NAME and the SYMBOL_REF symbol do
not
agree).
I think the problem is that, with your patch, the DECLs are not unified when
they have the same DECL_INITIAL (decl), even if they have the same RTL in
the
end.
Hmm, but when I use the same contents for the two arrays in my simple
testcase I do get only a single .LC0 output referenced from two places.
We will end up sharing the same RTL for both (unmerged) DECLs - but
I don't see how this can be a problem? Maybe we fail to set
TREE_ASM_WRITTEN on the duplicate and output it anyway via other
mechanisms?
So in fact the issue must be that we _do_ share the constant pool
entry but not the decl we use to refer to it. Which isn't very
easily fixable (well, it _is_ fixable, but ... )
OTOH in assemble_variable we properly use
/* If this symbol belongs to the tree constant pool, output the constant
if it hasn't already been written. */
if (TREE_CONSTANT_POOL_ADDRESS_P (symbol))
{
tree decl = SYMBOL_REF_DECL (symbol);
if (!TREE_ASM_WRITTEN (DECL_INITIAL (decl)))
output_constant_def_contents (symbol);
return;
}
so any constant pool entry shouldn't be emitted multiple times ...
But I can reproduce the Ada LTO bootstrap failure ...
So we can revert the part of the patch that ends up not creating
a new decl but only transfer DECL_ALIGN. But then we still don't
merge the decls we use to refer to the constants, so I wonder
how creating less decls can fix this issue at all ...
Note that merging constants but not decls also can end up
creating bogusly aligned constants. In fact it seems to me
that we need to arrange for the LTO path
/* If this variable belongs to the global constant pool, retrieve the
pre-computed RTL or recompute it in LTO mode. */
if (TREE_CODE (decl) == VAR_DECL DECL_IN_CONSTANT_POOL (decl))
{
SET_DECL_RTL (decl, output_constant_def_1 (DECL_INITIAL (decl),
decl, 1));
return;
}
to never share a constant pool entry ... :/
Bah. A reduced testcase would be nice to have ...
[Bug target/56538] New: No opiton to disable slow 'lock' instr. one does not need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56538
Bug #: 56538
Summary: No opiton to disable slow 'lock' instr. one does not
need
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
Target: x86_64-unknown-linux-gnu
When no threads / shared mem is in use 'lock' has no benefits.
But it still has heavy performance hit.
#include memory
#include unistd.h
#include sys/wait.h
int main() {
const int jobs=8;
pid_t pid[jobs];
std::shared_ptrint p(new int());
for (int job=0;jobjobs;job++)
if ((pid[job]=fork())==0) {
for (int i=0;i10;i++)
std::shared_ptrint q(p);
_exit(0);
}
for (int job=0;jobjobs;job++)
waitpid(pid[job],NULL,0);
}
g++ -o bench1 bench1.C -Wall -g -std=gnu++11 -O3
7.816s
g++ bench1.C -Wall -g -std=gnu++11 -O3 -S -o -|g++ -Dlock= -o bench1 -x
assembler-with-cpp - -lstdc++
7.150s
= 9.3% improvement
fork() has to be there to see an improvement - Intel i7-920 probably ignores
'lock' when only single core runs.
gcc-4.8.0-0.14.fc19.x86_64
[Bug target/56533] Linker problem on avr with lto and main function inside archive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 Matthijs Kooijman matthijs at stdin dot nl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #5 from Matthijs Kooijman matthijs at stdin dot nl 2013-03-05 14:38:36 UTC --- Just for future reference, the problem here seems to be that I'm using -fwhole-program, but the GCC LTO cannot actually look at the whole program. In particular, .a archives and .o object files that were compiled without -flto, are passed directly to the linker and not included in LTO. Since -fwhole-program makes the compiler assume that all files that are included in LTO compose the whole program, the compiler removes symbols that look unused, but then turn up missing in the final link. So, I shouldn't have been using -fwhole-program, or I should be aware of the above and set externally_visible attributes as needed if I insist on using -fwhole-program. Ideally, the compiler would ask the linker about which symbols are used in these non-LTO objects, which is done by -fuse-linker-plugin (which is implied by -flto). However, on the AVR target, it seems there is no linker plugin (at least not in this particular case), which means that without -fwhole-program, the compiler cannot optimize as much (since it has to assume that all symbols are externally visible).
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #30 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05
14:39:00 UTC ---
So we can revert the part of the patch that ends up not creating
a new decl but only transfer DECL_ALIGN. But then we still don't
merge the decls we use to refer to the constants, so I wonder
how creating less decls can fix this issue at all ...
That would be worse, DECL_ALIGN should _not_ be fiddled with for constant pool
entries in the first place since the constant/DECL_INITIAL is shared.
Note that merging constants but not decls also can end up
creating bogusly aligned constants. In fact it seems to me
that we need to arrange for the LTO path
/* If this variable belongs to the global constant pool, retrieve the
pre-computed RTL or recompute it in LTO mode. */
if (TREE_CODE (decl) == VAR_DECL DECL_IN_CONSTANT_POOL (decl))
{
SET_DECL_RTL (decl, output_constant_def_1 (DECL_INITIAL (decl),
decl, 1));
return;
}
to never share a constant pool entry ... :/
We should simply not touch DECL_IN_CONSTANT_POOL variables, since they are not
regular VAR_DECLs but only represent the underlying constant.
[Bug c++/55786] g++ segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55786 Andreas Beckmann gcc at abeckmann dot de changed: What|Removed |Added CC||gcc at abeckmann dot de --- Comment #1 from Andreas Beckmann gcc at abeckmann dot de 2013-03-05 14:39:58 UTC --- PR56534 is probably a duplicate of this Found: 4.8.0 4.7.3 Notfound: 4.6.4 $ g++-trunk -v -c /tmp/bug.cpp Using built-in specs. COLLECT_GCC=/opt/software/x86_64/gcc-trunk/bin/g++-trunk Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/opt/software/x86_64/gcc-trunk --program-suffix=-trunk --enable-languages=c,c++,fortran --enable-checking Thread model: posix gcc version 4.8.0 20130302 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /opt/software/x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus -quiet -v -imultilib . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE /tmp/bug.cpp -quiet -dumpbase bug.cpp -mtune=generic -march=x86-64 -auxbase bug -version -o /tmp/ccqIqNaE.s GNU C++ (GCC) version 4.8.0 20130302 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.0 20130302 (experimental), GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu ignoring nonexistent directory /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0 /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu/. /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include /usr/local/include /opt/software/x86_64/gcc-trunk/include /opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++ (GCC) version 4.8.0 20130302 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.0 20130302 (experimental), GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: eedf9bce273f5c2d2f3e6a014c94ec56 /tmp/bug.cpp:8:17: error: ‘’ should be ‘ ’ within a nested template argument list struct FooBarT::template Baztrue ^ /tmp/bug.cpp:8:30: internal compiler error: Segmentation fault struct FooBarT::template Baztrue ^ 0xa7da8f crash_signal ../../gcc-trunk/gcc/toplev.c:332 0x5331de check_elaborated_type_specifier(tag_types, tree_node*, bool) ../../gcc-trunk/gcc/cp/decl.c:11731 0x61d1de cp_parser_elaborated_type_specifier ../../gcc-trunk/gcc/cp/parser.c:14256 0x5fad08 cp_parser_type_specifier ../../gcc-trunk/gcc/cp/parser.c:13601 0x6121ed cp_parser_decl_specifier_seq ../../gcc-trunk/gcc/cp/parser.c:10900 0x616163 cp_parser_single_declaration ../../gcc-trunk/gcc/cp/parser.c:21915 0x618ee2 cp_parser_template_declaration_after_export ../../gcc-trunk/gcc/cp/parser.c:21800 0x6207f9 cp_parser_declaration ../../gcc-trunk/gcc/cp/parser.c:10309 0x61f3dd cp_parser_declaration_seq_opt ../../gcc-trunk/gcc/cp/parser.c:10231 0x620c82 cp_parser_translation_unit ../../gcc-trunk/gcc/cp/parser.c:3807 0x620c82 c_parse_file() ../../gcc-trunk/gcc/cp/parser.c:28182 0x728794 c_common_parse_file() ../../gcc-trunk/gcc/c-family/c-opts.c:1046 Please submit a full bug report,
[Bug target/56533] Linker problem on avr with lto and main function inside archive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 Matthijs Kooijman matthijs at stdin dot nl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Matthijs Kooijman matthijs at stdin dot nl 2013-03-05 14:40:15 UTC --- w00ps, didn't mean to change the resolution.
[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #21 from Steven Bosscher steven at gcc dot gnu.org 2013-03-05 14:45:32 UTC --- Author: steven Date: Tue Mar 5 14:45:23 2013 New Revision: 196464 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196464 Log: gcc/ PR c++/55135 * except.h (remove_unreachable_eh_regions): New prototype. * except.c (remove_eh_handler_splicer): New function, split out of remove_eh_handler. (remove_eh_handler): Use remove_eh_handler_splicer. Add comment warning about running it on many EH regions one at a time. (remove_unreachable_eh_regions_worker): New function, walk the EH tree in depth-first order and remove non-marked regions. (remove_unreachable_eh_regions): New function. * tree-eh.c (mark_reachable_handlers): New function, split out from remove_unreachable_handlers. (remove_unreachable_handlers): Use mark_reachable_handlers and remove_unreachable_eh_regions. (remove_unreachable_handlers_no_lp): Use mark_reachable_handlers and remove_unreachable_eh_regions. Modified: trunk/gcc/ChangeLog trunk/gcc/except.c trunk/gcc/except.h trunk/gcc/tree-eh.c
[Bug target/56536] GCC with LTO and `-march=pentium3' tries to generate SSE2 code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56536 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-05 Component|lto |target Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 14:49:19 UTC --- Confirmed. Quite weird. It's vectorizing of lrintf obviously, for some reason ix86_builtin_vectorized_function returns a decl with LTO but not without LTO. This function probably does the wrong thing for target attributed functions, too.
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-05 15:01:55 UTC --- (In reply to comment #11) It seems that darwin doesn't do PIC the way ELF targets do, so this test should be skipped. I also confirmed this with stock gcc trunk (to verify that it was unrelated to the proposed fix for PR target/51784 at http://gcc.gnu.org/ml/gcc-bugs/2013-02/msg00468.html).
[Bug tree-optimization/56521] [4.8 Regression] Uninitialized value_id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56521 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 15:03:07 UTC --- Author: rguenth Date: Tue Mar 5 15:02:58 2013 New Revision: 196465 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196465 Log: 2013-03-05 Richard Biener rguent...@suse.de PR tree-optimization/56521 * tree-ssa-sccvn.c (set_value_id_for_result): Always initialize value-id. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #31 from rguenther at suse dot de rguenther at suse dot de
2013-03-05 15:09:06 UTC ---
On Tue, 5 Mar 2013, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #28 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05
14:23:19 UTC ---
Hmm, but when I use the same contents for the two arrays in my simple
testcase I do get only a single .LC0 output referenced from two places.
We will end up sharing the same RTL for both (unmerged) DECLs - but
I don't see how this can be a problem? Maybe we fail to set
TREE_ASM_WRITTEN on the duplicate and output it anyway via other
mechanisms?
We simply fail to set TREE_ASM_WRITTEN on the DECL_INITIAL (decl) because it
is
not shared anymore. So probably:
But in all places I found we check TREE_ASM_WRITTEN on DECL_INITIAL
of the SYMBOL_REF_DECL ...
So it must be pure luck that we survived LTO bootstrap before my
patch (as far as I understand things). Before my patch we created
yet another decl for the constant pool entry. With my patch
we will have one less (we still have the decls from the constant
pool entries that end up being shared in the LTRANS unit).
So in the end I can agree to that my patch doesn't really fix
the original issue fully. So we can as well revert it and
instead avoid messing with alignment of the constant pool entries.
But then the underlying issue with multiple decls refering to
the same constant pool entry with LTO remains, it just happens
that it isn't triggered anymore.
Index: varasm.c
===
--- varasm.c(revision 196416)
+++ varasm.c(working copy)
@@ -3112,7 +3112,6 @@ build_constant_desc (tree exp, tree decl
LTO mode. Instead we set the flag that will be recognized in
make_decl_rtl. */
DECL_IN_CONSTANT_POOL (decl) = 1;
- DECL_INITIAL (decl) = desc-value;
/* ??? CONSTANT_ALIGNMENT hasn't been updated for vector types on most
architectures so use DATA_ALIGNMENT as well, except for strings. */
if (TREE_CODE (exp) == STRING_CST)
@@ -3125,6 +3124,8 @@ build_constant_desc (tree exp, tree decl
align_variable (decl, 0);
}
+ DECL_INITIAL (decl) = desc-value;
+
/* Now construct the SYMBOL_REF and the MEM. */
if (use_object_blocks_p ())
{
Hmm, maybe. Then, why do we copy the constant in the first place ...
Thus,
Index: varasm.c
===
--- varasm.c(revision 196462)
+++ varasm.c(working copy)
@@ -3087,7 +3087,7 @@ build_constant_desc (tree exp, tree decl
int labelno;
desc = ggc_alloc_constant_descriptor_tree ();
- desc-value = copy_constant (exp);
+ desc-value = exp;
/* Propagate marked-ness to copied constant. */
if (flag_mudflap mf_marked_p (exp))
should be an equivalent fix.
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-05 15:11:48 UTC --- (In reply to comment #9) This failure has re-appeared at r196444 on x86_64-apple-darwin12... FAIL: g++.dg/debug/dwarf2/thunk1.C -std=gnu++98 scan-assembler-times LFB3 5 FAIL: g++.dg/debug/dwarf2/thunk1.C -std=gnu++11 scan-assembler-times LFB3 5 There are two issues for x86_64-apple-darwin* (1) As noticed in comment #2: On Darwin/x86 (32-bit i386-apple-darwin11.3.0 compiler), LFB3 doesn't occur in thunk1.s at all. (2) Before revision 195842 the test was unsupported on x86_64-*-*. (In reply to comment #11) It seems that darwin doesn't do PIC the way ELF targets do, so this test should be skipped. What is supposed to be tested? Sould the whole test skipped on darwin or only the dg-final?
[Bug tree-optimization/56521] [4.8 Regression] Uninitialized value_id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56521 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 15:13:13 UTC --- Fixed.
[Bug middle-end/56526] [4.8 regression] false positive for maybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 15:16:59 UTC --- Author: jakub Date: Tue Mar 5 15:16:49 2013 New Revision: 196466 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196466 Log: PR middle-end/56526 * simple-object-mach-o.c (simple_object_mach_o_segment): Initialize wrapper_sect_offset to avoid a warning. Modified: trunk/libiberty/ChangeLog trunk/libiberty/simple-object-mach-o.c
[Bug middle-end/56526] [4.8 regression] false positive for maybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 15:22:39 UTC --- Should be fixed hopefully.
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 --- Comment #32 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05 15:32:15 UTC --- But in all places I found we check TREE_ASM_WRITTEN on DECL_INITIAL of the SYMBOL_REF_DECL ... Nope, maybe_output_constant_def_contents has: rtx symbol = XEXP (desc-rtl, 0); tree exp = desc-value; if (flag_syntax_only) return; if (TREE_ASM_WRITTEN (exp)) /* Already output; don't do it again. */ return; so the DECL_INITIAL of the SYMBOL_REF_DECL must be desc-value. So it must be pure luck that we survived LTO bootstrap before my patch (as far as I understand things). Before my patch we created yet another decl for the constant pool entry. With my patch we will have one less (we still have the decls from the constant pool entries that end up being shared in the LTRANS unit). We use LTO on heavy Ada applications with an unmodified 4.7 compiler (modulo a patch for -g) so I don't think that luck has anything to do here. So in the end I can agree to that my patch doesn't really fix the original issue fully. So we can as well revert it and instead avoid messing with alignment of the constant pool entries. That would be my preference. Hmm, maybe. Then, why do we copy the constant in the first place ... Thus, Index: varasm.c === --- varasm.c(revision 196462) +++ varasm.c(working copy) @@ -3087,7 +3087,7 @@ build_constant_desc (tree exp, tree decl int labelno; desc = ggc_alloc_constant_descriptor_tree (); - desc-value = copy_constant (exp); + desc-value = exp; /* Propagate marked-ness to copied constant. */ if (flag_mudflap mf_marked_p (exp)) should be an equivalent fix. This call to copy_constant has been there for ages though. so a little bit of archeology would probably be in order before removing it. In the meantime, I've successfully bootstrapped my patchlet so we can also go for it.
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #14 from Jason Merrill jason at gcc dot gnu.org 2013-03-05 15:41:15 UTC --- (In reply to comment #13) What is supposed to be tested? Should the whole test skipped on darwin or only the dg-final? The whole test; the test is verifying that the x86 PIC thunk doesn't have debug info, but Darwin doesn't emit that thunk.
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 --- Comment #33 from rguenther at suse dot de rguenther at suse dot de 2013-03-05 15:48:03 UTC --- On Tue, 5 Mar 2013, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 --- Comment #32 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05 15:32:15 UTC --- But in all places I found we check TREE_ASM_WRITTEN on DECL_INITIAL of the SYMBOL_REF_DECL ... Nope, maybe_output_constant_def_contents has: rtx symbol = XEXP (desc-rtl, 0); tree exp = desc-value; if (flag_syntax_only) return; if (TREE_ASM_WRITTEN (exp)) /* Already output; don't do it again. */ return; so the DECL_INITIAL of the SYMBOL_REF_DECL must be desc-value. Ah, ok ... too many smart TREE_ASM_WRITTEN bits around ... So it must be pure luck that we survived LTO bootstrap before my patch (as far as I understand things). Before my patch we created yet another decl for the constant pool entry. With my patch we will have one less (we still have the decls from the constant pool entries that end up being shared in the LTRANS unit). We use LTO on heavy Ada applications with an unmodified 4.7 compiler (modulo a patch for -g) so I don't think that luck has anything to do here. Fine, so the above might be the only issue. So in the end I can agree to that my patch doesn't really fix the original issue fully. So we can as well revert it and instead avoid messing with alignment of the constant pool entries. That would be my preference. Which of course pessimizes code generation and probably causes some testsuite fallout for ppc (the original reported spurious fails). Hmm, maybe. Then, why do we copy the constant in the first place ... Thus, Index: varasm.c === --- varasm.c(revision 196462) +++ varasm.c(working copy) @@ -3087,7 +3087,7 @@ build_constant_desc (tree exp, tree decl int labelno; desc = ggc_alloc_constant_descriptor_tree (); - desc-value = copy_constant (exp); + desc-value = exp; /* Propagate marked-ness to copied constant. */ if (flag_mudflap mf_marked_p (exp)) should be an equivalent fix. This call to copy_constant has been there for ages though. so a little bit of archeology would probably be in order before removing it. ;) Did that, it's there since forever - well, I traced it back to the point we only deferred string constants: 37459 jakub p = (struct deferred_string *) 37459 jakub xmalloc (sizeof (struct deferred_string)); 37459 jakub 37459 jakub p-exp = copy_constant (exp); 37459 jakub p-label = desc-label; I'm LTO bootstrapping desc-value = decl ? exp : copy_constant (exp); and doing a regular bootstrap with the copy_constant completely removed at the moment. Just curious ... In the meantime, I've successfully bootstrapped my patchlet so we can also go for it. I'm fine with that. As I concluded that the original fix didn't fix the alignment issue (well, not for all possible cases at least) reverting the original fix works for me as well. I'm working on a patch to avoid re-aligning constant pool entries.
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 15:49:55 UTC --- Author: jakub Date: Tue Mar 5 15:49:43 2013 New Revision: 196467 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196467 Log: PR middle-end/56461 * sched-deps.c (delete_dep_node): Free DEP_REPLACE. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #33 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 15:50:52 UTC --- Author: jakub Date: Tue Mar 5 15:50:38 2013 New Revision: 196468 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196468 Log: PR middle-end/56461 * lra.c (lra): Call lra_clear_live_ranges if live_p, right before calling lra_create_live_ranges, also call it when clearing live_p. Only call lra_clear_live_ranges at the end if live_p. Modified: trunk/gcc/ChangeLog trunk/gcc/lra.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #34 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 15:52:02 UTC --- Author: jakub Date: Tue Mar 5 15:51:48 2013 New Revision: 196469 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196469 Log: PR middle-end/56461 * ggc-common.c (gt_pch_save): For ENABLE_VALGRIND_CHECKING, if VALGRIND_GET_VBITS is defined, temporarily make object memory all defined, and restore previous valgrind addressability and definability afterwards. Free this_object at the end. * c-pch.c (pch_init): Free target_validity at the end. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-pch.c trunk/gcc/ggc-common.c
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 --- Comment #34 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05 16:05:44 UTC --- Created attachment 29587 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29587 Patch to restore LTO bootstrap with Ada + comment tweaks OK, this is the patch I've tested, but it's your call.
[Bug tree-optimization/56539] New: [4.6/4.7/4.8 Regression] ICE: verify_ssa failed: caused by -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56539
Bug #: 56539
Summary: [4.6/4.7/4.8 Regression] ICE: verify_ssa failed:
caused by -foptimize-sibling-calls
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Keywords: ice-on-valid-code, wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
short string2int( const char * buf, unsigned len )
{
return (len 1) ? ( buf[len-1] - '0' ) + (short)10 * string2int(buf,
len-1) : ( *buf - '0' );
}
#include assert.h
int main()
{
assert( string2int(13, 2) == 13);
return 0;
}
At -O2 this program fails the assertion with 4.6 and 4.7
A 4.8 build with --enable-checking gets an ICE in verify_ssa
$ ~/gcc/4.8/bin/gcc t.c -O2
t.c: In function 'string2int':
t.c:12:1: error: definition in block 3 follows the use
}
^
for SSA_NAME: _15 in statement:
acc_tmp_17 = (short int) _15;
t.c:12:1: internal compiler error: verify_ssa failed
0xa57004 verify_ssa(bool)
../../gcc-4.8/gcc/tree-ssa.c:1049
0x83ea9e execute_function_todo
../../gcc-4.8/gcc/passes.c:1967
0x83f56c execute_todo
../../gcc-4.8/gcc/passes.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Using -fno-optimize-sibling-calls makes the bug go away for all versions.
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-05 CC||aldyh at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|Compiler ICE when compiling |[4.8 Regression] Compiler |with -mips16|ICE when compiling with ||-mips16 Ever Confirmed|0 |1 --- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-03-05 16:23:34 UTC --- Confirmed.
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-03-05 16:24:35 UTC --- Created attachment 29588 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29588 reduced testcase
[Bug tree-optimization/56539] [4.6/4.7/4.8 Regression] ICE: verify_ssa failed: caused by -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56539 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.4.3 Known to fail||4.5.2, 4.6.3, 4.7.3, 4.8.0 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-05 16:24:59 UTC --- 4.4.3 is OK, 4.5.2 fails the asertion
[Bug tree-optimization/56539] [4.6/4.7/4.8 Regression] ICE: verify_ssa failed: caused by -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56539 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-05 16:27:50 UTC --- N.B. -O3 is needed to trigger the bug with 4.5.2
[Bug preprocessor/56540] New: No __SIZEOF__XXX__ macro for __float128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56540 Bug #: 56540 Summary: No __SIZEOF__XXX__ macro for __float128 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@johnmaddock.co.uk I'm not sure I have the component set right for this... this is possibly a C and C++ compiler driver issue..? As far as I can tell every builtin type has it's own __SIZEOF__XXX__ macro defined in the preprocessor, which for example makes detecting __int128 support easy via __SIZEOF_INT128__. However there are no corresponding macros for __float80 and __float128. I'd like to see __SIZEOF_FLOAT80__ and __SIZEOF_FLOAT128__ defined when these types are supported by the compiler.
[Bug tree-optimization/56539] [4.6/4.7/4.8 Regression] ICE: verify_ssa failed: caused by -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56539 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-05 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org 2013-03-05 16:34:13 UTC --- Confirmed.
[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #22 from Steven Bosscher steven at gcc dot gnu.org 2013-03-05 16:40:40 UTC --- (In reply to comment #20) I have a fix proper for this problem in testing. Posted for discussion here: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00193.html
[Bug tree-optimization/56541] New: vectorizaton fails in conditional assignment of a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56541
Bug #: 56541
Summary: vectorizaton fails in conditional assignment of a
constant
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
this loop does not vectorize
#includecmath
float a,b,c,d;
float z[1024]; bool ok[1024];
constexpr float rBig = 150.;
void foo() {
for (int i=0;i!=1024;++i) {
float rR = a*z[i];
float rL = b*z[i];
float rMin = (rRrL) ? rR : rL;
float rMax = (rRrL) ? rL : rR;
//rMin = (rMax0) ? rMin : rBig+std::abs(z[i]); // this vectorize (sic...)
rMin = (rMax0) ? rMin : rBig; // comment to vectorize
rMin = (rMin0) ? rMin : rMax;
ok[i] = rMin-crMax+d;
}
}
c++ -std=c++11 -Ofast -march=corei7 -c range.cc -ftree-vectorizer-verbose=1
Analyzing loop at range.cc:8
range.cc:7: note: vectorized 0 loops in function.
range.cc:16: note: vect_recog_bool_pattern: detected:
range.cc:16: note: pattern recognized: VIEW_CONVERT_EXPRunsigned
char(ok[i_22]) = patt_15;
range.cc:16: note: additional pattern stmt: patt_13 = _14 _16 ? 1 : 0;
adding to rBig std::abs(z[i]) it does
c++ -std=c++11 -Ofast -march=corei7 -c range.cc -ftree-vectorizer-verbose=1
Analyzing loop at range.cc:8
range.cc:8: note: vect_recog_bool_pattern: detected:
range.cc:8: note: pattern recognized: VIEW_CONVERT_EXPRunsigned
char(ok[i_24]) = patt_16;
range.cc:8: note: additional pattern stmt: patt_14 = _15 _17 ? 1 : 0;
Vectorizing loop at range.cc:8
range.cc:8: note: LOOP VECTORIZED.
range.cc:7: note: vectorized 1 loops in function.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294
--- Comment #18 from Martin Jambor jamborm at gcc dot gnu.org 2013-03-05
16:49:29 UTC ---
(In reply to comment #17)
Which is the testcase that still fails? The attached and more reduced ones
pass for me ...
The testcase from comment #10 (called Another unrelated issue) still
fails for me with g++ -O2 -fno-ipa-sra -fcompare-debug. (I use trunk
from yesterday).
(In reply to comment #16)
can you check if rewrite_update_enter_block visits basic-blocks
in different order -g vs. -g0?
No, from the dumps it does not seem so (see below). The dump also
shows that in the -g1 case, the renamer sees elim_cost$complexity much
earlier with debug statements. However, even seeing them only a
little bit earlier (BB 17 as opposed to 18) is enough to trigger the
problem. Perhaps because there is a to-be SSA name definition at the
beginning of BB 18?
-g0:
Updating SSA:
Registering new PHI nodes in block #0
Registering new PHI nodes in block #2
Registering new PHI nodes in block #3
Registering new PHI nodes in block #4
Updating SSA information for statement elim_cost$cost = SR.30;
Updating SSA information for statement elim_cost$complexity = SR.31;
Updating SSA information for statement _22 = elim_cost$cost;
Registering new PHI nodes in block #5
Updating SSA information for statement elim_cost$cost = _24;
Registering new PHI nodes in block #6
Updating SSA information for statement cost$cost = elim_cost$cost;
Updating SSA information for statement _74 = cost$cost;
Registering new PHI nodes in block #7
Registering new PHI nodes in block #8
Registering new PHI nodes in block #9
Registering new PHI nodes in block #10
Registering new PHI nodes in block #11
Registering new PHI nodes in block #12
Registering new PHI nodes in block #13
Registering new PHI nodes in block #14
Registering new PHI nodes in block #15
Registering new PHI nodes in block #16
Updating SSA information for statement _50 = elim_cost$cost;
Updating SSA information for statement elim_cost$cost = _51;
Registering new PHI nodes in block #17
Registering new PHI nodes in block #18
Updating SSA information for statement cost$cost = elim_cost$cost;
Updating SSA information for statement cost$complexity = elim_cost$complexity;
Registering new PHI nodes in block #19
Updating SSA information for statement cost$cost = cost$cost;
Updating SSA information for statement _78 = cost$cost;
Registering new PHI nodes in block #20
Symbols to be put in SSA form
{ D.2850 D.2851 D.2854 D.2855 D.2856 D.2857 D.2858 D.2859 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 21
Number of blocks to update: 20 ( 95%)
Affected blocks: 0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
-g1:
Updating SSA:
Registering new PHI nodes in block #0
Registering new PHI nodes in block #2
Registering new PHI nodes in block #3
Registering new PHI nodes in block #4
Updating SSA information for statement elim_cost$cost = SR.30;
Updating SSA information for statement elim_cost$complexity = SR.31;
Updating SSA information for statement _22 = elim_cost$cost;
Registering new PHI nodes in block #5
Updating SSA information for statement elim_cost$cost = _24;
Registering new PHI nodes in block #6
Updating SSA information for statement cost$cost = elim_cost$cost;
Updating SSA information for statement # DEBUG cost$complexity =
elim_cost$complexity
Updating SSA information for statement _74 = cost$cost;
Registering new PHI nodes in block #7
Registering new PHI nodes in block #8
Registering new PHI nodes in block #9
Registering new PHI nodes in block #10
Registering new PHI nodes in block #11
Registering new PHI nodes in block #12
Registering new PHI nodes in block #13
Registering new PHI nodes in block #14
Registering new PHI nodes in block #15
Registering new PHI nodes in block #16
Updating SSA information for statement _50 = elim_cost$cost;
Updating SSA information for statement elim_cost$cost = _51;
Registering new PHI nodes in block #17
Updating SSA information for statement # DEBUG cost1$cost = elim_cost$cost
Updating SSA information for statement # DEBUG cost1$complexity =
elim_cost$complexity
Registering new PHI nodes in block #18
Updating SSA information for statement cost$cost = elim_cost$cost;
Updating SSA information for statement cost$complexity = elim_cost$complexity;
Registering new PHI nodes in block #19
Updating SSA information for statement cost$cost = cost$cost;
Updating SSA information for statement # DEBUG cost$complexity =
cost$complexity
Updating SSA information for statement _78 = cost$cost;
Registering new PHI nodes in block #20
Symbols to be put in SSA form
{ D.2850 D.2851 D.2854 D.2855 D.2856 D.2857 D.2858 D.2864 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 21
Number of blocks to update: 20 ( 95%)
Affected blocks: 0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363
--- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-05
16:55:07 UTC ---
(In reply to comment #14)
(In reply to comment #13)
What is supposed to be tested? Should the whole test skipped on darwin or
only
the dg-final?
The whole test; the test is verifying that the x86 PIC thunk doesn't have
debug
info, but Darwin doesn't emit that thunk.
Any idea how to disable this on darwin? While...
// { dg-do compile { target { { i?86-*-* || x86_64-*-* } { ! *-*-darwin* } }
} }
parses in dejagnu, the required...
// { dg-do compile { target { { i?86-*-* || x86_64-*-* } { ! *-*-darwin* }
ia32 } } }
doesn't...
ERROR: g++.dg/debug/dwarf2/thunk1.C -std=gnu++98: syntax error in target
selector target i?86-*-* || x86_64-*-*! *-*-darwin*ia32 for
dg-do 2 compile { target { { i?86-*-* || x86_64-*-* } { ! *-*-darwin* } {
ia32 } } }
[Bug c++/56542] New: complex number division underflow on darwin11 without -lm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56542
Bug #: 56542
Summary: complex number division underflow on darwin11 without
-lm
Classification: Unclassified
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pickledeyeb...@gmail.com
Created attachment 29589
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29589
source code, *i file, screen output, compiler flags, etc.
This is similar to (closed) bug 42333 that was for darwin10 + -lm. This bug
report is for darwin11 without the math lib linked in and no apparent complex
number related compiler flags.
x/y where x, y (1e-22,i*a) and x-yeps yields (NaN,NaN) instead of 1.0.
numeric_limitfloat::eps() = 1.17549e-38
The essential operation of complex::operator/ is like this:
(x + i*y) / (a + i*b)
= (x * i*y) * (a - i*b) / [(a + i*b) * (a - i*b)]
= [ (x*a + y*b) + (y*a - x*b) *i ] / (a*a + b*b)
= (x*a + y*b) / ((a*a * b*b) + i * (y*a - x*b) / (a*a + b*b)
It appears that the code is trying to rescale the problem, but the rescale is
failing due to underflow in denominator (and possibly numerator).
The following code demonstrates this bug:
# include iostream
# include complex
# include cstdio
# include numeric
using namespace std;
int main(void)
{
cout endl;
cout endl;
cout === === endl;
cout === Demonstration of division bug in complex numbers === endl;
cout === === endl;
cout endl;
cout endl;
cout limitfloat::min() = numeric_limitsfloat::esp() endl;
float base1 = 1.1754901;
float base2 = 1.1754900;
int largest_good = -22; // largest good exponent
int smallest_bad = -23; // smallest bad exponent
for(int exp=largest_good; exp=smallest_bad; --exp) {
complexfloat x(base1*pow(10.,exp),0) ;
complexfloat y(base2*pow(10.,exp),0) ;
printf(Exponent: %d\n, exp);
printf(x = (%1.7fe%d, i*0)\n, base1, exp);
printf(y = (%1.7fe%d, i*0)\n, base2, exp);
printf(x / y = %1.16e / %1.16e\n, x.real(), y.real());
cout = x / y endl;
cout endl;
}
return 0;
}
It prints out:
=== ===
=== Demonstration of division bug in complex numbers ===
=== ===
limitfloat::eps() = 1.17549e-38
Exponent: -22
x = (1.1754901e-22, i*0)
y = (1.1754900e-22, i*0)
x / y = 1.1754900914587337e-22 / 1.1754899652409888e-22
= (1,0)
Exponent: -23
x = (1.1754901e-23, i*0)
y = (1.1754900e-23, i*0)
x / y = 1.1754901545676061e-23 / 1.1754899967954250e-23
= (nan,nan)
[Bug c++/50276] [C++0x] Wrong used uninitialized in this function warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2013-03-05 17:41:39 UTC --- This seems to have been fixed by one of my lambda patches for 4.8.
[Bug c++/52183] [C++0x] Redeclaration of __this in lambda inside template member function when calling static class function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52183 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/56222] Pointer to member in lambda should not require this to be captured
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56222 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-03-05 17:46:53 UTC --- Related to 51494.
[Bug c++/51494] Legal program rejection - capturing this when using static method inside lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51494 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/56543] New: [4.7.3/4.8 Regression] ICE on valid code in copy_node_stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56543
Bug #: 56543
Summary: [4.7.3/4.8 Regression] ICE on valid code in
copy_node_stat
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@abeckmann.de
The following useless but valid piece of code causes a ICE Segfault in 4.8
(SVN) and 4.7.3 (SVN). It is accepted by 4.6.4 (SVN) and 4.7.2.
= 8 =
template typename struct S ;
template typename T struct U {
typedef typename S T :: template V W ;
S W x;
};
= 8 =
$ g++-trunk -c -v ice-segfault-copy_node_stat.cpp
Using built-in specs.
COLLECT_GCC=/opt/software/x86_64/gcc-trunk/bin/g++-trunk
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/software/x86_64/gcc-trunk
--program-suffix=-trunk --enable-languages=c,c++,fortran --enable-checking
Thread model: posix
gcc version 4.8.0 20130302 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-c' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/opt/software/x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus
-quiet -v -imultilib . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE
ice-segfault-copy_node_stat.cpp -quiet -dumpbase
ice-segfault-copy_node_stat.cpp -mtune=generic -march=x86-64 -auxbase
ice-segfault-copy_node_stat -version -o /tmp/ccZwWTct.s
GNU C++ (GCC) version 4.8.0 20130302 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20130302 (experimental), GMP version
5.0.5, MPFR version 3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu/.
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include
/usr/local/include
/opt/software/x86_64/gcc-trunk/include
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C++ (GCC) version 4.8.0 20130302 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20130302 (experimental), GMP version
5.0.5, MPFR version 3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: eedf9bce273f5c2d2f3e6a014c94ec56
ice-segfault-copy_node_stat.cpp:4:8: internal compiler error: Segmentation
fault
S W x;
^
0xa7da8f crash_signal
../../gcc-trunk/gcc/toplev.c:332
0xc656bd copy_node_stat(tree_node*)
../../gcc-trunk/gcc/tree.c:947
0x6a1819 strip_typedefs(tree_node*)
../../gcc-trunk/gcc/cp/tree.c:1228
0x54b82c canonicalize_type_argument
../../gcc-trunk/gcc/cp/pt.c:6136
0x584e1d coerce_template_parms
../../gcc-trunk/gcc/cp/pt.c:6706
0x586dc8 lookup_template_class_1
../../gcc-trunk/gcc/cp/pt.c:7265
0x586dc8 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc-trunk/gcc/cp/pt.c:7562
0x677fb2 finish_template_type(tree_node*, tree_node*, int)
../../gcc-trunk/gcc/cp/semantics.c:2806
0x611528 cp_parser_template_id
../../gcc-trunk/gcc/cp/parser.c:12710
0x6118c2 cp_parser_class_name
../../gcc-trunk/gcc/cp/parser.c:18109
0x606dbb cp_parser_qualifying_entity
../../gcc-trunk/gcc/cp/parser.c:5275
0x606dbb cp_parser_nested_name_specifier_opt
../../gcc-trunk/gcc/cp/parser.c:5006
0x6077db cp_parser_nested_name_specifier
../../gcc-trunk/gcc/cp/parser.c:5199
0x6173bb cp_parser_using_declaration
../../gcc-trunk/gcc/cp/parser.c:15174
0x5f9d11 cp_parser_member_declaration
../../gcc-trunk/gcc/cp/parser.c:19127
0x5fb036 cp_parser_member_specification_opt
../../gcc-trunk/gcc/cp/parser.c:18990
0x5fb036 cp_parser_class_specifier_1
../../gcc-trunk/gcc/cp/parser.c:18243
0x5fb036 cp_parser_class_specifier
../../gcc-trunk/gcc/cp/parser.c:18459
0x5fb036 cp_parser_type_specifier
../../gcc-trunk/gcc/cp/parser.c:13573
0x6121ed cp_parser_decl_specifier_seq
../../gcc-trunk/gcc/cp/parser.c:10900
Please submit a full bug report,
$
[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
--- Comment #16 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-03-05
18:00:12 UTC ---
Created attachment 29590
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29590
WIP: proposed patch special casing constant phi arguments
Ian.
Sure, I can handle SSA_NAME_VAR equality, but then we won't be able to handle
self referential operations like the one in gcc.dg/Wstrict-overflow-12.c. For
example, with your suggested approach (in this attached patch), we fail here:
for (i = 1, bits = 1; i 0; i += i) /* { dg-warning assuming signed
overflow does not occur correct warning } */
++bits;
Because we encounter something like this which is perfectly valid with your
approach:
i_1 = PHI 1(2), i_4(3)
[Bug web/56544] New: documentation for __cplusplus is out of date
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56544 Bug #: 56544 Summary: documentation for __cplusplus is out of date Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: jist...@redhat.com The Standard Predefined Macros documentation states that __cplusplus is always 1, when in fact it can now be either 199711L or 201103L (thanks to PR1773).
[Bug c++/56545] New: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5790
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56545 Bug #: 56545 Summary: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5790 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ericmartinchristian...@gmail.com What happened: I attempted to compile and got this message: echristiansen@jnu:/wg/stor6_home3/echristiansen/DropboxDontUse/Dropbox/t/2013_q1/salve/build$ make -j12 [ 12%] Built target gtest [ 25%] Built target gtest_main [ 37%] Building CXX object CMakeFiles/runUnitTests.dir/src/testCanBuildFrom.cpp.o /wg/stor6_home3/echristiansen/DropboxDontUse/Dropbox/t/2013_q1/salve/src/testCanBuildFrom.cpp: In constructor ‘constexpr Stringyint::Stringy()’: /wg/stor6_home3/echristiansen/DropboxDontUse/Dropbox/t/2013_q1/salve/src/testCanBuildFrom.cpp:57:8: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5790 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. Preprocessed source stored into /tmp/ccSUtCpb.out file, please attach this to your bugreport. make[2]: *** [CMakeFiles/runUnitTests.dir/src/testCanBuildFrom.cpp.o] Error 1 make[1]: *** [CMakeFiles/runUnitTests.dir/all] Error 2 make: *** [all] Error 2 System: Ubuntu 12.10 x64 Preprocessed source: Attached
[Bug web/56544] documentation for __cplusplus is out of date
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56544 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-05 Version|unknown |4.7.3 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-05 18:37:27 UTC --- confirmed
[Bug c++/56545] internal compiler error: in build_data_member_initialization, at cp/semantics.c:5790
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56545 --- Comment #1 from Eric Christiansen ericmartinchristiansen at gmail dot com 2013-03-05 18:42:04 UTC --- Created attachment 29591 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29591 preprocessed source
[Bug c++/50276] [C++0x] Wrong used uninitialized in this function warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2013-03-05 18:58:41 UTC --- Author: jason Date: Tue Mar 5 18:58:36 2013 New Revision: 196472 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196472 Log: PR c++/50276 * g++.dg/cpp0x/lambda/lambda-template10.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template10.C
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org 2013-03-05 19:01:18 UTC --- If it's easier to just disable the dg-final, that's fine too.
[Bug c++/56545] internal compiler error: in build_data_member_initialization, at cp/semantics.c:5790
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56545
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de
2013-03-05 19:03:01 UTC ---
Probably dup of Bug 54126.
Reduced:
templatetypenamestruct StringyInterface
{};
templatetypenamestruct StringyImplementation;
templatestruct StringyImplementationint: StringyInterfaceint
{};
templatetypename Astruct Stringy
{
const StringyInterfaceA verifyConforms =
StringyImplementationA();
};
void
fn1()
{
Stringyint().verifyConforms;
}
