[Bug c++/53846] [c++11] memory exhaustion on simple recursive function template that uses decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53846 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-07-04 06:43:20 UTC --- Same problem with gcc 4.8.0 20120624 (experimental)
[Bug middle-end/53849] New: [4.8 Regression] ICE: in add_referenced_var_1, at tree-dfa.c:567 with -O2 -ftree-parallelize-loops=2 -fno-tree-loop-im
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53849 Bug #: 53849 Summary: [4.8 Regression] ICE: in add_referenced_var_1, at tree-dfa.c:567 with -O2 -ftree-parallelize-loops=2 -fno-tree-loop-im Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 27740 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27740 reduced testcase Compiler output: $ gcc -O2 -ftree-parallelize-loops=2 -fno-tree-loop-im testcase.c testcase.c: In function 'foo': testcase.c:8:11: internal compiler error: in add_referenced_var_1, at tree-dfa.c:567 while (--d) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x122de40 /mnt/svn/gcc-trunk/gcc/tree-dfa.c, line=567, function=0x122e0a0 add_referenced_var_1) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:1010 #1 0x00a240c7 in add_referenced_var_1 (var=0x76cf11e0, fn=optimized out) at /mnt/svn/gcc-trunk/gcc/tree-dfa.c:565 #2 0x00a083d2 in move_stmt_op (tp=0x76e22020, walk_subtrees=0x7fffccac, data=optimized out) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:6032 #3 0x00be8b5c in walk_tree_1 (tp=0x76e22020, func=0xa08200 move_stmt_op(tree*, int*, void*), data=0x7fffcf20, pset=0x0, lh=0) at /mnt/svn/gcc-trunk/gcc/tree.c:10572 #4 0x00be92f9 in walk_tree_1 (tp=0x76e0c410, func=0xa08200 move_stmt_op(tree*, int*, void*), data=0x7fffcf20, pset=0x0, lh=0) at /mnt/svn/gcc-trunk/gcc/tree.c:10828 #5 0x0081fc06 in walk_gimple_op (stmt=0x76e0c3c0, callback_op=0xa08200 move_stmt_op(tree*, int*, void*), wi=0x7fffcf20) at /mnt/svn/gcc-trunk/gcc/gimple.c:1463 #6 0x0081ffed in walk_gimple_stmt (gsi=0x7fffcf00, callback_stmt=0xa0e730 move_stmt_r(gimple_stmt_iterator*, bool*, walk_stmt_info*), callback_op=0xa08200 move_stmt_op(tree*, int*, void*), wi=0x7fffcf20) at /mnt/svn/gcc-trunk/gcc/gimple.c:1757 #7 0x00a18186 in move_block_to_fn (d=0x7fffcf60, update_edge_count_p=optimized out, after=optimized out, bb=optimized out, dest_cfun=0x76e300a0) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:6263 #8 move_sese_region_to_fn (dest_cfun=0x76e300a0, entry_bb=optimized out, exit_bb=optimized out, orig_block=optimized out) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:6551 #9 0x008e4d4b in expand_omp_taskreg (region=0x18dbae0) at /mnt/svn/gcc-trunk/gcc/omp-low.c:3570 #10 0x008e60c8 in expand_omp (region=0x18dbae0) at /mnt/svn/gcc-trunk/gcc/omp-low.c:5598 #11 0x008ef311 in omp_expand_local (head=optimized out) at /mnt/svn/gcc-trunk/gcc/omp-low.c:5735 #12 0x00a6f0a6 in gen_parallel_loop (n_threads=optimized out, reduction_list=optimized out, loop=0x0, niter=optimized out) at /mnt/svn/gcc-trunk/gcc/tree-parloops.c:1888 #13 parallelize_loops () at /mnt/svn/gcc-trunk/gcc/tree-parloops.c:2210 #14 0x00afeb07 in tree_parallelize_loops () at /mnt/svn/gcc-trunk/gcc/tree-ssa-loop.c:545 #15 0x0090c7d5 in execute_one_pass (pass=0x1759040) at /mnt/svn/gcc-trunk/gcc/passes.c:2165 #16 0x0090cb95 in execute_pass_list (pass=0x1759040) at /mnt/svn/gcc-trunk/gcc/passes.c:2220 #17 0x0090cba7 in execute_pass_list (pass=0x1759580) at /mnt/svn/gcc-trunk/gcc/passes.c:2221 #18 0x0090cba7 in execute_pass_list (pass=0x1756ae0) at /mnt/svn/gcc-trunk/gcc/passes.c:2221 #19 0x006b7f98 in expand_function (node=0x76cef750) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1615 #20 0x006b9d74 in expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1720 #21 compile () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2018 #22 0x006ba335 in finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2095 #23 0x0059bb10 in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c/c-decl.c:10116 #24 0x009f6ff5 in compile_file () at /mnt/svn/gcc-trunk/gcc/toplev.c:564 #25 0x009f8b98 in do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1867 #26 toplev_main (argc=16, argv=0x7fffd6b8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1943 #27 0x76f052ad in __libc_start_main () from /lib64/libc.so.6 #28 0x0057ef11 in _start () Tested revisions: r189246 - crash 4.7 r188682 - OK 4.6 r188682 - OK
[Bug middle-end/53850] New: [4.8 Regression] ICE: in expand_call_tm, at trans-mem.c:2289 with -fgnu-tm -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53850 Bug #: 53850 Summary: [4.8 Regression] ICE: in expand_call_tm, at trans-mem.c:2289 with -fgnu-tm -O3 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 27741 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27741 reduced testcase Compiler flags: -fgnu-tm -O3 or -fgnu-tm -O2 -ftree-loop-distribute-patterns Compiler output: $ gcc -fgnu-tm -O2 -ftree-loop-distribute-patterns testcase.c testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: in expand_call_tm, at trans-mem.c:2289 foo (void) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x12277d0 /mnt/svn/gcc-trunk/gcc/trans-mem.c, line=2289, function=0x1228230 expand_call_tm) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:1010 #1 0x00a02b6a in expand_call_tm (gsi=0x7fffd410, region=0x194b820) at /mnt/svn/gcc-trunk/gcc/trans-mem.c:2289 #2 expand_block_tm (bb=optimized out, region=0x194b820) at /mnt/svn/gcc-trunk/gcc/trans-mem.c:2379 #3 execute_tm_mark () at /mnt/svn/gcc-trunk/gcc/trans-mem.c:2519 #4 0x0090c7d5 in execute_one_pass (pass=0x1757ac0) at /mnt/svn/gcc-trunk/gcc/passes.c:2165 #5 0x0090cb95 in execute_pass_list (pass=0x1757ac0) at /mnt/svn/gcc-trunk/gcc/passes.c:2220 #6 0x0090cba7 in execute_pass_list (pass=0x1757b20) at /mnt/svn/gcc-trunk/gcc/passes.c:2221 #7 0x006b7f98 in expand_function (node=0x76cef750) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1615 #8 0x006b9d74 in expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1720 #9 compile () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2018 #10 0x006ba335 in finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2095 #11 0x0059bb10 in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c/c-decl.c:10116 #12 0x009f6ff5 in compile_file () at /mnt/svn/gcc-trunk/gcc/toplev.c:564 #13 0x009f8b98 in do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1867 #14 toplev_main (argc=16, argv=0x7fffd6c8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1943 #15 0x76f052ad in __libc_start_main () from /lib64/libc.so.6 #16 0x0057ef11 in _start () Tested revisions: r189246 - crash 4.7 r188682 - OK
[Bug c++/53826] [4.8 Regression] [alpha]: ICE in fold_convert_loc, at fold-const.c:2008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53826 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-07/msg00105.htm ||l Resolution||FIXED --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2012-07-04 07:29:44 UTC --- (In reply to comment #3) Should be fixed now. Yes, the patch fixes the testsuite failure [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg00319.html
[Bug middle-end/53850] [4.8 Regression] ICE: in expand_call_tm, at trans-mem.c:2289 with -fgnu-tm -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53850 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/53849] [4.8 Regression] ICE: in add_referenced_var_1, at tree-dfa.c:567 with -O2 -ftree-parallelize-loops=2 -fno-tree-loop-im
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53849 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-04 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 09:19:53 UTC --- Mine.
[Bug c++/53848] [4.8 regression] ICE in decl_linkage at ../../gcc-trunk/gcc/cp/tree.c:3215
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53848 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |c++ Target Milestone|--- |4.8.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 09:21:00 UTC --- Backtrace is from the C++ frontend.
[Bug c++/53707] compiler generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53707 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 09:22:10 UTC --- Invalid.
[Bug bootstrap/53675] [4.8 Regression] bootstrap fails on non-TLS targets with multiple definitions of libstdc++ symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53675 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-04 09:22:58 UTC --- I'm still seeing junk dwarf info: /usr/bin/ld: Dwarf Error: found dwarf version '0', this reader only handles version 2 and 3 information. 2.cc:(.text._Z6test01v+0x73): undefined reference to `std::chrono::steady_clock::now()' /usr/bin/ld: Dwarf Error: found dwarf version '12425', this reader only handles version 2 and 3 information. 2.cc:(.text._Z6test01v+0xe1): undefined reference to `std::chrono::steady_clock::now()' collect2: error: ld returned 1 exit status Will investigate ...
[Bug target/53842] avr second write to volatile register gets dropped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53842 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-04 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 09:26:55 UTC --- I belive this has been fixed for 4.7.1, please double-check.
[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||andi-gcc at firstfloor dot ||org --- Comment #20 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 09:27:53 UTC --- (In reply to comment #19) (In reply to comment #18) The testcase is fixed when using -fno-fat-lto-objects and gcc-ar For me x64_64-linux version works if I use gcc-ar (both with and without -fno-fat-lto-objects). (which is not required, or should not be required(?) for -ffat-lto-objects?) No idea, today is the first time I hear about gcc-nm/ar. Are there any online docs? Are users supposed to create LTO archives with gcc-ar instead of good ol' ar these days? Good question, even I am not sure. This is an area that could have documentation. Honza, Andi, can you clarify?
[Bug c++/53846] [c++11] memory exhaustion on simple recursive function template that uses decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53846 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-04 Ever Confirmed|0 |1 Known to fail||4.4.7, 4.5.4, 4.6.3, 4.7.1, ||4.8.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 09:31:15 UTC --- Confirmed, fails this way since forever.
[Bug tree-optimization/53844] [4.6/4.7 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Component|middle-end |tree-optimization AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 09:34:59 UTC --- With the alias-oracle in place DCE can no longer see this (the temporaries have their address taken). DSE should be able to, but it seems it does not. Investigating.
[Bug tree-optimization/53844] [4.6/4.7 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844 --- Comment #4 from Edward Rosten ed at edrosten dot com 2012-07-04 09:42:52 UTC --- It doesn't seem to do with the address, entirely. It still pushes the values onto the stack even if the class is changed to have a const int, rather than const int.
[Bug tree-optimization/53844] [4.6/4.7 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04
09:55:27 UTC ---
For trunk dse_possible_dead_store_p fails to look through the loop, when
being at the VDEF .MEM_165:
bb 3:
# i_93 = PHI i_78(3), 0(2)
# .MEM_100 = PHI .MEM_165(3), .MEM_68(2)
# VUSE .MEM_100
D.3879_71 = MEM[(struct VBase *)out_2(D)].my_data;
D.3880_73 = (long unsigned int) i_93;
D.3881_74 = D.3880_73 * 8;
D.3878_75 = D.3879_71 + D.3881_74;
# VUSE .MEM_100
D.3975_138 = MEM[(const struct VBase *)in_1(D)].my_data;
D.3974_141 = D.3975_138 + D.3881_74;
# VUSE .MEM_100
D.3981_142 = *D.3974_141;
# .MEM_165 = VDEF .MEM_100
*D.3878_75 = D.3981_142;
i_78 = i_93 + 1;
if (i_78 != 100)
goto bb 3;
else
goto bb 4;
bb 4:
# .MEM_28 = VDEF .MEM_165
D.2811 ={v} {CLOBBER};
we then see two uses that have a VDEF - the PHI (which we processed before),
and the store after the loop.
The following fixes that
Index: gcc/tree-ssa-dse.c
===
--- gcc/tree-ssa-dse.c (revision 189248)
+++ gcc/tree-ssa-dse.c (working copy)
@@ -94,7 +94,7 @@ dse_possible_dead_store_p (gimple stmt,
temp = stmt;
do
{
- gimple use_stmt;
+ gimple use_stmt, defvar_def;
imm_use_iterator ui;
bool fail = false;
tree defvar;
@@ -108,6 +108,7 @@ dse_possible_dead_store_p (gimple stmt,
defvar = PHI_RESULT (temp);
else
defvar = gimple_vdef (temp);
+ defvar_def = temp;
temp = NULL;
FOR_EACH_IMM_USE_STMT (use_stmt, ui, defvar)
{
@@ -139,7 +140,13 @@ dse_possible_dead_store_p (gimple stmt,
fail = true;
BREAK_FROM_IMM_USE_STMT (ui);
}
- temp = use_stmt;
+ /* Do not consider the PHI as use if it dominates the
+stmt defining the virtual operand we are processing. */
+ if (gimple_bb (defvar_def) != gimple_bb (use_stmt)
+ !dominated_by_p (CDI_DOMINATORS,
+ gimple_bb (defvar_def),
+ gimple_bb (use_stmt)))
+ temp = use_stmt;
}
/* If the statement is a use the store is not dead. */
else if (ref_maybe_used_by_stmt_p (use_stmt,
but the existing loop code is weird ...
I'm anyway testing the above.
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433
--- Comment #21 from Uros Bizjak ubizjak at gmail dot com 2012-07-04 10:10:13
UTC ---
It looks that expand_builtin_strncmp gets miscompiled.
Try to compile the testcase from Comment #5 with -O2 on x86_64-pc-linux-gnu.
Put breakpoint in gen_cmpstrnsi.
When debugging normal, non-LTO, non-profiled build, we get:
Breakpoint 1, gen_cmpstrnsi (operand0=0x71ace8a0, operand1=0x71acb8b8,
operand2=0x71acb918, operand3=0x719a84f0, operand4=0x719a8480)
at ../../gcc-svn/trunk/gcc/config/i386/i386.md:15989
15989 (set (match_operand:P 0 register_operand =D)
(gdb) bt
#0 gen_cmpstrnsi (operand0=0x71ace8a0, operand1=0x71acb8b8,
operand2=0x71acb918,
operand3=0x719a84f0, operand4=0x719a8480)
at ../../gcc-svn/trunk/gcc/config/i386/i386.md:15989
#1 0x005bb0c0 in expand_builtin_strncmp (exp=0x71acdd20,
target=0x71ace8a0,
mode=optimized out) at ../../gcc-svn/trunk/gcc/builtins.c:4000
(gdb) up
#1 0x005bb0c0 in expand_builtin_strncmp (exp=0x71acdd20,
target=0x71ace8a0,
mode=optimized out) at ../../gcc-svn/trunk/gcc/builtins.c:4000
4000 GEN_INT (MIN (arg1_align, arg2_align)));
(gdb) li
3995
3996arg1_rtx = get_memory_rtx (arg1, len);
3997arg2_rtx = get_memory_rtx (arg2, len);
3998arg3_rtx = expand_normal (len);
3999insn = gen_cmpstrnsi (result, arg1_rtx, arg2_rtx, arg3_rtx,
4000 GEN_INT (MIN (arg1_align, arg2_align)));
4001if (insn)
4002 {
4003emit_insn (insn);
4004
(gdb) p target
$11 = (rtx_def *) 0x71ace8a0
(gdb) p result
$12 = (rtx_def *) 0x71ace8a0
(gdb)
debugging profiledbootstrap (--with-build-config=bootstrap-lto):
Breakpoint 3, gen_cmpstrnsi (operand0=0x71ace9e0, operand1=0x71acb8b8,
operand2=0x71acb918, operand3=0x719a84f0, operand4=0x719a8480)
at ../../gcc-svn/trunk/gcc/config/i386/i386.md:15989
15989 (set (match_operand:P 0 register_operand =D)
(gdb) bt
#0 gen_cmpstrnsi (operand0=0x71ace9e0, operand1=0x71acb8b8,
operand2=0x71acb918,
operand3=0x719a84f0, operand4=0x719a8480)
at ../../gcc-svn/trunk/gcc/config/i386/i386.md:15989
#1 0x00b3310f in
_ZL22expand_builtin_strncmpP9tree_nodeP7rtx_def12machine_mode.isra.13 (
target=0x71ace8a0, exp=0x71acdd20) at
../../gcc-svn/trunk/gcc/builtins.c:4000
(gdb) p target
$12 = (struct rtx_def *) 0x71ace8a0
(gdb) p result
$13 = '\000' repeats 113 times
(gdb)
The trick is that a couple of lines above, we have:
/* Make a place to write the result of the instruction. */
result = target;
if (! (result != 0
REG_P (result) GET_MODE (result) == insn_mode
REGNO (result) = FIRST_PSEUDO_REGISTER))
result = gen_reg_rtx (insn_mode);
Probably result doesn't get propagated correctly to gen_cmpstrnsi, we have:
(gdb) p *target
$15 = {code = REG, mode = SImode, jump = 0, call = 0, unchanging = 0, volatil =
0, in_struct = 0,
(gdb) down
#0 gen_cmpstrnsi (operand0=0x71ace9e0, operand1=0x71acb8b8,
operand2=0x71acb918,
operand3=0x719a84f0, operand4=0x719a8480)
at ../../gcc-svn/trunk/gcc/config/i386/i386.md:15989
15989 (set (match_operand:P 0 register_operand =D)
(gdb) p *operand0
$14 = {code = REG, mode = VOIDmode, jump = 0, call = 0, unchanging = 0, volatil
= 0, in_struct = 0,
Everything goes downhill there.
(sorry for not using debug_rtx here, calling it gdb says Cannot resolve
function debug_rtx to any overloaded instance.)
[Bug c++/53848] [4.8 regression] ICE in decl_linkage at ../../gcc-trunk/gcc/cp/tree.c:3215
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53848
--- Comment #2 from Dmitry G. Dyachenko dimhen at gmail dot com 2012-07-04
10:18:03 UTC ---
extern C
{
struct s {
enum {
e = 0
} f;
};
}
[Bug c++/53848] [4.8 regression] ICE in decl_linkage at ../../gcc-trunk/gcc/cp/tree.c:3215
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53848 --- Comment #3 from Dmitry G. Dyachenko dimhen at gmail dot com 2012-07-04 10:19:37 UTC --- r189094 OK
[Bug fortran/53851] New: Automatic silent allocation/deallocation of allocatable variables in several instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53851 Bug #: 53851 Summary: Automatic silent allocation/deallocation of allocatable variables in several instances Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: liluli2...@gmail.com I have found that gfortran (v4.6) performs implicit allocation and deallocation of allocatable variables when these are assigned values using a constructor, like in the example code below. I wonder whether this is intentional and complying with the Fortran standard. I have checked with ifort and there seems not to be such implicit allocation/deallocation for it (neither gfortran nor ifort compilers give compilation or execution error messages in connection with the example below, but the respective outputs are very different). implicit none integer, allocatable, dimension(:) :: vec integer, allocatable, dimension(:,:) :: aa integer :: i ! allocate ( vec(20) ) vec = (/ ( 1, -1, i = 1, 20 ) /) print*, vector size, size(vec) ! allocate ( aa(4,4) ) aa = reshape ( vec , shape = (/ 4,4 /) ) ! It is like reshape implies a silent previous allocation of an otherwise not explicitly allocated variable print*, array shape, shape(aa) do i = 1, 4 print*, aa(i,:) end do ! deallocate ( aa ) ; allocate ( aa(5,5) ) aa = reshape ( vec , shape = (/ 5,5 /) ) ! Now the variable is reallocated implicitly to a new shape without having been explicitly deallocated print*, new array shape, shape(aa) do i = 1, 5 print*, aa(i,:) end do vec = (/ ( 1, -1, i = 1, 25 ) /) ! same for this rank-1 array print*, new vector size, size(vec) end program
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 --- Comment #22 from Uros Bizjak ubizjak at gmail dot com 2012-07-04 10:37:48 UTC --- Digging deeper, both testcases (from comment #0 and comment #5) fail due to: enum machine_mode insn_mode = insn_data[(int) CODE_FOR_cmpstrnsi].operand[0].mode; The insn_mode is determined as VOIDmode in both cases. The testcase from comment #0 fails in expand_builtin_strcmp (builtins.c line 3825) and the testcase from comment #5 fails in expand_builtin_strncmp (builtins.c line 3937). The pattern is defined in a correct way: (define_expand cmpstrnsi [(set (match_operand:SI 0 register_operand) (compare:SI (match_operand:BLK 1 general_operand) (match_operand:BLK 2 general_operand))) (use (match_operand 3 general_operand)) (use (match_operand 4 immediate_operand))]
[Bug c++/53848] [4.8 regression] ICE in decl_linkage at ../../gcc-trunk/gcc/cp/tree.c:3215
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53848 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-04 Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 10:53:51 UTC --- Confirmed. Program received signal SIGSEGV, Segmentation fault. 0x0080dbfe in decl_linkage (decl=0x76f5cd90) at /space/rguenther/src/svn/trunk/gcc/cp/tree.c:3215 3215return decl_linkage (TYPE_NAME (DECL_CONTEXT (decl))); (gdb) l 3210return lk_external; 3211 3212 /* Linkage of a CONST_DECL depends on the linkage of the enumeration 3213 type. */ 3214 if (TREE_CODE (decl) == CONST_DECL) 3215return decl_linkage (TYPE_NAME (DECL_CONTEXT (decl))); 3216 3217 /* Some things that are not TREE_PUBLIC have external linkage, too. 3218 For example, on targets that don't have weak symbols, we make all 3219 template instantiations have internal linkage (in the object (gdb) call debug_tree (decl) const_decl 0x76f5cd90 e type integer_type 0x76f775e8 int public SI size integer_cst 0x76f7d100 constant 32 unit size integer_cst 0x76f7d120 constant 4 align 32 symtab 0 alias set -1 canonical type 0x76f775e8 precision 32 min integer_cst 0x76f7d0a0 -2147483648 max integer_cst 0x76f7d0c0 2147483647 pointer_to_this pointer_type 0x76f852a0 VOID file t.ii line 5 col 10 align 1 no DECL_CONTEXT.
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433
--- Comment #23 from Uros Bizjak ubizjak at gmail dot com 2012-07-04 10:58:03
UTC ---
Compiling testcase from comment 0, -O0:
(gdb) b builtins.c:3830
Breakpoint 1 at 0x522c91: file ../../gcc-svn/trunk/gcc/builtins.c, line 3830.
(gdb) r
Starting program: /home/uros/gcc-build-xxx/gcc/cc1 -O0 ttt.c
d_unqualified_name
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups
whole-programAssembling functions:
d_unqualified_name
Breakpoint 1, expand_builtin_strcmp (exp=0x719a5b88, target=0x71ace360)
at ../../gcc-svn/trunk/gcc/builtins.c:3830
3830 if (len1)
(gdb) li
3827 tree len1 = c_strlen (arg1, 1);
3828 tree len2 = c_strlen (arg2, 1);
3829
3830 if (len1)
(gdb) p insn_mode
$1 = VOIDmode
(gdb) p insn_data[2829]
$2 = {name = 0xdc80ab cmpstrnsi, output = {single = 0x0, multi = 0x0,
function = 0},
genfun = 0x623d95 gen_cmpstrnsi(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*),
operand = 0xe09e98, n_generator_args = 5 '\005', n_operands = 5 '\005',
n_dups = 0 '\000',
n_alternatives = 0 '\000', output_format = 0 '\000'}
(gdb) p insn_data[2829].operand[0].mode
$3 = SImode
But...
enum machine_mode insn_mode
= insn_data[(int) CODE_FOR_cmpstrnsi].operand[0].mode;
tree len1 = c_strlen (arg1, 1);
tree len2 = c_strlen (arg2, 1);
Something is seriously broken here. insn_mode should get SImode, not VOIDmode.
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433
--- Comment #24 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04
11:16:20 UTC ---
The hint in comment #5 together with your analysis points at the initializer
in insn-output.c:
const struct insn_data_d insn_data[] =
{
...
/* /space/rguenther/src/svn/trunk/gcc/config/i386/i386.md:16008 */
{
cmpstrnsi,
#if HAVE_DESIGNATED_UNION_INITIALIZERS
{ 0 },
#else
{ 0, 0, 0 },
#endif
(insn_gen_fn) gen_cmpstrnsi,
operand_data[5173],
5,
5,
0,
0,
0
},
and operand_data in
static const struct insn_operand_data operand_data[] =
{
...
{
0,
,
VOIDmode,
0,
0,
1,
0
},
{ --- should be this
register_operand,
,
SImode,
0,
0,
1,
0
},
{
general_operand,
,
BLKmode,
0,
0,
1,
1
},
so maybe there is an off-by-one error somewhere in constant folding from
initializers?
[Bug middle-end/53852] New: -ftree-loop-linear: large compile time / memory usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852 Bug #: 53852 Summary: -ftree-loop-linear: large compile time / memory usage Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch Current trunk (189233) has X Gb of memory usage (before I have to kill the compilation) on the following testcase with: gfortran -O2 -ftree-loop-linear test.f90 SUBROUTINE build_d_tensor_gks(d1f, d2f, d3f, d4f, d5f, v, d1, d2, d3, d4, d5) INTEGER, PARAMETER :: dp=8 REAL(KIND=dp), DIMENSION(3), INTENT(OUT) :: d1f REAL(KIND=dp), DIMENSION(3, 3), INTENT(OUT):: d2f REAL(KIND=dp), DIMENSION(3, 3, 3), INTENT(OUT):: d3f REAL(KIND=dp), DIMENSION(3, 3, 3, 3), INTENT(OUT):: d4f REAL(KIND=dp), DIMENSION(3, 3, 3, 3, 3), INTENT(OUT), OPTIONAL :: d5f REAL(KIND=dp), DIMENSION(3), INTENT(IN) :: v REAL(KIND=dp), INTENT(IN):: d1, d2, d3, d4 REAL(KIND=dp), INTENT(IN), OPTIONAL :: d5 INTEGER :: k1, k2, k3, k4, k5 REAL(KIND=dp):: w d1f = 0.0_dp d2f = 0.0_dp d3f = 0.0_dp d4f = 0.0_dp DO k1=1,3 d1f(k1)=d1f(k1)+v(k1)*d1 ENDDO DO k1=1,3 DO k2=1,3 d2f(k2,k1)=d2f(k2,k1)+v(k1)*v(k2)*d2 ENDDO d2f(k1,k1)=d2f(k1,k1)+ d1 ENDDO DO k1=1,3 DO k2=1,3 DO k3=1,3 d3f(k3,k2,k1)=d3f(k3,k2,k1)+v(k1)*v(k2)*v(k3)*d3 ENDDO w=v(k1)*d2 d3f(k1,k2,k2)=d3f(k1,k2,k2)+w d3f(k2,k1,k2)=d3f(k2,k1,k2)+w d3f(k2,k2,k1)=d3f(k2,k2,k1)+w ENDDO ENDDO DO k1=1,3 DO k2=1,3 DO k3=1,3 DO k4=1,3 d4f(k4,k3,k2,k1)=d4f(k4,k3,k2,k1)+ v(k1)*v(k2)*v(k3)*v(k4)*d4 ENDDO w=v(k1)*v(k2)*d3 d4f(k1,k2,k3,k3)=d4f(k1,k2,k3,k3)+w d4f(k1,k3,k2,k3)=d4f(k1,k3,k2,k3)+w d4f(k3,k1,k2,k3)=d4f(k3,k1,k2,k3)+w d4f(k1,k3,k3,k2)=d4f(k1,k3,k3,k2)+w d4f(k3,k1,k3,k2)=d4f(k3,k1,k3,k2)+w d4f(k3,k3,k1,k2)=d4f(k3,k3,k1,k2)+w ENDDO d4f(k1,k1,k2,k2)=d4f(k1,k1,k2,k2)+d2 d4f(k1,k2,k1,k2)=d4f(k1,k2,k1,k2)+d2 d4f(k1,k2,k2,k1)=d4f(k1,k2,k2,k1)+d2 ENDDO ENDDO IF (PRESENT(d5f).AND.PRESENT(d5)) THEN d5f = 0.0_dp DO k1=1,3 DO k2=1,3 DO k3=1,3 DO k4=1,3 DO k5=1,3 d5f(k5,k4,k3,k2,k1)=d5f(k5,k4,k3,k2,k1)+ v(k1)*v(k2)*v(k3)*v(k4)*v(k5)*d5 ENDDO w=v(k1)*v(k2)*v(k3)*d4 d5f(k1,k2,k3,k4,k4)=d5f(k1,k2,k3,k4,k4)+w d5f(k1,k2,k4,k3,k4)=d5f(k1,k2,k4,k3,k4)+w d5f(k1,k4,k2,k3,k4)=d5f(k1,k4,k2,k3,k4)+w d5f(k4,k1,k2,k3,k4)=d5f(k4,k1,k2,k3,k4)+w d5f(k1,k2,k4,k4,k3)=d5f(k1,k2,k4,k4,k3)+w d5f(k1,k4,k2,k4,k3)=d5f(k1,k4,k2,k4,k3)+w d5f(k4,k1,k2,k4,k3)=d5f(k4,k1,k2,k4,k3)+w d5f(k1,k4,k4,k2,k3)=d5f(k1,k4,k4,k2,k3)+w d5f(k4,k1,k4,k2,k3)=d5f(k4,k1,k4,k2,k3)+w d5f(k4,k4,k1,k2,k3)=d5f(k4,k4,k1,k2,k3)+w ENDDO w=v(k1)*d3 d5f(k1,k2,k2,k3,k3)=d5f(k1,k2,k2,k3,k3)+w d5f(k1,k2,k3,k2,k3)=d5f(k1,k2,k3,k2,k3)+w d5f(k1,k2,k3,k3,k2)=d5f(k1,k2,k3,k3,k2)+w d5f(k2,k1,k2,k3,k3)=d5f(k2,k1,k2,k3,k3)+w d5f(k2,k1,k3,k2,k3)=d5f(k2,k1,k3,k2,k3)+w d5f(k2,k1,k3,k3,k2)=d5f(k2,k1,k3,k3,k2)+w d5f(k2,k2,k1,k3,k3)=d5f(k2,k2,k1,k3,k3)+w d5f(k2,k3,k1,k2,k3)=d5f(k2,k3,k1,k2,k3)+w d5f(k2,k3,k1,k3,k2)=d5f(k2,k3,k1,k3,k2)+w d5f(k2,k2,k3,k1,k3)=d5f(k2,k2,k3,k1,k3)+w d5f(k2,k3,k2,k1,k3)=d5f(k2,k3,k2,k1,k3)+w d5f(k2,k3,k3,k1,k2)=d5f(k2,k3,k3,k1,k2)+w d5f(k2,k2,k3,k3,k1)=d5f(k2,k2,k3,k3,k1)+w d5f(k2,k3,k2,k3,k1)=d5f(k2,k3,k2,k3,k1)+w d5f(k2,k3,k3,k2,k1)=d5f(k2,k3,k3,k2,k1)+w ENDDO ENDDO ENDDO END IF END SUBROUTINE build_d_tensor_gks
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433
--- Comment #25 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04
11:26:55 UTC ---
Or the insn_data initializer does not properly point to the operand_data
initializer (maybe that is non-existent or the magic LTO error_mark_node
and we fold that in a wrong way - VOIDmode happens to be zero after all...).
See the special code in get_base_constructor in gimple-fold.c:
/* See if we can find constructor defining value of BASE.
When we know the consructor with constant offset (such as
base is array[40] and we do know constructor of array), then
BIT_OFFSET is adjusted accordingly.
As a special case, return error_mark_node when constructor
is not explicitly available, but it is known to be zero
such as 'static const int a;'. */
static tree
get_base_constructor (tree base, HOST_WIDE_INT *bit_offset,
tree (*valueize)(tree))
...
switch (TREE_CODE (base))
{
case VAR_DECL:
if (!const_value_known_p (base))
return NULL_TREE;
/* Fallthru. */
case CONST_DECL:
if (!DECL_INITIAL (base)
(TREE_STATIC (base) || DECL_EXTERNAL (base)))
return error_mark_node;
return DECL_INITIAL (base);
and lto-streamer-out.c:
/* Write a physical representation of tree node EXPR to output block
OB. If REF_P is true, the leaves of EXPR are emitted as references
via lto_output_tree_ref. IX is the index into the streamer cache
where EXPR is stored. */
static void
lto_write_tree (struct output_block *ob, tree expr, bool ref_p)
{
...
/* Handle DECL_INITIAL for symbols. */
tree initial = DECL_INITIAL (expr);
if (TREE_CODE (expr) == VAR_DECL
(TREE_STATIC (expr) || DECL_EXTERNAL (expr))
initial)
{
lto_varpool_encoder_t varpool_encoder;
struct varpool_node *vnode;
varpool_encoder = ob-decl_state-varpool_node_encoder;
vnode = varpool_get_node (expr);
if (!vnode
|| !lto_varpool_encoder_encode_initializer_p (varpool_encoder,
vnode))
initial = error_mark_node;
So, does
Index: gimple-fold.c
===
--- gimple-fold.c (revision 189251)
+++ gimple-fold.c (working copy)
@@ -2713,6 +2713,8 @@ get_base_constructor (tree base, HOST_WI
if (!DECL_INITIAL (base)
(TREE_STATIC (base) || DECL_EXTERNAL (base)))
return error_mark_node;
+ if (DECL_INITIAL (base) == error_mark_node)
+ return NULL_TREE;
return DECL_INITIAL (base);
case ARRAY_REF:
fix it?
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 --- Comment #26 from Uros Bizjak ubizjak at gmail dot com 2012-07-04 11:30:26 UTC --- (In reply to comment #25) So, does Index: gimple-fold.c === --- gimple-fold.c (revision 189251) +++ gimple-fold.c (working copy) @@ -2713,6 +2713,8 @@ get_base_constructor (tree base, HOST_WI if (!DECL_INITIAL (base) (TREE_STATIC (base) || DECL_EXTERNAL (base))) return error_mark_node; + if (DECL_INITIAL (base) == error_mark_node) + return NULL_TREE; return DECL_INITIAL (base); case ARRAY_REF: fix it? Let me restart the bootstrap, I will report ASAP. BTW: There is no referece to insn_data in failing expand_builtin_strcmp objdump asm dump.
[Bug middle-end/53852] -ftree-loop-linear: large compile time / memory usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog, ||memory-hog Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-04 CC||matz at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 11:54:42 UTC --- From #20 0x012171c0 in compute_deps (scop=0x1f16e50, pbbs=0x1fa6d70, must_raw=0x1f16e90, may_raw=0x1f16e98, must_raw_no_source=0x1f16ea0, may_raw_no_source=0x1f16ea8, must_war=0x1f16eb0, may_war=0x1f16eb8, must_war_no_source=0x1f16ec0, may_war_no_source=0x1f16ec8, must_waw=0x1f16ed0, may_waw=0x1f16ed8, must_waw_no_source=0x1f16ee0, may_waw_no_source=0x1f16ee8) at /space/rguenther/src/svn/trunk/gcc/graphite-dependences.c:471 471 res = isl_union_map_compute_flow (isl_union_map_copy (reads), we do not finish without allocating much much memory. from inside ISL it's compute_val_based_dependences that takes that much memory and compile-time.
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 --- Comment #27 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-07-04 11:53:56 UTC --- (In reply to comment #25) So, does Index: gimple-fold.c === --- gimple-fold.c (revision 189251) +++ gimple-fold.c (working copy) @@ -2713,6 +2713,8 @@ get_base_constructor (tree base, HOST_WI if (!DECL_INITIAL (base) (TREE_STATIC (base) || DECL_EXTERNAL (base))) return error_mark_node; + if (DECL_INITIAL (base) == error_mark_node) + return NULL_TREE; return DECL_INITIAL (base); case ARRAY_REF: fix it? Yes! At least gcc builds now without errors. (I didn't run the test-suite yet)
[Bug target/53811] ICE: in insn_default_length, at config/i386/i386.md:529 (unrecognizable insn) with -mcmodel=large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53811
--- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-07-04
12:07:15 UTC ---
g++.dg/other/pr53811.C fails on x86_64-apple-darwin10 with -m64:
FAIL: g++.dg/other/pr53811.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/other/pr53811.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/other/pr53811.C -std=gnu++11 (internal compiler error)
FAIL: g++.dg/other/pr53811.C -std=gnu++11 (test for excess errors)
The ICE is
Excess errors:
/opt/gcc/work/gcc/testsuite/g++.dg/other/pr53811.C:29:1: error: insn does not
satisfy its constraints:
(insn 3 2 4 (set (reg:DI 59)
(const:DI (unspec:DI [
(symbol_ref:DI (_ZN12ScriptString12CreateStringEPKc)
[flags 0x403] function_decl 0x142987100 CreateString)
] UNSPEC_GOTOFF))) 62 {*movdi_internal_rex64}
(nil))
Should I open a new PR?
Note that ' -mcmodel=large' seems to have issues on x86_64-apple-darwin10: see
pr50077.
[Bug middle-end/53849] [4.8 Regression] ICE: in add_referenced_var_1, at tree-dfa.c:567 with -O2 -ftree-parallelize-loops=2 -fno-tree-loop-im
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53849 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 12:09:20 UTC --- Author: rguenth Date: Wed Jul 4 12:09:09 2012 New Revision: 189255 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189255 Log: 2012-07-04 Richard Guenther rguent...@suse.de PR tree-optimization/53849 * tree-cfg.c (move_stmt_op): Only call add_referenced_var for duplicated locals. Use add_referenced_var_1 to avoid pushing/popping cfun. * gcc.dg/pr53849.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr53849.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug tree-optimization/53844] [4.6/4.7 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 12:10:56 UTC --- Author: rguenth Date: Wed Jul 4 12:10:40 2012 New Revision: 189256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189256 Log: 2012-07-04 Richard Guenther rguent...@suse.de PR tree-optimization/53844 * tree-ssa-dse.c (dse_possible_dead_store_p): Properly handle the loop virtual PHI. * g++.dg/tree-ssa/pr53844.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr53844.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dse.c
[Bug middle-end/53852] -ftree-loop-linear: large compile time / memory usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852 --- Comment #2 from Michael Matz matz at gcc dot gnu.org 2012-07-04 12:11:10 UTC --- ISL generally has speed problems. For instance graphite/interchange-8.c needs quite long to compile (well, several seconds), and _all_ of the runtime is basically in malloc/free/copy activity of isl_int's. It does 10 million calls to malloc/free, 51 million to gmpz_set, 15 million to gmpz_addmul, 9 million to gmpz_mul, 51 million gmpn_copi, and so on. Huge causes for this excessive gmp activity is compute_deps - isl_union_map_compute_flow. Three calls of the latter are responsible for 76% compile time, and it's all in gmp activity. It's then doing 16x isl_access_info_compute_flow, 210x isl_map_partial_lexmax, 307x isl_map_apply_range and isl_map_intersect, which do 1x isl_basic_map_intersect and 7400x isl_basic_map_apply_range. That causes 25000x isl_basic_map_simplify and 61000x isl_basic_map_alloc_space. That results in 82000x isl_blk_alloc, which ultimately does the excessive number of malloc and gmp_init calls. And it results in several million calls to the simplify primitives (isl_seq_elim-isl_seq_combine-gmp_addmul/mul/set, isl_seq_copy, and isl_seq_abs_min_non_zero).
[Bug tree-optimization/53844] [4.6/4.7 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 12:11:57 UTC --- Fixed on trunk sofar, watching for fallout.
[Bug middle-end/53849] [4.8 Regression] ICE: in add_referenced_var_1, at tree-dfa.c:567 with -O2 -ftree-parallelize-loops=2 -fno-tree-loop-im
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53849 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 12:12:01 UTC --- Fixed.
[Bug target/53811] ICE: in insn_default_length, at config/i386/i386.md:529 (unrecognizable insn) with -mcmodel=large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53811 --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2012-07-04 12:14:00 UTC --- (In reply to comment #6) Should I open a new PR? Yes, please. I will wait with the 4.7 backport until new PR resolves. Note that ' -mcmodel=large' seems to have issues on x86_64-apple-darwin10: see pr50077. TBH, -mcmodel=large is currently an overkill, but fixes are fairly trivial (pushing address to temporary reg).
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 --- Comment #28 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 12:14:03 UTC --- Ok, I'll bootstrap and test and commit the fix. Thanks for tracking it down up to a point where I thought *well, that sounds familiar in some way* ;)
[Bug middle-end/53852] -ftree-loop-linear: large compile time / memory usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-07-04 12:17:47 UTC --- To fill in the X, 130 Gb is not sufficient for this testcase.
[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831 --- Comment #21 from Andi Kleen andi-gcc at firstfloor dot org 2012-07-04 12:24:45 UTC --- For non fat (slim) LTO builds you need to use these tools yes. ar needs to know the symbol table for its index and that needs LTO specific knowledge. This follows other slim lto compilers like LLVM or icc. There's no special documentation because the usage is the same as the standard ar/ranlib/nm. The lto documentation hints at them, but could be perhaps clearer.
[Bug target/53853] New: FAIL: g++.dg/other/pr53811.C -std=gnu++* (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53853
Bug #: 53853
Summary: FAIL: g++.dg/other/pr53811.C -std=gnu++* (internal
compiler error)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: ia...@gcc.gnu.org, ubiz...@gmail.com
Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
Build: x86_64-apple-darwin10
g++.dg/other/pr53811.C fails on x86_64-apple-darwin10 with -m64:
FAIL: g++.dg/other/pr53811.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/other/pr53811.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/other/pr53811.C -std=gnu++11 (internal compiler error)
FAIL: g++.dg/other/pr53811.C -std=gnu++11 (test for excess errors)
The ICE is
Excess errors:
/opt/gcc/work/gcc/testsuite/g++.dg/other/pr53811.C:29:1: error: insn does not
satisfy its constraints:
(insn 3 2 4 (set (reg:DI 59)
(const:DI (unspec:DI [
(symbol_ref:DI (_ZN12ScriptString12CreateStringEPKc)
[flags 0x403] function_decl 0x142987100 CreateString)
] UNSPEC_GOTOFF))) 62 {*movdi_internal_rex64}
(nil))
Note that ' -mcmodel=large' seems to have issues on x86_64-apple-darwin10: see
pr50077.
[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831 --- Comment #22 from Yuri Gribov tetra2005 at gmail dot com 2012-07-04 12:32:08 UTC --- For non fat (slim) LTO builds you need to use these tools yes So it seems that original testcase with fat files which used plain ar is indeed correct and we have a real bug.
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 --- Comment #29 from Uros Bizjak ubizjak at gmail dot com 2012-07-04 12:32:25 UTC --- The patch from Comment #25 works for me, too. You will need a bunch of patches from PR53321 to finish LTO profiledbootstrap, I will post these to gcc-patches@ mailing list. Regression test is currently in progress. All looks OK.
[Bug tree-optimization/53852] [4.8 Regression] -ftree-loop-linear: large compile time / memory usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |tree-optimization Known to work||4.7.1 Target Milestone|--- |4.8.0 Summary|-ftree-loop-linear: large |[4.8 Regression] |compile time / memory usage |-ftree-loop-linear: large ||compile time / memory usage --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 12:43:48 UTC --- 4.7 compiles this quickly and without too much memory.
[Bug target/53854] New: ICE in find_constant_pool_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854
Bug #: 53854
Summary: ICE in find_constant_pool_ref
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: s390x-linux
void baz (void);
void
foo (void)
{
int i;
double d = 2.0;
float f = .0f;
for (i = 0; i 10; i++)
{
__asm (# %0 %1 :: or (d), or (f));
baz ();
}
}
ICEs with -m64 -O2 in find_constant_pool_ref, which assumes a single insn
references at most one constant pool entry. ASM_OPERANDS can reference many
more though. This breaks systemtap probes on s390x.
[Bug target/53853] FAIL: g++.dg/other/pr53811.C -std=gnu++* (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53853 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-04 Ever Confirmed|0 |1 --- Comment #1 from Iain Sandoe iains at gcc dot gnu.org 2012-07-04 13:05:45 UTC --- Also on i686-darwin9 @m64 As commented in 50077, we don't support the large model. I suppose the best thing to do in the short(ish) term is to make a target test for large model support and make the tests that require it do that test. Addition of large model support would be nice - but might be optimistic for 4.8 with the resources available to darwin at present.
[Bug target/53854] ICE in find_constant_pool_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-07-04 13:15:39 UTC --- Created attachment 27742 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27742 gcc48-pr53854.patch Untested fix.
[Bug target/53854] ICE in find_constant_pool_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-04 CC||krebbel at gcc dot gnu.org, ||uweigand at gcc dot gnu.org Target Milestone|--- |4.7.2 Ever Confirmed|0 |1
[Bug middle-end/53844] [4.6/4.7 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844
Edward Rosten ed at edrosten dot com changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #8 from Edward Rosten ed at edrosten dot com 2012-07-04 13:36:28
UTC ---
(In reply to comment #7)
Fixed on trunk sofar, watching for fallout.
I pulled the latest change from SVN and tried it on the test code, with
success.
I'm using the shortened test function:
void test(const Vector in, Vector out, int i)
{
out = in*1*1*1*1;
}
If I change the test function to:
void test(const Vector in, Vector out, int i)
{
const VectorScalarMulExprScalarMulExprScalarMulExprScalarMulExprVBase
v = in*1*1*1*1;
out = v;
}
The the results go to being almost identical to gcc 4.7 (and much worse than
the first test function). The asm code (compiled with -fno-tree-vectorize to
avoid all the asm code to deal with alignment etc) gives:
_Z4testRK6VectorI5VBaseERS1_i:
.LFB8:
.cfi_startproc
movq(%rsi), %rcx
xorl%esi, %esi
movq-16(%rsp), %rax
cvtsi2sd%esi, %xmm1
movq8(%rax), %rdx
movq(%rax), %rax
cvtsi2sd(%rax), %xmm3
movq-24(%rsp), %rax
movq(%rdx), %rdx
cvtsi2sd(%rax), %xmm2
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L3:
movsd(%rdx,%rax), %xmm0
mulsd%xmm3, %xmm0
mulsd%xmm2, %xmm0
mulsd%xmm1, %xmm0
movsd%xmm0, (%rcx,%rax)
addq$8, %rax
cmpq$800, %rax
jne.L3
rep; ret
.cfi_endproc
In this case, it's clearly converting all those 1's to floats and then
multiplying by all but the first one. Note that if the following test function
is used:
void test(const Vector in, Vector out, int i)
{
const VectorScalarMulExprScalarMulExprVBase v = in*1*1;
out = v;
}
Then suboptimal code isn't produced. Further investigation shows that this also
applies to the previous symptom with unnecessary pushes in gcc 4.7.
If I change the mul member in ScalarMulExpr to int rather than int, the
compiler can optimize away the first two multiplications, rather than the first
one.
GCC version is:
gcc-4.8-svn -v
Using built-in specs.
COLLECT_GCC=gcc-4.8-svn
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --program-suffix=-4.8-svn
--enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120704 (experimental) (GCC)
but similar results are reported on 4.7 as well.
Is this a continuation of the same bug, or should I refile this as a new bug?
[Bug middle-end/53844] [4.6/4.7 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844 --- Comment #9 from Edward Rosten ed at edrosten dot com 2012-07-04 13:40:54 UTC --- (In reply to comment #7) Fixed on trunk sofar, watching for fallout. I would like to note that your fix seems to remove the performance hit in my numerics which revealed the bug.
[Bug middle-end/53844] [4.6/4.7 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844
--- Comment #10 from rguenther at suse dot de rguenther at suse dot de
2012-07-04 13:47:09 UTC ---
On Wed, 4 Jul 2012, ed at edrosten dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844
Edward Rosten ed at edrosten dot com changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #8 from Edward Rosten ed at edrosten dot com 2012-07-04
13:36:28 UTC ---
(In reply to comment #7)
Fixed on trunk sofar, watching for fallout.
I pulled the latest change from SVN and tried it on the test code, with
success.
I'm using the shortened test function:
void test(const Vector in, Vector out, int i)
{
out = in*1*1*1*1;
}
If I change the test function to:
void test(const Vector in, Vector out, int i)
{
const
VectorScalarMulExprScalarMulExprScalarMulExprScalarMulExprVBase
v = in*1*1*1*1;
out = v;
}
I can at least see that you are using no longer live variables:
bb 2:
D.2391 ={v} {CLOBBER};
D.2396 ={v} {CLOBBER};
bb 3:
# i_36 = PHI i_35(3), 0(2)
D.2928_28 = MEM[(struct VBase *)out_3(D)].my_data;
D.2929_30 = (long unsigned int) i_36;
D.2930_31 = D.2929_30 * 8;
D.2927_32 = D.2928_28 + D.2930_31;
D.2948_44 = MEM[(const struct ScalarMulExpr *)D.2391].vec;
here D.2391 is already dead. So possibly you are returning references
to temporaries somewhere.
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 --- Comment #30 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 13:47:26 UTC --- Author: rguenth Date: Wed Jul 4 13:47:18 2012 New Revision: 189260 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189260 Log: 2012-07-04 Richard Guenther rguent...@suse.de PR middle-end/53433 * gimple-fold.c (get_base_constructor): Do not return an error_mark_node DECL_INITIAL. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c
[Bug bootstrap/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 --- Comment #18 from uros at gcc dot gnu.org 2012-07-04 13:49:24 UTC --- Author: uros Date: Wed Jul 4 13:49:19 2012 New Revision: 189261 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189261 Log: PR middle-end/53321 * ipa.c (symtab_remove_unreachable_nodes): Partially revert r187375 to not call cgraph_propagate_frequency if something was changed. testsuite/ChangLog: PR middle-end/53321 * g++.dg/torture/pr53321.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr53321.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 --- Comment #31 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 13:53:20 UTC --- Author: rguenth Date: Wed Jul 4 13:53:11 2012 New Revision: 189262 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189262 Log: 2012-07-04 Richard Guenther rguent...@suse.de PR middle-end/53433 * gimple-fold.c (get_base_constructor): Do not return an error_mark_node DECL_INITIAL. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/gimple-fold.c
[Bug middle-end/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-07/msg00146.htm ||l Component|bootstrap |middle-end AssignedTo|hubicka at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #19 from Uros Bizjak ubizjak at gmail dot com 2012-07-04 13:56:15 UTC --- Fixed.
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 --- Comment #32 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 13:56:05 UTC --- Author: rguenth Date: Wed Jul 4 13:56:00 2012 New Revision: 189263 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189263 Log: 2012-07-04 Richard Guenther rguent...@suse.de PR middle-end/53433 * tree-ssa-ccp.c (get_base_constructor): Do not return an error_mark_node DECL_INITIAL. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa-ccp.c
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #32 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 13:56:05 UTC --- Author: rguenth Date: Wed Jul 4 13:56:00 2012 New Revision: 189263 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189263 Log: 2012-07-04 Richard Guenther rguent...@suse.de PR middle-end/53433 * tree-ssa-ccp.c (get_base_constructor): Do not return an error_mark_node DECL_INITIAL. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa-ccp.c --- Comment #33 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 13:56:50 UTC --- Fixed.
[Bug middle-end/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #20 from Uros Bizjak ubizjak at gmail dot com 2012-07-04 13:57:53 UTC --- .
[Bug target/53670] GCC internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53670 Sergey Galanov sergey.e.galanov at gmail dot com changed: What|Removed |Added CC||sergey.e.galanov at gmail ||dot com --- Comment #4 from Sergey Galanov sergey.e.galanov at gmail dot com 2012-07-04 13:58:26 UTC --- The same problem happens with gcc 4.5.2. gcc 4.6.2 works fine, though.
[Bug middle-end/53433] [4.8 Regression] ICE in int_mode_for_mode, at stor-layout.c:424 during lto-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #33 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 13:56:50 UTC --- Fixed.
[Bug fortran/53449] [4.8 regression] fortran fails to build with LTO bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53449 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|bootstrap |fortran --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 13:59:15 UTC --- Frontend issue (if it still prevails).
[Bug middle-end/53428] [4.8 Regression] 403.gcc in SPEC CPU 2006 miscompiled by LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53428 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 14:00:10 UTC --- Hopefully fixed now (r189260) - please re-open if not.
[Bug target/53670] GCC internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53670 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-04 14:05:47 UTC --- Then it's fixed. GCC 4.5 is no longer maintained either. Without a testcase we couldn't have done anything anyways.
[Bug fortran/53449] [4.8 regression] fortran fails to build with LTO bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53449 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-04 AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-07-04 14:12:31 UTC --- (In reply to comment #2) Frontend issue (if it still prevails). Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00145.html
[Bug middle-end/53844] [4.6/4.7 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844 --- Comment #11 from Edward Rosten ed at edrosten dot com 2012-07-04 14:13:28 UTC --- (In reply to comment #10) On Wed, 4 Jul 2012, ed at edrosten dot com wrote: here D.2391 is already dead. So possibly you are returning references to temporaries somewhere. You are correct. In fiddling around adding and removing 's and not tracking my files properly, I left some references in. If I do it properly, then good code is produced.
[Bug target/53842] avr second write to volatile register gets dropped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53842 jim at jtan dot com changed: What|Removed |Added Status|WAITING |RESOLVED Known to work||4.7.1 Resolution||FIXED Known to fail||4.7.0 --- Comment #2 from jim at jtan dot com 2012-07-04 15:08:03 UTC --- You're right, 4.7.1 looks fine. Thanks.
[Bug c++/53848] [4.8 regression] ICE in decl_linkage at ../../gcc-trunk/gcc/cp/tree.c:3215
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53848 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-07-04 15:25:03 UTC --- It is caused by revision 189174: http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00078.html
[Bug tree-optimization/53855] New: Emitting a warning for some dangling references.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53855
Bug #: 53855
Summary: Emitting a warning for some dangling references.
Classification: Unclassified
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: e...@edrosten.com
A dangling reference is created in the following code:
struct IntRef
{
IntRef(const int v_)
:v(v_)
{
}
const int v;
double get() const
{
return v;
}
};
struct BRef
{
BRef(const IntRef v_)
:v(v_)
{
}
const IntRef v;
double get() const
{
return v.get();
}
};
double test(const int a)
{
const BRef c(a);
return c.get();
}
After the first stage of copy propagation, the representation of test is (from
test.cc.029t.copyprop1):
;; Function double test(const int) (_Z4testRKi, funcdef_no=8, decl_uid=2230,
cgraph_uid=8)
double test(const int) (const int a)
{
const struct IntRef c$v;
const struct IntRef D.2286;
int D.2284;
const int D.2283;
double D.2282;
const struct BRef c;
const struct IntRef D.2251;
bb 2:
D.2251.v = a_1(D);
D.2251 ={v} {CLOBBER};
D.2283_9 = D.2251.v;
D.2284_10 = *D.2283_9;
D.2282_11 = (double) D.2284_10;
return D.2282_11;
}
at which point is is quite obvious that D.2251 is used after it is CLOBBER'd.
Is it possible to add a feature to generate a warning in this case?
I'm using gcc version r189256 from SVN, but things are much the same in 4.7.
[Bug c++/53856] New: Default argument allowed on member defined outside of class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53856
Bug #: 53856
Summary: Default argument allowed on member defined outside of
class template
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
templatetypename T
struct A
{
struct B;
};
templatetypename T = int
struct AT::B
{
int i;
};
int main()
{
Aint::B b = { };
return b.i;
}
This should be rejected according to [temp.param]/9
A default template-argument shall not be specified in the
template-parameter-lists of the definition of a member of a class template that
appears outside of the member’s class.
All versions of G++ since at least 3.4 accept the code above.
Comeau online rejects it:
ComeauTest.c, line 7: error: a default template argument cannot be specified
on
the declaration of a member of a class template outside of its class
templatetypename T = int
^
As does Clang++
bug2.cc:7:19: error: cannot add a default template argument to the definition
of a member of a class template
templatetypename T = int
^ ~~~
Solaris CC accepts it.
[Bug c++/53856] Default argument allowed on member defined outside of class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53856
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Known to fail||3.4.3, 4.1.2, 4.6.3, 4.8.0
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-04
16:43:53 UTC ---
Modifying the example to use a member template of a non-template, which I
believe *is* valid, gets rejected:
struct A
{
templatetypename T
struct B;
};
templatetypename T = int
struct A::B
{
int i;
};
int main()
{
A::Bint b = { };
return b.i;
}
bug.cc:8:11: error: default argument for template parameter for class enclosing
'struct A::BT'
This seems to be completely backwards, the invalid case is accepted and the
valid case rejected!
Comeau online rejects it for the same reason as the code in commnt 0 above:
ComeauTest.c, line 6: error: a default template argument cannot be specified
on
the declaration of a member of a class template outside of its class
templatetypename T = int
^
The wording is much better than G++'s, but I think the error is wrong, as it
talks about a member of a class template, whereas the code above is a member
template of a class. Not the same thing.
Clang++ and Solaris CC accept the modified version.
[Bug c/53857] New: Possible problem with arithmetic overflow in optimizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53857 Bug #: 53857 Summary: Possible problem with arithmetic overflow in optimizer Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: 00w...@gmail.com Created attachment 27743 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27743 Program showing the problem Hi We found unusual behaviour of compilator which probably assumes there is no arithmetic overflow and then simplifies the code too much. We attach the simplest code which illustrates the problem. Make will create several binaries including: testo1 and testo2. The first is compiled with -O1 option, the other with -O2. For the gcc 4.6 (or clang'a 3.1) everything is fine. Both programs write: x: 2147483648, y: 2147483648 For gcc 4.7.1 (also 4.7) program testo1 writes the same as above but testo2 will write: x: 18446744071562067968, y: 18446744071562067968 What is interesting the problem appears on both architectures: x86_64 (Intel 64-bit) and i386 (Intel 32-bit). We made tests with options -fno-strict-overflow and -fwrapv. Compilation with only -fno-strict-overflow option still generates the code which gives wrong results. Compilation with -fwrapv gived the proper code. But still the behaviour differs from 4.6 version. According to us code x64|=(uint32_t)(some_arithmetic_operations_on_signed_integers_with_overflow) should in no case set high 32 bits of x64 variable independently of options used. Even if overflow result in some_arithmetic_operations_on_signed_integers_with_overflow fragment is not specified, then type casting to uint32_t should never return negative number, which expanded to 64 bits will cause setting high 32 bits of x64 variable. We need to take into account that some_arithmetic_operations_on_signed_integers_with_overflow may return a negative number (even without any overflows), so treatment of overflows should not change anything here - after casting to uint32_t we should always get a 32-bit unsigned number which by the |= operation with 64-bit number with no sign should also expand to 64-bit number with no sign by adding 32 high bits filled with zeros. Even when we assume that the result of some_arithmetic_operations_on_signed_integers_with_overflow has undefined behavior, then after casting it to uint32_t only lower 32 bits should remain undefined but here we can see that the result has also impact on the high bits (even without any warning). What is suspicious compilation behaves in very unpredictable way. The same expression compiled with the same options may give different results. When we change this fragment y = get64bit(rp); to: y = 0; then the second variable x will return proper results. MooseFS Team http://www.moosefs.org/
[Bug target/53854] ICE in find_constant_pool_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854 --- Comment #2 from Ulrich Weigand uweigand at gcc dot gnu.org 2012-07-04 17:17:22 UTC --- The problem with this is that there was a reason why I originally supported only a single constant pool reference per instruction: there needs to be an upper bound on the number of bytes consumed in the text section (code + literals) by a single insn, otherwise the pool chunkify mechanism doesn't work. As an obvious extreme example, if the asm were to refer to more than 4096 bytes of literals, it would be impossible to refer to them all using a single literal pool base pointer. As another obvious extreme example, if the asm *code* were to span more than 4096 bytes, it would be impossible to have even a single literal in the same chunk as the asm and thus be referenced from it (using the current chunkify algorithm). All this is less of an issue in 64-bit code since its much easier to address literals, but we still be should be correct for 31-bit on old machines too ... Why do the literals end up in the pool anyway in your example, as opposed to a register? They did with older compilers; this seems to have changed recently due to different IRA cost computations ... Maybe it would be better to prevent asm statements from generating pool references; it is likely that the asm will expect this to happen anyway?
[Bug c/53857] Possible problem with arithmetic overflow in optimizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53857 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-04 18:03:26 UTC --- some_arithmetic_operations_on_signed_integers_with_overflow Once overflow happens the result is undefined. What is suspicious compilation behaves in very unpredictable way. No it is not, according to the rules of C. As once an undefined behavior has happen, anything goes aftwards
[Bug middle-end/53855] Emitting a warning for use after clobber
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53855 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Component|tree-optimization |middle-end Version|tree-ssa|4.7.0 Summary|Emitting a warning for some |Emitting a warning for use |dangling references.|after clobber --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-04 18:18:19 UTC --- Maybe the C++ front-end could warn about use of temp variables passed to constructors.
[Bug fortran/53851] Automatic silent allocation/deallocation of allocatable variables in several instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53851 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf anlauf at gmx dot de 2012-07-04 19:01:25 UTC --- You just discovered that gfortran supports reallocation on assignment from Fortran 2003. If you don't want that, either use -std=f95 or -fno-realloc-lhs to prevent this. With Intel Fortran, read their manual (see -standard-semantics). Intel Fortran is not standard conforming by default.
[Bug c++/49569] [4.7 regression] -std=gnu++0x causes segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49569 dcb dcb314 at hotmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #4 from dcb dcb314 at hotmail dot com 2012-07-04 19:42:51 UTC --- I just checked trunk-20120704 and this bug seems to have reappeared. Strange, it seemed still fixed as recently as trunk-20120701. Suggest try original source code I supplied.
[Bug c++/49569] [4.7 regression] -std=gnu++0x causes segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49569 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2012-07-04 19:59:28 UTC --- The new failure with the original testcase is the same as PR 53848, a different bug than it was hitting before.
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-04 20:59:09 UTC --- N.B. this is easily reproducable on gcc110 in the compile farm, a powerpc64-unknown-linux-gnu box
[Bug fortran/53851] Automatic silent allocation/deallocation of allocatable variables in several instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53851 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||INVALID --- Comment #2 from kargl at gcc dot gnu.org 2012-07-04 21:17:33 UTC --- As Harald notes, gfortran supports reallocation on assignment, which is a Fortran 2003 feature. He also provides methods to disable this behavior.
[Bug c++/53848] [4.8 regression] ICE in decl_linkage at ../../gcc-trunk/gcc/cp/tree.c:3215
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53848 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2012-07-04 21:34:12 UTC --- Author: jason Date: Wed Jul 4 21:34:07 2012 New Revision: 189267 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189267 Log: PR c++/53848 * decl.c (build_enumerator): Don't use build_lang_decl_loc. Added: trunk/gcc/testsuite/g++.dg/other/enum3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53848] [4.8 regression] ICE in decl_linkage at ../../gcc-trunk/gcc/cp/tree.c:3215
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53848 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2012-07-04 21:43:08 UTC --- Fixed.
[Bug libstdc++/53830] condition_variable_any - deadlock issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53830 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-04 22:17:24 UTC --- Author: redi Date: Wed Jul 4 22:17:18 2012 New Revision: 189268 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189268 Log: PR libstdc++/53830 * include/std/condition_variable (condition_variable_any::wait): Move _Unlock type to class scope. (condition_variable_any::wait_until): Reuse it. * testsuite/30_threads/condition_variable_any/53830.cc: New. Added: trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/53830.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/condition_variable
[Bug libstdc++/53830] condition_variable_any - deadlock issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53830 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-05 00:19:41 UTC --- Author: redi Date: Thu Jul 5 00:19:36 2012 New Revision: 189273 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189273 Log: PR libstdc++/53830 * include/std/condition_variable (condition_variable_any::wait): Move _Unlock type to class scope. (condition_variable_any::wait_until): Reuse it. * testsuite/30_threads/condition_variable_any/53830.cc: New. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/30_threads/condition_variable_any/53830.cc Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/std/condition_variable
[Bug libstdc++/53830] condition_variable_any - deadlock issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53830 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-05 01:10:18 UTC --- Author: redi Date: Thu Jul 5 01:10:10 2012 New Revision: 189275 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189275 Log: PR libstdc++/53830 * include/std/condition_variable (condition_variable_any::wait): Move _Unlock type to class scope. (condition_variable_any::wait_until): Reuse it. * testsuite/30_threads/condition_variable_any/53830.cc: New. Added: branches/gcc-4_6-branch/libstdc++-v3/testsuite/30_threads/condition_variable_any/53830.cc Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/std/condition_variable
[Bug libstdc++/53830] condition_variable_any - deadlock issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53830 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Known to fail||4.6.3, 4.7.1 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-05 01:16:28 UTC --- Fixed for 4.6.4, 4.7.2 and 4.8.0
[Bug c++/53858] New: template aliases used in template parameters default expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53858
Bug #: 53858
Summary: template aliases used in template parameters default
expression
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
gcc-4.8 compile error when template aliases used in template parameters default
expression. There was no error with gcc-4.7.1
---
template typename T struct s0 { typedef T tdef0; };
template typename T struct s1 { typedef T tdef1; };
template typename T using us1 = typename s1T::tdef1;
template typename T, typename TT = typename us1T::tdef0 struct s2 {};
int main () { return 0; }
--
g++ -std=gnu++11 t.cc
t.cc:4:49: error: expected nested-name-specifier
template typename T, typename TT = typename us1T::tdef0 struct s2 {};
^
t.cc:4:49: error: expected ‘’
gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-pre/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.0_pre/work/gcc-4.8.0-/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,go,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.8.0_pre'
Thread model: posix
gcc version 4.8.0-pre 20120704 (experimental) commit
3d02dd733723c41be7c56f814a3072cee1b43ecc (Gentoo 4.8.0_pre)
---
