[Bug middle-end/29239] -fno-strict-aliasing disables restrict
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 --- This boils down to restrict being implemented as a different alias-set instead of as points-to information. Dup of PR14187. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29239
[Bug middle-end/29239] -fno-strict-aliasing disables restrict
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-30 23:37 --- Also it should be noted before strict aliasing came about, restrict did nothing in the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29239
[Bug middle-end/29239] -fno-strict-aliasing disables restrict
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-26 20:28 --- And this is not a bug, restrict can be ignored by a compiler in terms of optimization which is what is happening with -fno-strict-aliasing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29239
[Bug middle-end/29239] -fno-strict-aliasing disables restrict
--- Comment #2 from joseph at codesourcery dot com 2006-09-26 21:01 --- Subject: Re: -fno-strict-aliasing disables restrict On Tue, 26 Sep 2006, pinskia at gcc dot gnu dot org wrote: And this is not a bug, restrict can be ignored by a compiler in terms of optimization which is what is happening with -fno-strict-aliasing. Of course it's a bug. -fno-strict-aliasing enables a particular language dialect without the type-based alias rules. Nothing in the documentation of -fno-strict-aliasing says that dialect lacks the restrict rules. So either it's a missed-optimization bug or a doc bug; I think the former. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29239
[Bug middle-end/29239] -fno-strict-aliasing disables restrict
--- Comment #3 from acahalan at gmail dot com 2006-09-27 00:18 --- [EMAIL PROTECTED] is correct, it's a missed-optimization bug. (if this isn't a bug, then no missed optimization is a bug) -- acahalan at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Keywords||missed-optimization Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29239
[Bug middle-end/29239] -fno-strict-aliasing disables restrict
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-27 00:35 --- Except it is better just to fix your code for aliasing issues. 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. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29239
[Bug middle-end/29239] -fno-strict-aliasing disables restrict
--- 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...) 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29239
[Bug middle-end/29239] -fno-strict-aliasing disables restrict
--- 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 -, 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
