Re: Miscellaneous XCode Questions
Re: Miscellaneous XCode Questions
- Subject: Re: Miscellaneous XCode Questions
- From: Sanjay Patel <email@hidden>
- Date: Sat, 13 May 2006 05:42:55 -0700 (PDT)
Eric Albert wrote:
>
> On May 12, 2006, at 2:44 PM, Ben Weiss wrote:
>
> > On May 12, 2006, at 4:57 AM, Sanjay Patel wrote:
> >
> >>>>> 3. When a pointer (to say, a char) is cast to a vUInt16* pointer,
> >>>>> gcc implicitly assumes that it is 16-byte aligned, and loads data
> >>>>> with movdqa. Is it legal for gcc to assume this? Do misaligned
> >>>>> loads always have to be coded explicitly?
> >>
> >> Minimal test case:
> >>
> >> #include <xmmintrin.h>
> >>
> >> __m128 foo( char* a ) {
> >> return *( __m128* )( a );
> >> }
> >>
> >> Codegen:
> >> ...
> >> movl 8(ëp), êx
> >> movaps (êx), %xmm0
> >> ...
> >
> > Exactly; 'movaps' is an aligned load instruction, and will crash if
> > char* a is misaligned.
> >
> >> Strictly speaking, casting your pointer to a different type is not
> >> legal 'C'.
> >> So I think the answer is going to be "your code is wrong, and the
> >> compiler
> >> can generate whatever it wants."
> >
> > (envisioning the chaos that would ensue if compilers suddenly
> > decided to enforce this...) If it's illegal C, why doesn't gcc
> > generate an error (or at least a warning?)
>
> I think this is a semantic issue. The syntax is legal C, but I'm not
> sure if the result is defined. See, for example, the section on -
> fstrict-aliasing in the gcc man page. -fstrict-aliasing is not
> turned on by default at any optimization level in Apple's compiler,
> despite what the man page says, but that section is still a good
> guide to how unexpected type conversions can affect optimizers.
I'm usually on the wrong side of the language law, but I found this:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
Section 6.3.2.3 states:
"A pointer to an object or incomplete type may be converted to a pointer to a
different object or incomplete type. If the resulting pointer is not
correctly aligned for the pointed-to type, the behavior is undefined."
I agree that GCC should be issuing a warning or error in this case. The
potential fallout for silently generating crashing code is just too big.
> > Apple's Altivec/SSE page says:
> >
> > "SSE has a wide variety of data type conversions. Like AltiVec, if
> > you wish to simply use a vector of one type (e.g. vFloat) as a
> > vector of another type (e.g. vSInt32) without changing the bits,
> > you can do that with a simple typecast:
> >
> > vFloat one = (vFloat) {1.0f, 1.0f, 1.0f, 1.0f };
> > vSInt32 oneBits = (vSInt32) one;
> >
> > Are they wrong? I've never seen fancy intrinsics used for casts
> > like this...
> They should probably update that page, yeah. Can you file a bug
> about it?
This is a holdover from Altivec and should be fixed. Altivec intrinsics do
*not* provide the casts (though they should). SSE intrinsics are more
strictly defined in this respect -- more like C++ (eg, static_cast<>) than C
-- and IMO safer.
--Sanjay
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden