This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix aliasing miscompilation
On Tue, Oct 24, 2000 at 08:13:57AM -0700, Mark Mitchell wrote:
> >>>>> "Jakub" == Jakub Jelinek <email@example.com> writes:
> Jakub> Hi!
> Jakub> The following testcase is miscompiled with -O2 on i386. The
> Jakub> reason is that when the __restrict keyword is applied to
> Jakub> the pointer to incomplete struct a, get_alias_set sets up
> Jakub> alias for struct a as whole but record_component_aliases is
> Jakub> never called on that type once it is layout out fully (the
> Jakub> testcase does not fail even without this patch if baz
> Jakub> prototype is moved after struct a full declaration or if
> Jakub> the __restrict keyword is removed from baz prototype). The
> Jakub> patch below seems to fix it. I'm not testing
> Jakub> flag_strict_aliasing because then the alias set is either 0
> Jakub> or -1. Ok to commit?
> Jakub> 2000-10-24 Jakub Jelinek <firstname.lastname@example.org>
> Jakub> * stor-layout.c (layout_type): Call
> Jakub> record_component_aliases if TYPE_ALIAS_SET was already set
> Jakub> on the incomplete type.
> There was historical discussion about this. Your patch is incorrect
> because some front-ends (C++) continue to modify the type after
> What would be safe would be to reset TYPE_ALIAS_SET to -1 at that
> point, I think.
If you set it back to -1, it means the restricted pointer now points to an
alias set which is a subset of never used alias set, so the end result will
be that gcc will assume the restricted pointer cannot ever alias any
aggregate of the type it points to, which is bad.
So, shouldn't alias.c define a new function which would do exactly what I
did in layout_type and frontends would need to call this when they are
really finished with type layout?