------- 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 <[EMAIL PROTECTED]> 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
