This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: -fstrict-aliasing fixes 5/6: make type system independent of flag_strict_aliasing
- From: Richard Biener <rguenther at suse dot de>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 8 Dec 2015 13:18:55 +0100 (CET)
- Subject: Re: -fstrict-aliasing fixes 5/6: make type system independent of flag_strict_aliasing
- Authentication-results: sourceware.org; auth=none
- References: <20151202080716 dot GV5527 at kam dot mff dot cuni dot cz> <20151207185408 dot GC10655 at kam dot mff dot cuni dot cz> <20151207194913 dot GB45133 at kam dot mff dot cuni dot cz> <17259092 dot 9bGTEO9jER at polaris>
On Tue, 8 Dec 2015, Eric Botcazou wrote:
> > The problem is with the type:
> > (gdb) p debug_tree (p)
> > <pointer_type 0x7ffff6af02a0 type <pointer_type 0x7ffff6af02a0>
> > sizes-gimplified public visited unsigned DI
> > size <integer_cst 0x7ffff6ad7bb8 type <integer_type 0x7ffff6adb2a0
> > bitsizetype> constant visited 64> unit size <integer_cst 0x7ffff6ad7bd0
> > type <integer_type 0x7ffff6adb1f8 sizetype> constant visited 8> align 64
> > symtab 0 alias set -1 canonical type 0x7ffff6af02a0
> > pointer_to_this <pointer_type 0x7ffff6af02a0>>
> >
> > it is a recursive pointer to itself. Does this make sense in Ada? If so we
> > will need to add a recursion guard into the loop and put the alias set into
> > voidptr_alias_set. It more looks like a frontend bug to me - I can not
> > think of a use for this beast.
>
> This one (access1) is admittedly border line and we can probably kludge around
> it in the front-end, but what about access2 and more generally pointer cycles?
Usually cycles happen through structure members and it might be that
all other frontends have the pointed-to type incomplete. But the
above recursion shouldn't apply for the structure case.
Not sure how your other examples look like.