__sparc__ not defined with Forte C

[Gregg Mattinson]

Alright, makes sense.  Since I don't know what you mean by "all compilers," I 
added a configure test and I will make sure __sparc__ is used everywhere.

In regards to the second point (@function vs. 2), something has been bugging me 
for a while...  Why do the .spec.c files have so much assembly code in them?  To 
me, it looks like most of it could be replaced with an array and some creative 
use of global variables.

I'm willing to tackle the task of converting the .spec.c files to use as much C 
as possible, but I can only test it on sparc.  Someone else would have to test 
it on i386 and with native .dlls

Gregg

>To: Gregg Mattinson <gm138242 at opcom-mail.canada.sun.com>
>Cc: wine-devel at winehq.com
>Subject: Re: __sparc__ not defined with Forte C
>From: Alexandre Julliard <julliard at winehq.com>
>Date: 15 Jul 2002 18:49:04 -0700
>User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)
>MIME-Version: 1.0
>
>Gregg Mattinson <gm138242 at scot.canada.sun.com> writes:
>
>> ChangeLog: dlls/ntdll/signal_sparc.c include/basetsd.h
>>            include/wine/port.h server/context_sparc.c
>>  - __sparc__ is not defined with Forte C, but __sparc is defined with both 
Forte 
>> and GCC.  Same goes for __sun__
>
>If __sparc and __sun work for all compilers we should use them
>everywhere, no need to try to support other forms. Otherwise it should
>be done with a configure test like we do for __i386__.
>
>>  - Forte C doesn't like @function.  Replaced it with 2.
>
>This needs a configure test. A #ifdef SUNPRO_C is almost always the
>wrong thing to do.
>
>-- 
>Alexandre Julliard
>julliard at winehq.com