Bug 40464 - [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above
Summary: [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler erro...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.5.0
: P2 normal
Target Milestone: 4.5.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 41250
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-16 18:00 UTC by John David Anglin
Modified: 2010-04-06 13:29 UTC (History)
3 users (show)

See Also:
Host: hppa*-*-* (32-bit)
Target: hppa*-*-* (32-bit)
Build: hppa*-*-* (32-bit)
Known to work:
Known to fail:
Last reconfirmed: 2009-08-04 16:54:23


Attachments
pr34099.ii.gz (68.53 KB, application/x-gunzip)
2009-07-29 13:08 UTC, dave
Details
pr34099.ii.132t.optimized.sra (510 bytes, text/plain)
2009-07-29 16:02 UTC, dave
Details
workaround patch (617 bytes, patch)
2009-08-06 17:31 UTC, Martin Jambor
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John David Anglin 2009-06-16 18:00:42 UTC
Executing on host: /home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/g++/../../g++ -B/
home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/g++/../../ /home/dave/gnu/gcc-4.5/gcc
/gcc/testsuite/g++.dg/torture/pr34099.C  -nostdinc++ -I/home/dave/gnu/gcc-4.5/ob
jdir/hppa-linux/libstdc++-v3/include/hppa-linux -I/home/dave/gnu/gcc-4.5/objdir/
hppa-linux/libstdc++-v3/include -I/home/dave/gnu/gcc-4.5/gcc/libstdc++-v3/libsup
c++ -I/home/dave/gnu/gcc-4.5/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/
gcc-4.5/gcc/libstdc++-v3/testsuite/util -fmessage-length=0  -O1      -L/home/dav
e/gnu/gcc-4.5/objdir/hppa-linux/./libstdc++-v3/src/.libs  -L/home/dave/gnu/gcc-4
.5/objdir/hppa-linux/./libstdc++-v3/src/.libs -L/home/dave/gnu/gcc-4.5/objdir/hp
pa-linux/./libiberty  -lm   -o ./pr34099.exe    (timeout = 300)
/home/dave/gnu/gcc-4.5/gcc/gcc/testsuite/g++.dg/torture/pr34099.C: In function '
void multiply(NumType, NumType, unsigned int, NumType&)':
/home/dave/gnu/gcc-4.5/gcc/gcc/testsuite/g++.dg/torture/pr34099.C:8:1: internal
compiler error: in make_decl_rtl, at varasm.c:1309
Please submit a full bug report,
(gdb) p debug_tree (decl)
 <var_decl 0x40d586c0 b.86
    type <record_type 0x40d614d0 NumType sizes-gimplified needs-constructing type_1 type_5 type_6 DC
        size <integer_cst 0x4010b7a0 constant 128>
        unit size <integer_cst 0x4010b7c0 constant 16>
        align 64 symtab 0 alias set -1 canonical type 0x40caaa80
        fields <field_decl 0x40d22c00 _M_value type <complex_type 0x40d303f0 _ComplexT>
            used private nonlocal decl_3 DC file /home/dave/gnu/gcc-4.5/objdir/hppa-linux/libstdc++-v3/include/complex line 1302 col 17 size <integer_cst 0x4010b7a0 128> unit size <integer_cst 0x4010b7c0 16>
            align 64 offset_align 64
            offset <integer_cst 0x4010b320 constant 0>
            bit offset <integer_cst 0x4010b8e0 constant 0> context <record_type 0x40caaa80 complex> chain <type_decl 0x40d301c0 complex>> context <namespace_decl 0x4011b770 std>
        full-name "struct NumType"
        needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=2 interface-unknown
        pointer_to_this <pointer_type 0x40d61690> reference_to_this <reference_type 0x40d61540> chain <type_decl 0x40caaaf0 complex>>
    used DC file /home/dave/gnu/gcc-4.5/gcc/gcc/testsuite/g++.dg/torture/pr34099.C line 8 col 1 size <integer_cst 0x4010b7a0 128> unit size <integer_cst 0x4010b7c0 16>
    align 64 context <function_decl 0x40d5c680 multiply> chain <var_decl 0x40d58720 D.24731>>
(gdb) bt
#0  make_decl_rtl (decl=0x40d586c0) at ../../gcc/gcc/varasm.c:1305
#1  0x0031be04 in expand_expr_real_1 (exp=0x40d586c0, target=0x0,
    tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
    at ../../gcc/gcc/expr.c:7358
#2  0x00309ae4 in expand_expr_real (exp=0x40d586c0, target=0x0,
    tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
    at ../../gcc/gcc/expr.c:7183
#3  0x00315624 in expand_expr_real_1 (exp=0x40d7b230, target=0x0,
    tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
    at ../../gcc/gcc/expr.h:542
#4  0x00309a38 in expand_expr_real (exp=0x40d7b230,
    target=<value optimized out>, tmode=<value optimized out>,
    modifier=<value optimized out>, alt_rtl=0x0) at ../../gcc/gcc/expr.c:7177
#5  0x00318c9c in expand_expr_real_1 (exp=0x40d78ba0, target=0x40d72f60,
    tmode=DFmode, modifier=EXPAND_NORMAL, alt_rtl=0xfb02da88)
    at ../../gcc/gcc/expr.h:548
#6  0x00309a38 in expand_expr_real (exp=0x40d78ba0,
    target=<value optimized out>, tmode=<value optimized out>,
    modifier=<value optimized out>, alt_rtl=0xfb02da88)
    at ../../gcc/gcc/expr.c:7177
#7  0x0030f668 in store_expr (exp=0x40d78ba0, target=0x40d72f60,
    call_param_p=0, nontemporal=0 '\0') at ../../gcc/gcc/expr.c:4644
#8  0x0031160c in expand_assignment (to=0x40d76188, from=0x40d78ba0,
---Type <return> to continue, or q <return> to quit---
    nontemporal=0 '\0') at ../../gcc/gcc/expr.c:4428
#9  0x003183f0 in expand_expr_real_1 (exp=0x40d7bc58,
    target=<value optimized out>, tmode=VOIDmode, modifier=EXPAND_NORMAL,
    alt_rtl=0x0) at ../../gcc/gcc/expr.c:9296
#10 0x00309a38 in expand_expr_real (exp=0x40d7bc58,
    target=<value optimized out>, tmode=<value optimized out>,
    modifier=<value optimized out>, alt_rtl=0x0) at ../../gcc/gcc/expr.c:7177
#11 0x0050325c in expand_expr_stmt (exp=0x40d586c0) at ../../gcc/gcc/expr.h:542
#12 0x0071a1cc in expand_gimple_basic_block (bb=0x40d08bd0)
    at ../../gcc/gcc/cfgexpand.c:2146
#13 0x0071b7ec in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:2586
#14 0x00457488 in execute_one_pass (pass=0x978f58)
    at ../../gcc/gcc/passes.c:1290
#15 0x00457744 in execute_pass_list (pass=0x978f58)
    at ../../gcc/gcc/passes.c:1339
#16 0x0056a580 in tree_rest_of_compilation (fndecl=0x40d5c680)
    at ../../gcc/gcc/tree-optimize.c:394
#17 0x006b2208 in cgraph_expand_function (node=0x40d4ff00)
    at ../../gcc/gcc/cgraphunit.c:1097
#18 0x006b4434 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1156
#19 0x00119158 in cp_write_global_declarations ()
    at ../../gcc/gcc/cp/decl2.c:3642
#20 0x0051404c in toplev_main (argc=25, argv=0xfb02d01c)
---Type <return> to continue, or q <return> to quit---
    at ../../gcc/gcc/toplev.c:1044
#21 0x404c75a4 in __libc_start_main () from /lib/libc.so.6
#22 0x00067978 in _start ()

dave@hiauly6:~/gnu/gcc-4.5/objdir/gcc$ ./xgcc -B./ -v
Reading specs from ./specs
Target: hppa-linux
Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --prefix=/home/dave/opt/gnu/gcc/gcc-4.4.0 --with-local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu --enable-java-gc=boehm --enable-java-awt=xlib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada
Thread model: posix
gcc version 4.5.0 20090616 (experimental) [trunk revision 148510] (GCC)
Comment 1 John David Anglin 2009-07-29 01:29:45 UTC
Introduced in revision 147980 (SRA).
Comment 2 Martin Jambor 2009-07-29 09:27:38 UTC
Can you please try this with -fno-tree-sra?  If you have a revision
earlier than 147980 (new SRA) at hand, can you try that with
-fno-tree-sra?  Thanks.

I'll try to reproduce this on gcc61 at the compile farm but it's gonna
take time to build (and I will be only able to help you if the bug is
indeed caused by SRA - there have been already cases where the old SRA
merely hid some bugs elsewhere).
Comment 3 dave 2009-07-29 13:08:26 UTC
Subject: Re:  [4.5 Regression] FAIL:
	g++.dg/torture/pr34099.C  -O1  (internal compiler error) at -O1 and
	above

> Can you please try this with -fno-tree-sra?  If you have a revision
> earlier than 147980 (new SRA) at hand, can you try that with
> -fno-tree-sra?  Thanks.

The testcase compiles without an ICE using -fno-tree-sra with 147980.
I'll rebuild 147979.

Dave
Comment 4 dave 2009-07-29 13:08:27 UTC
Created attachment 18268 [details]
pr34099.ii.gz
Comment 5 dave 2009-07-29 16:02:29 UTC
Subject: Re:  [4.5 Regression] FAIL:
	g++.dg/torture/pr34099.C  -O1  (internal compiler error) at -O1 and
	above

Attached tree dump.

Dave
Comment 6 dave 2009-07-29 16:02:29 UTC
Created attachment 18269 [details]
pr34099.ii.132t.optimized.sra
Comment 7 John David Anglin 2009-07-29 17:09:46 UTC
In the 'ch' pass, we have:

<bb 2>:
  a.85 = a;
  SR.155_25 = b._M_value;
  ...

This gets transformed in the 'cplxlower' pass to

<bb 2>:
  a.85 = a;
  SR.155$real_7 = REALPART_EXPR <b.86._M_value>;
  SR.155$imag_1 = IMAGPART_EXPR <b.86._M_value>;

However, b.86 is not declared or assigned in the gimple.

Comment 8 Martin Jambor 2009-08-04 16:54:23 UTC
Right. The number in identifiers I see are different, of course, but
what happens is this.  Early SRA replaces structure b.3 with
SR.4_25. In BB2, it is assigned into from parameter b:

  SR.4_25 = b._M_value;

This assignment survives until complex lowering which expands it into:

  SR.4$real_7 = REALPART_EXPR <b.3._M_value>;
  SR.4$imag_1 = IMAGPART_EXPR <b.3._M_value>;
  SR.4_25 = COMPLEX_EXPR <SR.4$real_7, SR.4$imag_1>;

Note that the b.3 is back, although it should have died long time
ago and that leads to the varasm ICE.

What is even more weird however, is how tree-complex.c comes upon that
variable.  In extract_component() it correctly builds rhs
REALPART_EXPR <b._M_value> but then it feeds it into
force_gimple_operand_gsi() which in turns inserts the bogus statements
into the stream.

So that is where to look now, I suppose.  I wonder how come the
behavior is target specific, though.  Well, let me see.
Comment 9 Martin Jambor 2009-08-05 20:51:20 UTC
The long-dead declaration is brought back to life by the following
line in gimplify_var_or_parm_decl() in gimplify.c:

      tree value_expr = DECL_VALUE_EXPR (decl);

I don't know why that happens yet.
Comment 10 Martin Jambor 2009-08-06 17:31:29 UTC
Created attachment 18311 [details]
workaround patch

I still  believe that the  gimplifier should not do  this substitution
this late in  the compilation.  However, since I do  not have time nor
am I brave enough to attempt to fix it there, I at least tried to make
sure that SRA does not create  situations which lead to this error and
the attached patch is the result of that effort.  I am currently
bootstrapping it on an x86_64.

However, it  should be noted that it  comes at a slight  cost, both in
run  time as this  leads to  less structure  copy propagation  (and at
least java uses DECL_VALUE_EXPR even on x86_64, I believe) and compile
time, as we  have to check for it  everywhere.  Moreover, every single
user  of force_gimple_operand  is  still  at risk  of  running into  a
problem like this.
Comment 11 Martin Jambor 2009-08-06 17:55:10 UTC
Patch posted to mailing list: 
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00367.html
Comment 12 Martin Jambor 2009-09-03 19:09:08 UTC
As Richard Henderson pointed out, declarations with DECL_VALUE_EXPR
should not appear in the function body at all.  I have filed bug 41250
about this.
Comment 13 Richard Biener 2010-04-06 11:20:24 UTC
GCC 4.5.0 is being released.  Deferring to 4.5.1.
Comment 14 Martin Jambor 2010-04-06 13:22:05 UTC
I don't see this failure in any of the recent retest results of hppa
(I've looked at http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00422.html
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00417.html and
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00410.html).
Therefore I think that it is fixed by the fix for PR 41250.  Please
reopen if I am wrong.
Comment 15 Richard Biener 2010-04-06 13:29:05 UTC
For 4.5.0.