This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Strict aliasing affects glibc 2.1.1 as well as Linux
- To: Jamie Lokier <egcs at tantalophile dot demon dot co dot uk>
- Subject: Re: Strict aliasing affects glibc 2.1.1 as well as Linux
- From: Linus Torvalds <torvalds at transmeta dot com>
- Date: Tue, 20 Jul 1999 16:35:57 -0700 (PDT)
- cc: "Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>, egcs at egcs dot cygnus dot com
On Wed, 21 Jul 1999, Jamie Lokier wrote:
>
> It suppress some optimisations, but __norestrict in its present
> all-aliasing form suppresses the same ones anyway.
Nope.
__norestrict does NOT supporess alias optimizations based on static
knowledge. __norestrict only suppresses optimizations based on TYPE.
In particular, the compiler can still prove that different stack slots are
never going to alias, even in the presense of __norestrict.
Anyway, the fact that the issue came up at all makes me suddenly agree
violently with Richard, and now I see why he really wanted to call it
__typealias.
Example: knowing that memory operations with the same base offset (be it
the stack pointer, a structure pointer or an array base pointer) cannot
alias if the offsets do not overlap is something that is often quite
useful.
Also, much as I love inline assembly for when I have to use it, it sure
screws up the compilers notion about pairing and CPU resoruces.
Linus