------- 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
