[Bug c++/56543] [4.7/4.8 Regression] ICE on valid code in copy_node_stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56543 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2013-03-06 07:45:02 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196228 aka PR56395.
[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 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek 2013-03-06 07:23:21 UTC --- I'd say this started with http://gcc.gnu.org/viewcvs?view=revision&revision=151935
[Bug middle-end/56526] [4.8 regression] false positive for maybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526 --- Comment #5 from Jakub Jelinek 2013-03-06 07:03:23 UTC --- Maybe-uninitialized warnings have tons of known false positives, while the predicated analysis can handle the simplest cases, it can't handle anything more complicated. As this isn't a usable testcase, requires LTO to reproduce, I don't think it is worth keeping it open.
[Bug lto/50293] -flto fails if GCC is installed in directory with space in path name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50293 --- Comment #3 from jye2 at gcc dot gnu.org 2013-03-06 06:32:15 UTC --- Author: jye2 Date: Wed Mar 6 06:32:03 2013 New Revision: 196485 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196485 Log: 2013-03-06 Joey Ye PR lto/50293 * gcc.c (convert_white_space): New function. (main): Handles white space in function name. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c
[Bug middle-end/56526] [4.8 regression] false positive for maybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526 --- Comment #4 from Matt Hargett 2013-03-06 02:06:03 UTC --- It does fix that warning, but there's a bug in the analysis that makes it a false positive. I've had difficulty reducing it to a self-contained example, and I don't have the expertise to do more in-depth debugging. This should stay open until the analysis is done to show that it's an accepted limitation of the warning's capabilities, IMO.
[Bug target/40797] [4.6/4.7/4.8 Regression] ICE in df_refs_verify, at df-scan.c:4361
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797 --- Comment #13 from Kazumoto Kojima 2013-03-06 01:08:19 UTC --- (In reply to comment #12) > I'd like to add a test case to the test suite for this PR first, if that's OK. Sounds good idea.
[Bug target/55295] [SH] Add support for fipr instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295 --- Comment #7 from Oleg Endo 2013-03-06 01:05:14 UTC --- (In reply to comment #5) > > > > 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. > I've opened a new PR 56547 for this issue.
[Bug target/56547] New: [SH] missed opportunity for fmac with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56547
Bug #: 56547
Summary: [SH] missed opportunity for fmac with -ffast-math
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
This one was mentioned in PR 55295:
float test (float a, float b)
{
return a * b + a;
}
compiled with -m4-single -O2 -ffast-math results in:
fldi1 fr0 ! 7 movsf_ie/4 [length = 2]
faddfr5,fr0 ! 8 addsf3_i[length = 2]
rts ! 27*return_i [length = 2]
fmulfr4,fr0 ! 9 mulsf3_i[length = 2]
At least on SH using fmac in this case would be better than transforming
'a * b + a' into '(1 + b) * a'. Not sure yet whether this is actually target
specific.
[Bug target/40797] [4.6/4.7/4.8 Regression] ICE in df_refs_verify, at df-scan.c:4361
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797 --- Comment #12 from Oleg Endo 2013-03-06 00:54:36 UTC --- (In reply to comment #11) > I've tried current 4.6/4.7/4.8 with --enable-checking=df on sh4-linux > and found that the ice has gone for both original and reduced test cases. > I'd like to close this PR unless new test case pops up. I'd like to add a test case to the test suite for this PR first, if that's OK.
[Bug target/40797] [4.6/4.7/4.8 Regression] ICE in df_refs_verify, at df-scan.c:4361
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797 --- Comment #11 from Kazumoto Kojima 2013-03-06 00:45:48 UTC --- I've tried current 4.6/4.7/4.8 with --enable-checking=df on sh4-linux and found that the ice has gone for both original and reduced test cases. I'd like to close this PR unless new test case pops up.
[Bug target/56529] [SH] Calls to __sdivsi3_i4i and __udivsi3_i4i are generated on SH2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56529 --- Comment #3 from Oleg Endo 2013-03-06 00:41:33 UTC --- Author: olegendo Date: Wed Mar 6 00:41:25 2013 New Revision: 196484 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196484 Log: PR target/56529 * config/sh/sh.c (sh_option_override): Check for TARGET_DYNSHIFT instead of TARGET_SH2 for call-table case. Do not set sh_div_strategy to SH_DIV_CALL_TABLE for TARGET_SH2. * config.gcc (sh_multilibs): Add m2 and m2a to sh*-*-linux* multilib list. * doc/invoke.texi (SH options): Document mdiv= call-div1, call-fp, call-table options. PR target/56529 * config/sh/lib1funcs.S (udivsi3_i4i, sdivsi3_i4i): Add __SH2A__ to inclusion list. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/sh/sh.c trunk/gcc/doc/invoke.texi trunk/libgcc/ChangeLog trunk/libgcc/config/sh/lib1funcs.S
[Bug target/55181] [4.7/4.8 Regression] Expensive shift loop where a bit-testing instruction could be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181
Steven Bosscher changed:
What|Removed |Added
Target|avr |
CC||steven at gcc dot gnu.org
--- Comment #5 from Steven Bosscher 2013-03-05
23:45:38 UTC ---
At trunk r196410, the .164t.optimized dump looks like this:
lfsr (long unsigned int number)
{
unsigned char b;
long unsigned int _4;
long unsigned int _5;
_Bool _8;
:
_4 = number_3(D) & 536870912;
_8 = _4 != 0;
b_10 = (unsigned char) _8;
_5 = number_3(D) & 8192;
if (_5 != 0)
goto ;
else
goto ;
:
b_6 = b_10 + 1;
:
# b_2 = PHI
return b_2;
}
and exact_log2 could be used to identify the and-instruction as
a bit test instruction:
(gdb) p exact_log2(536870912)
$1 = 29
(gdb)
AFAIK there are no named patterns for bit tests, perhaps there should be.
(http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html#Standard-Names)
So at least on x86_64 the test gets expanded as a shift:
6: {r65:DI=r64:DI 0>>0x1d;clobber flags:CC;}
7: {r59:QI=r65:DI#0&0x1;clobber flags:CC;}
8: {r66:DI=r64:DI&0x2000;clobber flags:CC;}
9: flags:CCZ=cmp(r66:DI,0)
i.e. also far from optimal.
[Bug rtl-optimization/47270] [4.6/4.7/4.8 Regression] GCC produces unnecessary code on -O2 and -O3 levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47270 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-05 Ever Confirmed|0 |1 --- Comment #4 from Steven Bosscher 2013-03-05 23:28:58 UTC --- (In reply to comment #1) > and RTL optimizations aren't able to undo that. I doubt anything can > be done about this easily. Perhaps tree-ssa-uncprop should handle this. FWIW, I've always thought that constant propagation into PHI arguments was a mistake...
[Bug middle-end/49319] [4.7 regression] g++.dg/abi/thunk5.C FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49319 Steven Bosscher changed: What|Removed |Added Summary|[4.7/4.8 regression]|[4.7 regression] |g++.dg/abi/thunk5.C FAILs |g++.dg/abi/thunk5.C FAILs |on Tru64 UNIX |on Tru64 UNIX --- Comment #8 from Steven Bosscher 2013-03-05 23:24:25 UTC --- GCC 4.8 does not support Tru64 anymore.
[Bug target/40797] [4.6/4.7/4.8 Regression] ICE in df_refs_verify, at df-scan.c:4361
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797 Steven Bosscher changed: What|Removed |Added Component|rtl-optimization|target --- Comment #10 from Steven Bosscher 2013-03-05 23:22:58 UTC --- Since nobody else seems to run into any of these problems (including the valgrind failures) this is almost certainly an SH target bug.
[Bug objc/39753] [4.6/4.7/4.8 Regression] Objective-C(++) and C90 strict-aliasing interaction bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753 Steven Bosscher changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #18 from Steven Bosscher 2013-03-05 23:16:58 UTC --- In WAITING mode since 2011-03-19 06:13:31 UTC No test case. => INVALID
[Bug debug/55364] ICE: in remove_addr_table_entry, at dwarf2out.c:4201 with -O -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55364 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Cary Coutant 2013-03-05 23:11:53 UTC --- Fixed at r196480.
[Bug debug/55364] ICE: in remove_addr_table_entry, at dwarf2out.c:4201 with -O -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55364 --- Comment #2 from Cary Coutant 2013-03-05 23:08:52 UTC --- Author: ccoutant Date: Tue Mar 5 23:08:45 2013 New Revision: 196480 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196480 Log: gcc/ PR debug/55364 * dwarf2out.c (resolve_addr): Don't call remove_loc_list_addr_table_entries a second time for the same expression. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug debug/56510] [4.7 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 Jakub Jelinek changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression] More |[4.7 Regression] More |var-tracking scalability|var-tracking scalability |problems|problems Known to fail|4.8.0 | --- Comment #15 from Jakub Jelinek 2013-03-05 22:35:30 UTC --- Fixed for trunk so far.
[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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Jakub Jelinek 2013-03-05 22:34:19 UTC --- Fixed.
[Bug debug/56510] [4.7/4.8 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 --- Comment #14 from Jakub Jelinek 2013-03-05 22:31:56 UTC --- Author: jakub Date: Tue Mar 5 22:31:50 2013 New Revision: 196479 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196479 Log: PR debug/56510 * cfgexpand.c (expand_debug_parm_decl): Call copy_rtx on incoming. (avoid_complex_debug_insns): New function. (expand_debug_locations): Call it. * gcc.dg/pr56510.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr56510.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog
[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 --- Comment #9 from Jakub Jelinek 2013-03-05 22:25:50 UTC --- Author: jakub Date: Tue Mar 5 22:25:43 2013 New Revision: 196478 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196478 Log: PR rtl-optimization/56484 * ifcvt.c (noce_process_if_block): If else_bb is NULL, avoid extending lifetimes of hard registers on small register class machines. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr56484.c Modified: trunk/gcc/ifcvt.c
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #17 from Jack Howarth 2013-03-05 22:20:33 UTC --- (In reply to comment #16) > If it's easier to just disable the dg-final, that's fine too. Patch posted at http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00210.html. Can you commit it?
[Bug target/56546] New: Using the divide operator on unsigned int produces incorrect code on AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56546 Bug #: 56546 Summary: Using the divide operator on unsigned int produces incorrect code on AVR Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: k...@free.fr Created attachment 29592 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29592 Sample code to reproduce the issue Using the divide integer on unsigned int variables on an AVR target leads to wrong code being generated. The generated code uses the __umulhisi3 routine from libgcc which is a multiplication routine and the result is always zero. As I'm willing to increase my knowledge about the inner workings of gcc, I tried to start debugging it myself. I found (using -fdump-rtl-all) that the issue was occurring in the RTL part of the compiler where the udiv was at several point transformed into a mult. I tried disabling the first pass that did the transformation (-fdisable-rtl-fwprop1) and the udiv was propagated a little further in the process until the ira pass. I then tried to disable the ira pass using -fdisable-rtl-ira, made gcc crash and discovered it was a really stupid thing to do (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56514). So here I am again but his time leaving compiler debugging to the compiler guys :-) I've come up with a very simple source file that allows to reproduce the issue. By the way I couldn't think of any case where transforming a udiv into a mult operating on integers would make sense and would be glad if someone could give me some hints on this. Here's the command line I used: avr-gcc -O0 -g -Wall -Wextra -save-temps -mmcu=atmega8 -o main.elf main.c And the version of the toolchain components: binutils: efb7cff2df30eb792d30e8afc384aa88c193932b gcc: ef11013858b41453c4953ca8d4c25e3b1668e536 avr-libc: 2ac01d285e23894ef3bcc65c75b39da8157b9fd9 gcc-4.7.2, binutils 2.23.1 and avr-libc 1.8.0 give the same result.
[Bug debug/55364] ICE: in remove_addr_table_entry, at dwarf2out.c:4201 with -O -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55364 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ccoutant at gcc dot gnu.org |gnu.org |
[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 Vincent changed: What|Removed |Added CC||vchou79 at gmail dot com --- Comment #4 from Vincent 2013-03-05 21:14:04 UTC --- bash-4.1$ x86_64-w64-mingw32-gcc -O2 t.c t.c: In function 'main': t.c:9:5: internal compiler error: Segmentation fault int main() ^ 0x71fa65 crash_signal ../../gcc-4_8-trunk/gcc/toplev.c:332 0x748617 ssa_default_def(function*, tree_node*) ../../gcc-4_8-trunk/gcc/tree-dfa.c:310 0x748688 get_or_create_ssa_default_def(function*, tree_node*) ../../gcc-4_8-trunk/gcc/tree-dfa.c:362 0x760f7c get_reaching_def ../../gcc-4_8-trunk/gcc/tree-into-ssa.c:1155 0x76364b maybe_replace_use ../../gcc-4_8-trunk/gcc/tree-into-ssa.c:1772 0x76364b rewrite_update_stmt ../../gcc-4_8-trunk/gcc/tree-into-ssa.c:1955 0x76364b rewrite_update_enter_block ../../gcc-4_8-trunk/gcc/tree-into-ssa.c:2124 0xab5380 walk_dominator_tree(dom_walk_data*, basic_block_def*) ../../gcc-4_8-trunk/gcc/domwalk.c:187 0x761183 rewrite_blocks ../../gcc-4_8-trunk/gcc/tree-into-ssa.c:2204 0x7669bc update_ssa(unsigned int) ../../gcc-4_8-trunk/gcc/tree-into-ssa.c:3283 0xb371a4 tree_unroll_loops_completely(bool, bool) ../../gcc-4_8-trunk/gcc/tree-ssa-loop-ivcanon.c:1175 0x7d4c92 tree_complete_unroll_inner ../../gcc-4_8-trunk/gcc/tree-ssa-loop.c:511 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. gcc version 4.8.0 20130305 (experimental) [gcc-4_8-trunk revision 196448]
[Bug c++/56506] variadic class template specialization not selected as best match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56506 --- Comment #4 from Daniel Krügler 2013-03-05 20:18:00 UTC --- (In reply to comment #3) Presumably my judgment was a bit premature and I think there is a logical flaw in my original argumentation: I think I misinterpreted 14.5.3 p5. I'm switching to observer-mode, but your examples are quite interesting because every compiler with variadic template support that I have access to rejects them. This seems to indicate some possible unforeseen case in existing models. I have forwarded this to the core language group.
[Bug c++/51884] lambda with templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51884
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #6 from Jason Merrill 2013-03-05
20:07:20 UTC ---
Slightly reduced again. Note that this testcase uses a normal local class
rather than a lambda; the only C++11 feature it uses is local types as template
arguments.
template struct is_same { static const int value = 0; };
template struct enable_if {
typedef void type;
};
struct thread {
struct _Impl_base {
virtual void _M_run();
};
template
struct _Impl : _Impl_base { };
template
thread(const _Callable& __f) {
_M_start_thread(_M_make_routine(__f));
}
template
_Impl<_Callable> _M_make_routine(const _Callable& __f);
};
template struct foo;
template struct foo::value>::type>
{
template void bar() const {
struct A { } a;
thread thr(a);
}
};
int main() {
foo f;
f.bar();
}
[Bug c++/55856] [4.7/4.8 Regression] ICE on tuple with rvalue ref member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55856 Paolo Carlini changed: What|Removed |Added CC||ericmartinchristiansen at ||gmail dot com --- Comment #7 from Paolo Carlini 2013-03-05 19:30:50 UTC --- *** Bug 56545 has been marked as a duplicate of this bug. ***
[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 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Paolo Carlini 2013-03-05 19:30:50 UTC --- Found it. *** This bug has been marked as a duplicate of bug 55856 ***
[Bug debug/55328] ICE: in output_addr_table_entry, at dwarf2out.c:21780 with -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55328 Cary Coutant changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ccoutant at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Cary Coutant 2013-03-05 19:27:27 UTC --- Fixed at r193515.
[Bug c++/55357] -Wshadow warns about lambda function parameters matching variables in outer scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55357 Jason Merrill changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-05 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jason Merrill 2013-03-05 19:25:34 UTC --- (In reply to comment #0) > I can't decide if this is correct behavior for the warning. It would catch > errors caused by people thinking they were using the outer variables by simply > disallowing overlap, which is good. I think it's appropriate to warn here; whether or not there is a default capture seems like a subtle distinction that is easy to miss when reading the code. > I also note that gcc warns me about the first line the lambda appears on (line > 3) and the last line (line 5). That's a bug.
[Bug c++/56543] [4.7/4.8 Regression] ICE on valid code in copy_node_stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56543 Paolo Carlini changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-05 Target Milestone|--- |4.7.3 Summary|[4.7.3/4.8 Regression] ICE |[4.7/4.8 Regression] ICE on |on valid code in|valid code in |copy_node_stat |copy_node_stat Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2013-03-05 19:19:26 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 #3 from Paolo Carlini 2013-03-05 19:11:38 UTC --- Both the reduced testcase and the original one works fine with current mainline and 4_7-branch for me. Thus I don't think this is a Dup of 54126, I think it can be closed.
[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 changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #2 from Markus Trippelsdorf
2013-03-05 19:03:01 UTC ---
Probably dup of Bug 54126.
Reduced:
templatestruct StringyInterface
{};
templatestruct StringyImplementation;
template<>struct StringyImplementation: StringyInterface
{};
templatestruct Stringy
{
const StringyInterface& verifyConforms =
StringyImplementation();
};
void
fn1()
{
Stringy().verifyConforms;
}
[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 2013-03-05 19:01:18 UTC --- If it's easier to just disable the dg-final, that's fine too.
[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 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=gcc&view=rev&rev=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 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 2013-03-05 18:42:04 UTC --- Created attachment 29591 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29591 preprocessed source
[Bug web/56544] documentation for __cplusplus is out of date
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56544 Jonathan Wakely 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 2013-03-05 18:37:27 UTC --- confirmed
[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 Stringy::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 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] 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 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 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 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 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 changed: What|Removed |Added Status|NEW |ASSIGNED 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 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 2013-03-05 17:46:53 UTC --- Related to 51494.
[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 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++/50276] [C++0x] Wrong "used uninitialized in this function" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Jason Merrill 2013-03-05 17:41:39 UTC --- This seems to have been fixed by one of my lambda patches for 4.8.
[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-y>eps yields (NaN,NaN) instead of 1.0.
numeric_limit::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
# include
# include
# include
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 << "limit::min() = " << numeric_limits::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) {
complex x(base1*pow(10.,exp),0) ;
complex 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 ===
=== ===
limit::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 debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363
--- Comment #15 from Jack Howarth 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 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 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 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
#include
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 = (rR0) ? rMin : rBig+std::abs(z[i]); // this vectorize (sic...)
rMin = (rMax>0) ? rMin : rBig; // comment to vectorize
rMin = (rMin>0) ? rMin : rMax;
ok[i] = rMin-c(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_EXPR(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 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 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 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 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-05 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini 2013-03-05 16:36:42 UTC --- Must be easy to fix.
[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 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 2013-03-05 16:34:13 UTC --- Confirmed.
[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 --- Comment #2 from Jonathan Wakely 2013-03-05 16:27:50 UTC --- N.B. -O3 is needed to trigger the bug with 4.5.2
[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 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 2013-03-05 16:24:59 UTC --- 4.4.3 is OK, 4.5.2 fails the asertion
[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 2013-03-05 16:24:35 UTC --- Created attachment 29588 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29588 reduced testcase
[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 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 2013-03-05 16:23:34 UTC --- Confirmed.
[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
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 for instructions.
Using -fno-optimize-sibling-calls makes the bug go away for all versions.
[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 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 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 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=gcc&view=rev&rev=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 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 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=gcc&view=rev&rev=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 #32 from Jakub Jelinek 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=gcc&view=rev&rev=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 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 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 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 debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #14 from Jason Merrill 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 #32 from Eric Botcazou 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 middle-end/56526] [4.8 regression] false positive for maybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Jakub Jelinek 2013-03-05 15:22:39 UTC --- Should be fixed hopefully.
[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 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=gcc&view=rev&rev=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 tree-optimization/56521] [4.8 Regression] Uninitialized value_id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56521 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Biener 2013-03-05 15:13:13 UTC --- Fixed.
[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 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 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
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 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 tree-optimization/56521] [4.8 Regression] Uninitialized value_id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56521 --- Comment #3 from Richard Biener 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=gcc&view=rev&rev=196465 Log: 2013-03-05 Richard Biener 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 debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #12 from Jack Howarth 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 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 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 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 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 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=gcc&view=rev&rev=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/56533] Linker problem on avr with lto and main function inside archive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 Matthijs Kooijman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Matthijs Kooijman 2013-03-05 14:40:15 UTC --- w00ps, didn't mean to change the resolution.
[Bug c++/55786] g++ segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55786 Andreas Beckmann changed: What|Removed |Added CC||gcc at abeckmann dot de --- Comment #1 from Andreas Beckmann 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 Foo>::template Baz ^ /tmp/bug.cpp:8:30: internal compiler error: Segmentation fault struct Foo>::template Baz ^ 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 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 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 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 changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #5 from Matthijs Kooijman 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 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
#include
#include
int main() {
const int jobs=8;
pid_t pid[jobs];
std::shared_ptr p(new int());
for (int job=0;job q(p);
_exit(0);
}
for (int job=0;job
[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
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
> 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
> > 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 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 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 debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 Jason Merrill changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #11 from Jason Merrill 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 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 changed: What|Removed |Added CC||Martin.vGagern at gmx dot ||net --- Comment #4 from Martin von Gagern 2013-03-05 14:10:14 UTC --- *** Bug 56537 has been marked as a duplicate of this bug. ***
[Bug c++/56537] [C++11] lambda expression treats members as const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56537 Martin von Gagern changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Martin von Gagern 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++/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
template struct Foo {
std::vector member;
Foo() {
auto f = [this]() {
#if 0
this->
#endif
member.push_back(42);
};
};
};
void bar() { Foo foo; }
The compiler reports:
foo.cc: In lambda function:
foo.cc:9:26: error: no matching function for call to
‘std::vector::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::allocator; std::vector<_Tp, _Alloc>::value_type = int]
…/4.7.2/include/g++-v4/bits/stl_vector.h:881:7: note: no known conversion for
implicit ‘this’ parameter from ‘const std::vector*’ to ‘std::vector*’
…/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::allocator; std::vector<_Tp, _Alloc>::value_type = int]
…/4.7.2/include/g++-v4/bits/stl_vector.h:899:7: note: no known conversion for
implicit ‘this’ parameter from ‘const std::vector*’ to ‘std::vector*’
But the "this" parameter in this case is a "Foo* const", not a "const
std::vector*". 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 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
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 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 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 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/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 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 debug/56510] [4.7/4.8 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 Jakub Jelinek 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 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 debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #10 from Jack Howarth 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/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #9 from Jack Howarth 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 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 changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |4.7.3
[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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Richard Biener 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 --- Comment #1 from Paolo Carlini 2013-03-05 13:31:14 UTC --- Looks like a Dup of PR55786.
[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 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] 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)
[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 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
