RE: incorrect __vxworks__ usage in longlong.h (3.3) was ok in 3.2 .3

RE: incorrect __vxworks__ usage in longlong.h (3.3) was ok in 3.2 .3

[Ken Faiczak]

Note: also the check  of PPC also causes problems for vxworks
since it also defines that as a CPU_FAMILY for comparison 
even though the current CPU is not equal to that
(it also defines all kinds of others CPUs and FAMILIES...)

ie in our case CPU=R4000 or CPU=SB1250

is the compiler supposed to be looking for these sorts of things
  that aren't surrounded by __PPC__ sort of thing


-----Original Message-----
From: David Edelsohn [mailto:dje@watson.ibm.com]
Sent: Wednesday, July 30, 2003 1:42 PM
To: Zack Weinberg
Cc: Ken Faiczak; 'gcc@gnu.org'
Subject: Re: incorrect __vxworks__ usage in longlong.h (3.3) was ok in
3.2.3 


>>>>> Zack Weinberg writes:

Zack> I would encourage you to raise this issue with the GMP maintainers
Zack> as well; they probably have the bug in their version of this file.

	The same test occurs in the GMP distribution.

	I have changed longlong.h in the GCC 3.4 trunk.  It is up to Mark
if this patch is approved for GCC 3.3 branch.

David

Re: incorrect __vxworks__ usage in longlong.h (3.3) was ok in 3.2 .3

[Zack Weinberg]

Ken Faiczak <kfaiczak@sandvine.com> writes:

> Note: also the check  of PPC also causes problems for vxworks
> since it also defines that as a CPU_FAMILY for comparison 
> even though the current CPU is not equal to that
> (it also defines all kinds of others CPUs and FAMILIES...)
>
> ie in our case CPU=R4000 or CPU=SB1250
>
> is the compiler supposed to be looking for these sorts of things
>   that aren't surrounded by __PPC__ sort of thing

It's suboptimal, but please understand that this file is lifted from
GMP, and changes really ought to go through the GMP maintainers.

I don't care to defend vxworks' pollution of the user namespace with
CPU and CPU_FAMILY macros, either.

zw