[Bug tree-optimization/42871] [4.4 Regression] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #15 from jwillemsen at remedy dot nl 2010-02-13 10:03 --- After doing a yum update on FC12 we found that FC12 now also has gcc 4.4.3-4 which also has this bug when compiling ACE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-13 10:11 --- (In reply to comment #3) > Basically yet another example of why it is a REALLY BAD IDEA to use constants > as PHI arguments. If the constant from "s =0" would not be propagated into the > PHI, the statement would not be dead and removed, and no new "s=0" would have > to be inserted in the wrong place. > > See bug 42906 for another example of exactly the same problem. > > Allowing constants as PHI arguments is GCC's biggest design f*ck-up. I'm not sure - do other compilers usually not allow this? It shouldn't be hard to at least disable propagation of constants into PHIs (there may be a number of optimizers generating PHIs with constants initially though). Note that I also see : # s_1 = PHI again and again - shouldn't these be plain assignments as well? Thus, should blocks with a single predecessor have PHIs at all? I suppose with the insertion at the wrong place you mean : # i_2 = PHI <0(2)> # s_11 = PHI <0(2)> as done by the pre-header generated by loop init? (they are dead anyway, but re-generated all the time) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
[Bug target/12395] Suboptimal code with global variables
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-02-13 10:23
---
To optimize
void foo() {
extern int a;
if(++a) ++a;
}
we need to have partial dead store elimination, basically sink the store
to after the condition:
void bar() {
extern int a;
int tmp = a;
if (++tmp)
++tmp;
a = tmp;
}
bar:
movla, %eax
pushl %ebp
movl%esp, %ebp
movl%eax, %edx
addl$1, %edx
je .L5
leal2(%eax), %edx
.L5:
movl%edx, a
popl%ebp
ret
we'd then assemble this to similar code as the testcase from comment #2.
See also PR41490, though a working tree-ssa-sink would at most generate
void foobar() {
extern int a;
int tmp = a;
if (++tmp)
{
++tmp;
a = tmp;
}
else
a = tmp;
}
Still an improvement as we'd propagate zero to the second store:
foobar:
movla, %eax
pushl %ebp
movl%esp, %ebp
cmpl$-1, %eax
jne .L9
movl$0, a
popl%ebp
ret
.p2align 4,,7
.p2align 3
.L9:
addl$2, %eax
movl%eax, a
popl%ebp
ret
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
BugsThisDependsOn||41490
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-02-13 10:23 --- (In reply to comment #21) > (In reply to comment #20) > > What is the plan for this bug, fix it for GCC 4.5.0 or for later? > > I don't really think I can argue that this is stage3 material, so the plan is > to fix it when trunk reopens for 4.6, and I have Richard G's > agreement-in-principle to then backport it from head to the 4.5 branch for > 4.5.1 Yes, that was the idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug java/41802] When attempting to compile pdftk-1.41 my machine comes to a grind
--- Comment #12 from lucabon at interfree dot it 2010-02-13 10:28 --- I upgraded all gcc components to 4.4.3 (before I upgraded only java parts) and it works fine. I downgraded to 4.3.3 and put only libgcc_s.so.1 from gcc 4.4.3 and it works fine. So, the problem was in libgcc_s and it was fixed in gcc 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41802
[Bug java/43055] [4.3/4.4/4.5 Regression'jc1: internal compiler error: Segmentation fault' using gcj -fprofile-arcs
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-13 10:32 --- Also fails for me with 4.3 and trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.3.4 4.4.1 4.5.0 Known to work||4.2.4 Last reconfirmed|-00-00 00:00:00 |2010-02-13 10:32:05 date|| Summary|'jc1: internal compiler |[4.3/4.4/4.5 Regression'jc1: |error: Segmentation fault' |internal compiler error: |using gcj -fprofile-arcs|Segmentation fault' using ||gcj -fprofile-arcs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43055
[Bug java/43055] [4.3/4.4/4.5 Regression] 'jc1: internal compiler error: Segmentation fault' using gcj -fprofile-arcs
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-13 10:35 ---
Program received signal SIGSEGV, Segmentation fault.
0x08158cf6 in coverage_checksum_string (chksum=0, string=0x0)
at /home/richard/src/trunk/gcc/coverage.c:484
484 for (i = 0; string[i]; i++)
Looks like the current function does not have a location.
536 {
537 expanded_location xloc
538 = expand_location (DECL_SOURCE_LOCATION (current_function_decl));
539 unsigned chksum = xloc.line;
540
541 chksum = coverage_checksum_string (chksum, xloc.file);
542 chksum = coverage_checksum_string
543 (chksum, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
(current_function_decl)));
544
545 return chksum;
(gdb) p xloc
$3 = {file = 0x0, line = 0, column = 0, sysp = 0 '\000'}
(gdb) call debug_generic_expr (current_function_decl)
_Jv_global_static_constructor
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3/4.4/4.5 Regression'jc1:|[4.3/4.4/4.5 Regression]
|internal compiler error:|'jc1: internal compiler
|Segmentation fault' using |error: Segmentation fault'
|gcj -fprofile-arcs |using gcj -fprofile-arcs
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43055
[Bug c++/43036] [4.3/4.4/4.5 Regresion] c++ compilation hang
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-13 10:45 --- Confirmed. We loop in 0x0823fa53 in cp_build_qualified_type_real (type=0xb39cbf70, type_quals=1, complain=7) at /home/richard/src/gcc-4_4-branch/gcc/cp/tree.c:781 781 for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t)) (gdb) finish Run till exit from #0 0x0823fa53 in cp_build_qualified_type_real ( type=0xb39cbf70, type_quals=1, complain=7) at /home/richard/src/gcc-4_4-branch/gcc/cp/tree.c:781 for (gdb) call debug_tree (type) (gdb) p type $3 = (tree) 0xb39cbf70 (gdb) p type->type.next_variant $4 = (union tree_node *) 0xb39d0888 (gdb) p type->type.main_variant->type.next_variant->type.next_variant->type.next_variant->type.next_variant->type.next_variant->type.next_variant $9 = (union tree_node *) 0xb39d0888 so we have a cyclic type variant list. Obviously not a too bright idea. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Known to fail||4.3.4 4.4.3 4.5.0 Known to work||4.2.4 Last reconfirmed|-00-00 00:00:00 |2010-02-13 10:45:17 date|| Summary|c++ compilation hang|[4.3/4.4/4.5 Regresion] c++ ||compilation hang Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
[Bug c++/43036] [4.3/4.4/4.5 Regresion] c++ compilation hang
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-02-13 10:48 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
[Bug java/41802] When attempting to compile pdftk-1.41 my machine comes to a grind
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-02-13 10:58 --- (In reply to comment #12) > I upgraded all gcc components to 4.4.3 (before I upgraded only java parts) and > it works fine. I downgraded to 4.3.3 and put only libgcc_s.so.1 from gcc 4.4.3 > and it works fine. So, the problem was in libgcc_s and it was fixed in gcc > 4.4. Exactly as I thought. There is/was an unwinding problem with made garbage collection break, there is a glibc fix available or an unwinder fix in gcc 4.4. Your distributor didn't pick up the glibc fix appearantly. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41802
[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64
--- Comment #9 from steven at gcc dot gnu dot org 2010-02-13 11:28 --- Re. comment #8: No other compiler, I have ever seen, allows constants as PHI args. Single-argument PHIs should be propagated out. Do you see this in one of the loop passes, then it's OK because they are probably there for loop-closed SSA. Anywhere else, they should be propagated out. We even used to do this in a simple CFG cleanup. It looks like something broke this. With "inserting in the wrong place" I mean that insert the new "s = 0" in a different place from where it was originally (which was the optimal place to begin with). We have pessimized the original code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64
--- Comment #10 from steven at gcc dot gnu dot org 2010-02-13 11:39 --- In the test case of comment #2, the history of the funny PHIs is really odd. At -O2 we end with this in the .optimized dump: : # i_1 = PHI <0(2)> # s_11 = PHI <0(2)> : # i_12 = PHI # s_13 = PHI But the history of the phi of i_12 looks like this: t.c.120t.reassoc2: # i_12 = PHI t.c.121t.vrp2: # i_12 = PHI t.c.121t.vrp2: # i_12 = PHI <0(3), i_7(4)> t.c.122t.dom2: # i_12 = PHI <0(3), i_7(4)> t.c.123t.phicprop2: # i_12 = PHI <0(2), i_7(3)> t.c.124t.cddce2: # i_12 = PHI Somehow we have re-introduced the special PHI "# i_1 = PHI <0(2)>" in the .cddce2 pass. The reason is that we created a loop pre-header. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
[Bug java/41802] When attempting to compile pdftk-1.41 my machine comes to a grind
--- Comment #14 from mikpe at it dot uu dot se 2010-02-13 11:52 --- (In reply to comment #13) > Exactly as I thought. There is/was an unwinding problem with made garbage > collection break, there is a glibc fix available or an unwinder fix in gcc > 4.4. > Your distributor didn't pick up the glibc fix appearantly. Do you have the PR numbers or commit dates for the glibc and unwinder fixes? -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41802
[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64
--- Comment #11 from rguenther at suse dot de 2010-02-13 12:07 ---
Subject: Re: [4.5 Regression] gcc.target/mips/octeon-bbit-2.c
failing for -mabi=64
On Sat, 13 Feb 2010, steven at gcc dot gnu dot org wrote:
>
>
> --- Comment #10 from steven at gcc dot gnu dot org 2010-02-13 11:39
> ---
> In the test case of comment #2, the history of the funny PHIs is really odd.
> At
> -O2 we end with this in the .optimized dump:
>
> :
> # i_1 = PHI <0(2)>
> # s_11 = PHI <0(2)>
>
> :
> # i_12 = PHI
> # s_13 = PHI
>
>
> But the history of the phi of i_12 looks like this:
>
> t.c.120t.reassoc2: # i_12 = PHI
> t.c.121t.vrp2: # i_12 = PHI
> t.c.121t.vrp2: # i_12 = PHI <0(3), i_7(4)>
> t.c.122t.dom2: # i_12 = PHI <0(3), i_7(4)>
> t.c.123t.phicprop2: # i_12 = PHI <0(2), i_7(3)>
> t.c.124t.cddce2: # i_12 = PHI
>
> Somehow we have re-introduced the special PHI "# i_1 = PHI <0(2)>" in the
> .cddce2 pass. The reason is that we created a loop pre-header.
Yep. I wonder if cfgcloop should just not do that, and of course
I wonder why cfgcleanup doesn't get rid of single-arg PHIs (well,
probably to not break loop-closed SSA form).
Btw, the following should avoid almost all constant propagations
into PHIs (well, I guess DOM needs fixing as well)
Index: tree-ssa-propagate.c
===
--- tree-ssa-propagate.c(revision 15)
+++ tree-ssa-propagate.c(working copy)
@@ -924,7 +924,9 @@ replace_phi_args_in (gimple phi, prop_va
{
tree val = prop_value[SSA_NAME_VERSION (arg)].value;
- if (val && val != arg && may_propagate_copy (arg, val))
+ if (val && val != arg
+ && TREE_CODE (val) == SSA_NAME
+ && may_propagate_copy (arg, val))
{
if (TREE_CODE (val) != SSA_NAME)
prop_stats.num_const_prop++;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-02-13 12:18
---
Yep.
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 15)
+++ tree-ssa-dom.c (working copy)
@@ -1455,8 +1455,7 @@ cprop_into_successor_phis (basic_block b
new_val = SSA_NAME_VALUE (orig_val);
if (new_val
&& new_val != orig_val
- && (TREE_CODE (new_val) == SSA_NAME
- || is_gimple_min_invariant (new_val))
+ && TREE_CODE (new_val) == SSA_NAME
&& may_propagate_copy (orig_val, new_val))
propagate_value (orig_p, new_val);
}
with that we end up with
g (int n, int i)
{
int s;
:
s_3 = 0;
if (n_5(D) > 0)
goto ;
else
goto ;
:
i_4 = 0;
:
# i_12 = PHI
# s_13 = PHI
s_6 = s_13 + i_12;
i_7 = i_12 + 1;
if (i_7 != n_5(D))
goto ;
else
goto ;
:
# s_9 = PHI
return s_9;
}
tree-ssa-sink sunk i_4 = 0 from bb2 to bb3.
Note that this shows that we may have extra BBs without constants in
PHI nodes.
But if it is more sane to not allow this we can experiment with this
for 4.6 quite easily.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-02-13 12:19 --- But it has a load of fallout already in the gcc.dg/tree-ssa testsuite parts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
[Bug fortran/41113] spurious _gfortran_internal_pack
--- Comment #17 from pault at gcc dot gnu dot org 2010-02-13 12:43 --- Subject: Bug 41113 Author: pault Date: Sat Feb 13 12:42:39 2010 New Revision: 156749 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156749 Log: 2010-02-13 Paul Thomas PR fortran/41113 PR fortran/41117 * trans-array.c (gfc_conv_array_parameter): Use gfc_full_array_ref_p to detect full and contiguous variable arrays. Full array components and contiguous arrays do not need internal_pack and internal_unpack. 2010-02-13 Paul Thomas PR fortran/41113 PR fortran/41117 * gfortran.dg/internal_pack_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/internal_pack_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
[Bug fortran/41117] spurious _gfortran_internal_pack (II)
--- Comment #3 from pault at gcc dot gnu dot org 2010-02-13 12:43 --- Subject: Bug 41117 Author: pault Date: Sat Feb 13 12:42:39 2010 New Revision: 156749 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156749 Log: 2010-02-13 Paul Thomas PR fortran/41113 PR fortran/41117 * trans-array.c (gfc_conv_array_parameter): Use gfc_full_array_ref_p to detect full and contiguous variable arrays. Full array components and contiguous arrays do not need internal_pack and internal_unpack. 2010-02-13 Paul Thomas PR fortran/41113 PR fortran/41117 * gfortran.dg/internal_pack_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/internal_pack_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41117
[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64
--- Comment #14 from steven at gcc dot gnu dot org 2010-02-13 12:44 --- Re. comment #12, if you mean the extra BB3, that one is not really "extra", it comes from loop header copying, and it easy to clean up. I assume ifcvt cleans this up? Re. comment #12, yes that is expected, but most of those failures are easily solved. The bottom line IMHO is this: * propagating constants into PHI args sometimes exposes things, but it conceals more and does irreparable damage * not propagating means we have to work harder in a few places (following SSA_NAME_DEF_STMT in a few places) to avoid missing optimizations, but at least we never make the code worse than the original code (and aoliva would add that we get debug info right if we don't propagate...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
[Bug rtl-optimization/43056] New: __builtin_prefetch causes ICE: in rtl_verify_flow_info, at cfgrtl.c:2205 with -fsched2-use-superblocks
Command line:
gcc -O1 -fschedule-insns2 -fsched2-use-superblocks -c testcase.c
testcase.c
int x[1];
void foo()
{
__builtin_prefetch(x);
}
Tested revisions:
trunk r156745 - crash
trunk r153685 - crash
4.4 r156256 - crash
4.4 r155365 - OK (no checking)
4.4 r149995 - crash
Output:
$ /mnt/svn/gcc-trunk/binary-156745-lto/bin/gcc -O1 -fschedule-insns2
-fsched2-use-superblocks -c testcase.c
testcase.c: In function ‘foo’:
testcase.c:5:1: error: missing barrier after block 2
testcase.c:5:1: error: return not followed by barrier
(jump_insn:TI 11 14 8 2 testcase.c:5 (return) 648 {return_internal} (nil))
testcase.c:5:1: internal compiler error: in rtl_verify_flow_info, at
cfgrtl.c:2205
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Summary: __builtin_prefetch causes ICE: in rtl_verify_flow_info,
at cfgrtl.c:2205 with -fsched2-use-superblocks
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056
[Bug java/41802] When attempting to compile pdftk-1.41 my machine comes to a grind
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-02-13 13:31 --- (In reply to comment #14) > (In reply to comment #13) > > Exactly as I thought. There is/was an unwinding problem with made garbage > > collection break, there is a glibc fix available or an unwinder fix in gcc > > 4.4. > > Your distributor didn't pick up the glibc fix appearantly. > > Do you have the PR numbers or commit dates for the glibc and unwinder fixes? I think this was fixed in the unwinder by 2009-04-04 Jakub Jelinek * unwind-dw2.h (_Unwind_FrameState): Add REG_UNDEFINED enum value. * unwind-dw2.c (execute_cfa_program): Set how to REG_UNDEFINED instead of REG_UNSAVED for DW_CFA_undefined. (uw_update_context_1): Handle REG_UNDEFINED the same as REG_UNSAVED. (uw_update_context): If RA column is REG_UNDEFINED, mark it as outermost frame. and the bug can be avoided in glibc by Wed Jun 25 13:30:42 CEST 2008 - rguent...@suse.de - Add patch to fix unwinding through clone for x86_64 and i386. [bnc#290807, bnc#403464] bnc#403464 contains useful links (that's bugzilla.novell.com), one reference to PR36568 which contains a glibc patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41802
[Bug c++/43036] [4.3/4.4/4.5 Regresion] c++ compilation hang
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-02-13 13:40
---
typedef char T6[2][4 + 4];
typedef unsigned char _CORBA_Char;
class _CORBA_String_member { };
typedef _CORBA_Char Char;
typedef _CORBA_String_member String_member;
typedef String_member st_1d_t[2];
typedef String_member T4[2];
typedef String_member T1[2];
typedef Char char_2_8[2][8];
typedef char T[4 + 4];
void _IF1_a2c_st_1d_t(st_1d_t io, const T6 in);
typedef T T2[2];
void _IF1_a2c_T4(T4 io, const T2 in);
typedef char T7[7 + 1];
typedef T7 T3[2];
typedef char T5[2][8];
void _IF12_a2c_char_2_8(char_2_8 io, const T5 in);
void _IF12_a2c_T1(T1 io, const T3 in);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
[Bug lto/43057] New: [LTO] fold check: original tree changed by fold
GCC 4.5.0 20100211. Configured with --enable-languages=c --enable-checking=all --disable-bootstrap. -- Summary: [LTO] fold check: original tree changed by fold Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43057
[Bug lto/43057] [LTO] fold check: original tree changed by fold
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-02-13 14:27 --- Created an attachment (id=19857) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19857&action=view) Backtrace -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43057
[Bug lto/43057] [LTO] fold check: original tree changed by fold
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-02-13 14:29 --- Created an attachment (id=19858) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19858&action=view) Testcase gcc -O -flto bug.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43057
[Bug tree-optimization/42871] [4.4 Regression] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-02-13 14:51 --- Subject: Bug 42871 Author: rguenth Date: Sat Feb 13 14:50:50 2010 New Revision: 156750 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156750 Log: 2010-02-13 Richard Guenther PR tree-optimization/42871 * tree-ssa-pre.c (phi_translate_set): Make sure to retain leaders. * g++.dg/torture/pr42871.C: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42871.C Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug tree-optimization/42871] [4.4 Regression] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-02-13 14:51 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-02-13 15:41 --- This should probably be a P2 since it causes a regression on darwin which breaks their weak linking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2010-02-13
16:04 ---
This alternative fix works as well...
--- /Users/howarth/gcc-4.5-20100211/gcc/varasm.c2010-01-20
18:46:25.0 -0500
+++ gcc/varasm.c2010-02-13 10:58:45.0 -0500
@@ -2345,7 +2345,8 @@
for declarations that can be weak, it happens to be
match. */
&& !TREE_STATIC (decl)
- && lookup_attribute ("weak", DECL_ATTRIBUTES (decl))
+ && ( lookup_attribute ("weak", DECL_ATTRIBUTES (decl)) ||
+ lookup_attribute ("weak_import", DECL_ATTRIBUTES (decl)))
&& value_member (decl, weak_decls) == NULL_TREE)
weak_decls = tree_cons (NULL, decl, weak_decls);
@@ -5290,9 +5291,11 @@
warning (0, "weak declaration of %q+D not supported", decl);
mark_weak (decl);
+#ifndef ASM_WEAKEN_DECL
if (!lookup_attribute ("weak", DECL_ATTRIBUTES (decl)))
DECL_ATTRIBUTES (decl)
= tree_cons (get_identifier ("weak"), NULL, DECL_ATTRIBUTES (decl));
+#endif
}
static void
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug rtl-optimization/43058] New: [4.5 Regression] var-tracking uses up all virtual memory
/usr/lib64/gcc/x86_64-suse-linux/4.5/cc1 -m32 -fpreprocessed xg.i -quiet -dumpbase xg.c -mtune=generic -march=i586 -auxbase xg -g -O2 -O2 -Wall -version -fomit-frame-pointer -fmessage-length=0 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fno-strict-aliasing -o xg.s --param ggc-min-expand=100 --param ggc-min-heapsize=131072 uses more than 2GB of virtual memory when on a 32bit host (and thus fails to compile). On a 64bit host we top at >3GB (I need to re-try on a host with more memory, I'm swapping to death right now). Related to PR41371, the offender is var-tracking. Without -g we top at 600MB on the 64bit host. I suppose we inline all single-call static functions into Init_libxg which makes it bg (and containing lots of calls). -- Summary: [4.5 Regression] var-tracking uses up all virtual memory Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: memory-hog Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: i?86-linux BugsThisDependsOn: 41371 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-13 19:06 --- Created an attachment (id=19859) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19859&action=view) testcase from snd Testcase from snd. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-13 19:12 --- Indeed. After IPA-inline we have: Init_libxg/4659(4659) @0x7fffef076138 availability:available 65 time, 10 benefit (112338 after inlining) 37 size, 1 benefit (89974 after inlining) needed reachable body externally_visible finalized inlinable called by: calls: scm_c_eval_string/4663 (0.39 per call) scm_c_eval_string/4663 (0.39 per call) scm_c_eval_string/4663 (0.39 per call) scm_c_define/4662 (0.39 per call) scm_from_locale_string/4661 (0.39 per call) scm_add_feature/4660 (0.39 per call) define_strings/4658 (inlined) (0.39 per call) define_atoms/4657 (0.39 per call) define_structs/4654 (0.39 per call) define_functions/4653 (inlined) (0.39 per call) define_doubles/4656 (0.39 per call) define_integers/4655 (inlined) (0.39 per call) scm_set_smob_free/4665 (0.39 per call) scm_make_smob_type/4664 (0.39 per call) And the function-called once dump looks odd to me: Deciding on functions called once: Considering define_strings size 840. Called once from Init_libxg 37 insns. Inlined into Init_libxg which now has 876 size for a net change of -841 size. Considering define_integers size 11078. Called once from Init_libxg 876 insns. Inlined into Init_libxg which now has 11953 size for a net change of -11079 size. I can't believe on this net change. Considering define_doubles size 56. Called once from Init_libxg 11953 insns. Not inlining: --param large-function-growth limit reached. Considering define_functions size 78022. Called once from Init_libxg 11953 insns. Inlined into Init_libxg which now has 89974 size for a net change of -78023 size. what? We refused to inline define_doubles but inline define_functions?? Considering define_atoms size 119. Called once from Init_libxg 89974 insns. Not inlining: --param large-function-growth limit reached. Considering define_structs size 757. Called once from Init_libxg 89974 insns. Not inlining: --param large-function-growth limit reached. Very very odd. Honza? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-13 19:25 ---
limit += limit * PARAM_VALUE (PARAM_LARGE_FUNCTION_GROWTH) / 100;
/* Check the size after inlining against the function limits. But allow
the function to shrink if it went over the limits by forced inlining. */
newsize = cgraph_estimate_size_after_inlining (times, to, what);
if (newsize >= to->global.size
&& newsize > PARAM_VALUE (PARAM_LARGE_FUNCTION_INSNS)
&& newsize > limit)
{
this allows unbounded growth based on PARAM_LARGE_FUNCTION_GROWTH, ignoring
PARAM_LARGE_FUNCTION_INSNS. Shouldn't we at least limit
/* When inlining large function body called once into small function,
take the inlined function as base for limiting the growth. */
if (inline_summary (to)->self_size > inline_summary(what)->self_size)
limit = inline_summary (to)->self_size;
else
limit = inline_summary (what)->self_size;
limit += limit * PARAM_VALUE (PARAM_LARGE_FUNCTION_GROWTH) / 100;
so that limit is at most PARM_LARGE_FUNCTION_INSNS * PARM_LARGE_FUNCTION_GROWTH
/ 100?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-13 19:38 --- With that we get the much more sane Deciding on functions called once: Considering define_strings size 840. Called once from Init_libxg 37 insns. Inlined into Init_libxg which now has 876 size for a net change of -841 size. Considering define_integers size 11078. Called once from Init_libxg 876 insns. Not inlining: --param large-function-growth limit reached. Considering define_doubles size 56. Called once from Init_libxg 876 insns. Inlined into Init_libxg which now has 931 size for a net change of -57 size. Considering define_functions size 78022. Called once from Init_libxg 931 insns. Not inlining: --param large-function-growth limit reached. Considering define_atoms size 119. Called once from Init_libxg 931 insns. Inlined into Init_libxg which now has 1049 size for a net change of -120 size. Considering define_structs size 757. Called once from Init_libxg 1049 insns. Inlined into Init_libxg which now has 1805 size for a net change of -758 size. The problem with the present code is that as long as the function we want to inline is LARGE_FUNCTION_GROWTH percent bigger than the caller we will continue to grow the caller up to infinite size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-13 19:56 --- Of course we'll blow up during var-tracking from within define_functions anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #6 from mikpe at it dot uu dot se 2010-02-13 20:49 --- A bisection through the binutils weekly and daily snapshots has identified 090505 as the last good snapshot and 090506 as the first bad one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug fortran/36932] unneeded temporary (2x)
--- Comment #3 from jv244 at cam dot ac dot uk 2010-02-13 21:13 --- testing Paul's patch (http://gcc.gnu.org/ml/fortran/2010-02/msg00093.html) on CP2K it further halved the number of pack/unpacks. However, some cases still unexpectedly resulted in a pack. A slightly modified version of the original testcase still fails: MODULE M1 IMPLICIT NONE TYPE particle REAL :: r(3) END TYPE CONTAINS SUBROUTINE S1(p) TYPE(particle), POINTER, DIMENSION(:) :: p REAL :: a(3) INTEGER :: i a=pbc(p(i)%r) END SUBROUTINE S1 FUNCTION pbc(a) REAL :: a(3) REAL :: pbc(3) pbc=a END FUNCTION END MODULE M1 here, the only difference is that 'p' has become an argument of 'S1'. -- jv244 at cam dot ac dot uk changed: What|Removed |Added GCC build triplet||pault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36932
[Bug fortran/36932] unneeded temporary (2x)
--- Comment #4 from jv244 at cam dot ac dot uk 2010-02-13 21:14 --- mv 'Build' to 'CC' , Paul, please see previous comment. -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||pault at gcc dot gnu dot org GCC build triplet|pault | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36932
[Bug rtl-optimization/43056] __builtin_prefetch causes ICE: in rtl_verify_flow_info, at cfgrtl.c:2205 with -fsched2-use-superblocks
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-13 23:09:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056
[Bug rtl-optimization/43056] __builtin_prefetch causes ICE: in rtl_verify_flow_info, at cfgrtl.c:2205 with -fsched2-use-superblocks
--- Comment #1 from steven at gcc dot gnu dot org 2010-02-13 23:18 --- Breakpoint 7, rest_of_handle_sched2 () at ../../trunk/gcc/sched-rgn.c:3534 3534 && ! maybe_skip_selective_scheduling ()) (gdb) p brief_dump_cfg(stderr) Basic block 2 (reachable, rtl) Predecessors: ENTRY [100.0%] (fallthru) Successors: EXIT [100.0%] The .split4 dump (just before .sched2): ;; Function foo (foo) 1 NOTE_INSN_DELETED 3 NOTE_INSN_BASIC_BLOCK 9 NOTE_INSN_PROLOGUE_END 2 NOTE_INSN_FUNCTION_BEG 5 prefetch(`x',0x0,0x3) 10 NOTE_INSN_EPILOGUE_BEG 11 return i 12: barrier 8 NOTE_INSN_DELETED And the .sched2 dump: changing bb of uid 13 unscanned insn changing bb of uid 5 from 2 to 3 deleting block 3 1 NOTE_INSN_DELETED 3 NOTE_INSN_BASIC_BLOCK 9 NOTE_INSN_PROLOGUE_END 2 NOTE_INSN_FUNCTION_BEG 14 NOTE_INSN_EPILOGUE_BEG 11 return 8 NOTE_INSN_DELETED What insn 13? What basic block 3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056
[Bug rtl-optimization/43056] __builtin_prefetch causes ICE: in rtl_verify_flow_info, at cfgrtl.c:2205 with -fsched2-use-superblocks
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-13 23:29 --- This is a gem, the scheduler attempts to schedule the prefetch *after* the return. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056
[Bug libstdc++/27198] fstream is using fopen underly for 32b applictaions
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-13 23:45 --- I gather that SUN fixed this problem more than 2 years ago, in Solaris 10 Update 4, see eg: http://blogs.sun.com/mandalika/entry/solaris_workaround_to_stdio_s Given that, I'm going to mark this as WONTFIX for older Solaris releases. We may reconsider the issue when the ABI will be broken. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27198
[Bug libstdc++/15047] libstdc++ testing does not work remotely
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-13 23:55 --- Any progress on this? Should be really kept open after almost 6 years of inactivity? Thanks for any update. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15047
[Bug rtl-optimization/43056] __builtin_prefetch causes ICE: in rtl_verify_flow_info, at cfgrtl.c:2205 with -fsched2-use-superblocks
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-14 00:07 ---
User prefetches should never be scheduled. Andreas Krebbel posted a patch
towards that (http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00130.html) but he
hasn't followed up on it, so far.
Of course, in very rare corner cases, it is possible to have a non-user
prefetch and then all other code removed as dead. To handle this situation,
sched-ebb.c should not move the barrier after the jump into a new basic block.
But I don't know if this is the responsibility of the CFGRTL modification
interface, or of the user of this interface. If the latter, the following patch
would be necessary:
Index: sched-ebb.c
===
--- sched-ebb.c (revision 156750)
+++ sched-ebb.c (working copy)
@@ -174,8 +174,13 @@
gcc_assert (NOTE_INSN_BASIC_BLOCK_P (BB_END (bb)));
}
else
- /* Create an empty unreachable block after the INSN. */
- bb = create_basic_block (NEXT_INSN (insn), NULL_RTX, last_bb);
+ {
+ /* Create an empty unreachable block after the INSN. */
+ rtx head = NEXT_INSN (insn);
+ while (head && BARRIER_P (head))
+ head = NEXT_INSN (head);
+ bb = create_basic_block (head, NULL_RTX, last_bb);
+ }
/* split_edge () creates BB before E->DEST. Keep in mind, that
this operation extends scheduling region till the end of BB.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||krebbel at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056
[Bug c++/43036] [4.3/4.4/4.5 Regresion] c++ compilation hang
--- Comment #12 from hjl dot tools at gmail dot com 2010-02-14 01:21 --- It is caused by revision 132242: http://gcc.gnu.org/ml/gcc-cvs/2008-02/msg00254.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||doug dot gregor at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
[Bug libstdc++/15047] libstdc++ testing does not work remotely
--- Comment #13 from joseph at codesourcery dot com 2010-02-14 02:07 --- Subject: Re: libstdc++ testing does not work remotely Given the right board file and site.exp, installed libstdc++ testing works fine for both remote host and remote target (modulo one installed testing bug: bug 23867) and has done so for some time, but I don't know about build-tree testing which is what this bug report seems to be about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15047
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-02-14 02:12 --- Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00532.html and testsuite resuilts for proposed patch at http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg01258.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug c++/41997] [C++0x] constant initializer_list not optimised
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-10 08:28:00 |2010-02-14 05:56:43 date|| Version|4.5.0 |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41997
[Bug c/43059] New: Unstable behavior of --include option with gcc
Please look at the interesting behavior of gcc
//a.c
int main(void)
{
print("Hello world\n");
return 0;
}
//header.h
#include
void print(char *);
void print(char *s)
{
printf("%s",s);
}
[r...@localhost JAVA]# gcc a.c -include header.h
[r...@localhost JAVA]# ./a.out
Hello world
[r...@localhost JAVA]# rm -f a.out
[r...@localhost JAVA]# gcc a.c --include header.h
[r...@localhost JAVA]# ./a.out
Hello world
[r...@localhost JAVA]# rm -f a.out
[r...@localhost JAVA]# gcc a.c -includeheader.h
[r...@localhost JAVA]# ./a.out
Hello world
[r...@localhost JAVA]# rm -f a.out
[r...@localhost JAVA]# gcc a.c --includeheader.h
cc1: error: unrecognized command line option "-fincludeheader.h"
[r...@localhost JAVA]#
--
Summary: Unstable behavior of --include option with gcc
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: RaghwendraKumar dot M at hcl dot in
GCC host triplet: OS: CentOS(Linux localhost.localdomain 2.6.9-55.EL #1
Wed May 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43059
