[Bug c++/56291] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

2013-02-11 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291 Paolo Carlini changed: What|Removed |Added CC|freddie_chopin at op dot pl | --- Comment #1 from Paolo Carl

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

2013-02-11 Thread ppluzhnikov at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265 --- Comment #3 from Paul Pluzhnikov 2013-02-12 00:48:01 UTC --- Thanks for the fix. We've confirmed that this fix also fixes the crash in "irreducible" test case from PR56262.

[Bug middle-end/56231] warning traces have bogus line information when using LTO

2013-02-11 Thread matt at use dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231 --- Comment #11 from Matt Hargett 2013-02-12 01:55:28 UTC --- can you add the reduced test case you came up with to the testsuite? I've seen these issues come and go at various points.

[Bug middle-end/56231] warning traces have bogus line information when using LTO

2013-02-11 Thread matt at use dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231 --- Comment #12 from Matt Hargett 2013-02-12 02:02:33 UTC --- looking at the patch for merging elsewhere, I noticed that location_t lto_input_location (struct bitpack_d *bp, struct data_in *data_in) { + static const char *current_f

[Bug target/55431] Invalid auxv search in ppc linux-unwind code.

2013-02-11 Thread amodra at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 --- Comment #5 from Alan Modra 2013-02-12 03:04:28 UTC --- Created attachment 29420 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29420 use /proc/self/auxv At the time the original code was being developed, linux-2.4.x was in wid

[Bug target/56263] [avr] Provide strict address-space checking

2013-02-11 Thread demiurg_spb at freemail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263 --- Comment #3 from demiurg_spb at freemail dot ru 2013-02-12 06:47:43 UTC --- (In reply to comment #2) > This cannot work because ISO/IEC TR18037 forces these literals into generic > space. > ISO/IEC TR18037 5.1.2 Address-space type

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

2013-02-11 Thread kcc at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #32 from Kostya Serebryany 2013-02-12 06:47:56 UTC --- Good news, 0x7fff8000 seems great: t0: orig t1: short offset (0x7fff8000) t2: zero offset + pie t0 t1 t1/t0 t2t2/t0 t2/t1 ---

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

2013-02-11 Thread kcc at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #33 from Kostya Serebryany 2013-02-12 07:02:40 UTC --- (In reply to comment #31) > If the mapping is so flexible, how can you detect mismatches? Different scale > or shadow offsets are ABI incompatible... We don't detect mism

[Bug target/55431] Invalid auxv search in ppc linux-unwind code.

2013-02-11 Thread bugdal at aerifal dot cx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 --- Comment #6 from Rich Felker 2013-02-12 07:08:14 UTC --- That sounds highly doubtful. The sigcontext is (necessarily) on the stack, so the only way accessing past the end of sigcontext could fault is if the access were so far beyond the

[Bug c++/56291] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

2013-02-11 Thread freddie_chopin at op dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291 --- Comment #2 from Freddie Chopin 2013-02-12 07:14:17 UTC --- Created attachment 29421 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29421 failing test case

[Bug c++/56291] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821

2013-02-11 Thread freddie_chopin at op dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291 Freddie Chopin changed: What|Removed |Added CC||freddie_chopin at op dot pl --

<    1   2