[Bug middle-end/44882] [4.6 Regression] Failed to build 416.gamess in SPEC CPU 2006

["rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #4 from rguenth at gcc dot gnu dot org  2010-07-09 08:33 -------
So we have

 <array_ref 0x7ffff7f0c240
    type <real_type 0x7ffff7ef1000 real(kind=4) SF
        size <integer_cst 0x7ffff7ed2708 constant 32>
        unit size <integer_cst 0x7ffff7ed2410 constant 4>
        align 32 symtab 0 alias set 2 canonical type 0x7ffff7ef1000 precision
32
        pointer_to_this <pointer_type 0x7ffff7ef11f8>>

    arg 0 <component_ref 0x7ffff7ee1400
        type <array_type 0x7ffff7fc8c78 type <real_type 0x7ffff7ef1000
real(kind=4)>
            type_2 BLK
            size <integer_cst 0x7ffff7fbe500 constant 320>
            unit size <integer_cst 0x7ffff7fbe668 constant 40>
            align 32 symtab 0 alias set 2 canonical type 0x7ffff7fc8c78 domain
<integer_type 0x7ffff7fcb000>
            pointer_to_this <pointer_type 0x7ffff7fcba80>>

        arg 0 <var_decl 0x7ffff7fcc000 trupar type <record_type 0x7ffff5ad9888>
            addressable public static ignored common decl_3 BLK defer-output
file t.f90 line 2 col 0
            size <integer_cst 0x7ffff7fcd2d0 constant 7040>
            unit size <integer_cst 0x7ffff7fcd280 constant 880>
            align 128 context <function_decl 0x7ffff7fc9c00 trudge> chain
<function_decl 0x7ffff7fc9c00 trudge>>
        arg 1 <field_decl 0x7ffff7fc6720 dr type <array_type 0x7ffff7fc8c78>
            BLK file t.f90 line 2 col 0 size <integer_cst 0x7ffff7fbe500 320>
unit size <integer_cst 0x7ffff7fbe668 40>
            align 32 offset_align 128
            offset <integer_cst 0x7ffff7ed2438 constant 0>
            bit offset <integer_cst 0x7ffff7ed2b40 constant 0> context
<record_type 0x7ffff7fcb930> chain <field_decl 0x7ffff7fc67b8 v>>>
    arg 1 <ssa_name 0x7ffff7fcf528
        type <integer_type 0x7ffff7ee45e8 integer(kind=8) public DI
            size <integer_cst 0x7ffff7ed27d0 constant 64>
            unit size <integer_cst 0x7ffff7ed27f8 constant 8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff7ee45e8
precision 64 min <integer_cst 0x7ffff7ed2758 -9223372036854775808> max
<integer_cst 0x7ffff7ed2780 9223372036854775807>
            pointer_to_this <pointer_type 0x7ffff7f235e8>>
        visited var <var_decl 0x7ffff7fcc6e0 D.1580>def_stmt D.1580_6 =
D.1579_5 + -1;

        version 6>>

and the record type is

 <record_type 0x7ffff5ad9888 BLK
    size <integer_cst 0x7ffff7fcd2d0 type <integer_type 0x7ffff7ee40a8
bit_size_type> constant 7040>
    unit size <integer_cst 0x7ffff7fcd280 type <integer_type 0x7ffff7ee4000>
constant 880>
    align 64 symtab 0 alias set 3 canonical type 0x7ffff5ad9888
    fields <field_decl 0x7ffff7fc6850 dx
        type <array_type 0x7ffff7fcbbd0 type <real_type 0x7ffff7ef10a8
real(kind=8)>


see how we are accessing trupar.dr as if it were an array of floats while
the structure type has an array of doubles as elements.

That is going to wreck TBAA.

Now, we could silently continue instead of ICEing here if using MEM_REFs.
The assert we have is basically, for the original access
trupar.dr[D.1580_6], assert that the outermost access alias-set conflicts
with the alias-set of the base object (trupar).  Which it does always
due to record_component_aliases --- iff the types were not wrecked in the
first place.

Thus, I'm simply going to remove the assert.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882