This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 12 May, 2004, at 12.53, Fariborz Jahanian wrote:
On May 12, 2004, at 12:32 PM, Ziemowit Laski wrote:
On 12 May, 2004, at 8.48, Aldy Hernandez wrote:
"Ziemowit" == Ziemowit Laski <zlaski@apple.com> writes:
I haven't modified the casting logic in the compiler, so if the compiler allows a cast to int or const int, then it's probably OK. :-)
Please test that this is actually the case.
IIUC, you want me to test that type casting/conversion in C and C++ work correctly, which
is completely orthogonal to the AltiVec issue, and also gives off a slight
"halting problem" vibe. :-) Can you be more specific?
What I would like to see is that incorrect AltiVec calls are caught; for example, passing
a non-intergal argument when an integral type is expected.
That will require either a __builtin_integral_type_p, or an argument test right inside the
expand logic in rs6000.c. Which one do you prefer, and do you _really_ think it is worth
the candle? I don't.
P.S. What is IIUC (
I have been thinking for a minute and cannot come up with the sentence :).
If I Understand Correctly. :-)
-------------------------------------------------------------- Ziemowit Laski 1 Infinite Loop, MS 301-2K Mac OS X Compiler Group Cupertino, CA USA 95014-2083 Apple Computer, Inc. +1.408.974.6229 Fax .5477
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |