[Bug middle-end/29239] -fno-strict-aliasing disables restrict

dberlin at dberlin dot org gcc-bugzilla@gcc.gnu.org
Wed Sep 27 02:12:00 GMT 2006



------- Comment #6 from dberlin at gcc dot gnu dot org  2006-09-27 02:11 -------
Subject: Re:  -fno-strict-aliasing disables restrict

On 27 Sep 2006 02:07:50 -0000, acahalan at gmail dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #5 from acahalan at gmail dot com  2006-09-27 02:07 -------
> (In reply to comment #4)
> > Except it is better just to fix your code for aliasing issues.
>
> Yes, and all other bugs should be fixed as well.
>
> This is often impractical. Is there even one large modern
> kernel which is compiled with strict aliasing enabled?
> (not Linux, not FreeBSD, definitely not OpenBSD because
> they patch gcc to have a different default...)

This is irrelevant. If you want to argue about strict-aliasing, again,
please take it to the mailing list (though I do admit Andrew has a
knack for what some woudl consider trolling. He doesn't know when to
leave well enough alone).

>
> > The reason why
> > restrict does not work without strict aliasing is because it needs aliasing
> > sets and the only way to get that is with strict aliasing.
>
> Yes, exactly. That is the bug.
>
> Aliasing sets should be computed. The only affect of -fno-strict-aliasing
> should be to change how non-char data types are handled in that computation.
> The non-char types should be handled as char is normally.
>
We actually do compute aliasing sets without TBAA.
The real problem is that restrict effectively defines "anti-alias" sets.
Sets that say "no matter what you believe, this pointer over here
cannot access the same memory as this pointer over here".
This is what we really need to be computing from the restrict sets,
and one day we shall


-- 


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



More information about the Gcc-bugs mailing list