[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop

["jakub at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #27 from jakub at gcc dot gnu dot org  2007-09-11 17:21 -------
Created an attachment (id=14191)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14191&action=view)
gcc43-pr33136.patch

Updated patch which tries to handle SFTs as well.
Unfortunately it causes a regression with gcc.dg/torture/pr26587.c at -O2 and
above.  That to me looks like an ipa-type-escape.c bug.
In particular, may_alias_p is now called with a SFT whose type is ARRAY_TYPE.
The first argument to ipa_type_escape_does_not_clobber_p is
 <record_type 0x2aaaaea4f1a0 type_0 BLK
    size <integer_cst 0x2aaaae941b40 type <integer_type 0x2aaaae9340d0
bit_size_type> constant invariant 576>
    unit size <integer_cst 0x2aaaaea4e150 type <integer_type 0x2aaaae934000
long unsigned int> constant invariant 72>
    align 32 symtab 0 alias set -1 canonical type 0x2aaaaea4f1a0
    fields <field_decl 0x2aaaae9f10b0 P
        type <array_type 0x2aaaaea4f0d0 BF_key type <integer_type
0x2aaaaea39a90 BF_word>
            BLK size <integer_cst 0x2aaaae941b40 576> unit size <integer_cst
0x2aaaaea4e150 72>
            align 32 symtab 0 alias set -1 canonical type 0x2aaaaea39ea0 domain
<integer_type 0x2aaaaea39b60>
            pointer_to_this <pointer_type 0x2aaaaea4f410>>
        BLK file pr26587.c line 8 size <integer_cst 0x2aaaae941b40 576> unit
size <integer_cst 0x2aaaaea4e150 72>
        align 32 offset_align 128
        offset <integer_cst 0x2aaaae925750 constant invariant 0>
        bit offset <integer_cst 0x2aaaae9413f0 constant invariant 0> context
<record_type 0x2aaaaea4f1a0>> context <translation_unit_decl 0x2aaaaea4f750
D.1521>
    pointer_to_this <pointer_type 0x2aaaaea4f820> chain <type_decl
0x2aaaaea4f270 D.1500>>
and the second is
 <array_type 0x2aaaaea4f0d0 BF_key
    type <integer_type 0x2aaaaea39a90 BF_word sizes-gimplified public unsigned
SI
        size <integer_cst 0x2aaaae925ab0 constant invariant 32>
        unit size <integer_cst 0x2aaaae925720 constant invariant 4>
        align 32 symtab 0 alias set -1 canonical type 0x2aaaae934680 precision
32 min <integer_cst 0x2aaaae925ae0 0> max <integer_cst 0x2aaaae925a80
4294967295>
        pointer_to_this <pointer_type 0x2aaaaea39d00>>
    BLK
    size <integer_cst 0x2aaaae941b40 type <integer_type 0x2aaaae9340d0
bit_size_type> constant invariant 576>
    unit size <integer_cst 0x2aaaaea4e150 type <integer_type 0x2aaaae934000
long unsigned int> constant invariant 72>
    align 32 symtab 0 alias set -1 canonical type 0x2aaaaea39ea0
    domain <integer_type 0x2aaaaea39b60
        type <integer_type 0x2aaaae934000 long unsigned int public unsigned
sizetype DI
            size <integer_cst 0x2aaaae925ba0 constant invariant 64>
            unit size <integer_cst 0x2aaaae925bd0 constant invariant 8>
            align 64 symtab 0 alias set -1 canonical type 0x2aaaae942270
precision 64 min <integer_cst 0x2aaaae925c00 0> max <integer_cst 0x2aaaae9414e0
-1>>
        public DI size <integer_cst 0x2aaaae925ba0 64> unit size <integer_cst
0x2aaaae925bd0 8>
        align 64 symtab 0 alias set -1 canonical type 0x2aaaaea39b60 precision
64 min <integer_cst 0x2aaaae925750 0> max <integer_cst 0x2aaaaea4e090 17>>
    pointer_to_this <pointer_type 0x2aaaaea4f410>>

ipa_type_escape_field_does_not_clobber_p calls get_canon_type_uid (, true,
true)
on this, which returns TYPE_UID of an unsigned int.
But if I check what actually mark_interesting_addressof marked, it is TYPE_UID
of a different ARRAY_TYPE - 
 <array_type 0x2aaaaea39c30
    type <integer_type 0x2aaaaea39a90 BF_word sizes-gimplified public unsigned
SI
        size <integer_cst 0x2aaaae925ab0 constant invariant 32>
        unit size <integer_cst 0x2aaaae925720 constant invariant 4>
        align 32 symtab 0 alias set -1 canonical type 0x2aaaae934680 precision
32 min <integer_cst 0x2aaaae925ae0 0> max <integer_cst 0x2aaaae925a80
4294967295>
        pointer_to_this <pointer_type 0x2aaaaea39d00>>
    BLK
    size <integer_cst 0x2aaaae941b40 type <integer_type 0x2aaaae9340d0
bit_size_type> constant invariant 576>
    unit size <integer_cst 0x2aaaaea4e150 type <integer_type 0x2aaaae934000
long unsigned int> constant invariant 72>
    align 32 symtab 0 alias set 2 canonical type 0x2aaaaea39ea0
    domain <integer_type 0x2aaaaea39b60
        type <integer_type 0x2aaaae934000 long unsigned int public unsigned
sizetype DI
            size <integer_cst 0x2aaaae925ba0 constant invariant 64>
            unit size <integer_cst 0x2aaaae925bd0 constant invariant 8>
            align 64 symtab 0 alias set -1 canonical type 0x2aaaae942270
precision 64 min <integer_cst 0x2aaaae925c00 0> max <integer_cst 0x2aaaae9414e0
-1>>
        public DI size <integer_cst 0x2aaaae925ba0 64> unit size <integer_cst
0x2aaaae925bd0 8>
        align 64 symtab 0 alias set -1 canonical type 0x2aaaaea39b60 precision
64 min <integer_cst 0x2aaaae925750 0> max <integer_cst 0x2aaaaea4e090 17>>>
so very different uid, and nothing actually ensures that if this type has been
marked that e.g. what it sees through has been marked as well.


-- 


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