Nathan Froyd <froydnj@codesourcery.com> writes:
> I don't know about HP-UX, IRIX, OSF/1, or AIX. Steve, Rainer and David,> could you please confirm that GCC defining __BYTE_ORDER__ et al will not> interfere with system headers on those targets with which you are> familiar?
At least on IRIX 6.5 and Tru64 UNIX V5.1B, there's no instance of
__BYTE_ORDER__ in the system headers. I'll fire off a bootstrap on both
targets with your patch to check if there's nothing amiss, though this
will take about two days.
Rainer

On Wed, Oct 13, 2010 at 9:52 PM, Nathan Froyd <froydnj@codesourcery.com> wrote:
> The patch below is a reworking of the patch posted here:>> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01081.html>> to take into account the need for documentation in cpp.texi and to use a> __BYTE_ORDER__-based scheme. I am a little uncertain about the use of> __BYTE_ORDER__ etc. as at least:>> http://gcc.gnu.org/ml/gcc-help/2007-07/msg00342.html>> suggests that there may be systems in the wild already using that.> glibc obviously does not, and the *BSDs, Solaris, VxWorks, and> newlib-based targets don't seem to, either.>> I don't know about HP-UX, IRIX, OSF/1, or AIX. Steve, Rainer and David,> could you please confirm that GCC defining __BYTE_ORDER__ et al will not> interfere with system headers on those targets with which you are> familiar?
AIX uses the macro BYTE_ORDER but not __BYTE_ORDER__
- David

On Wed, 2010-10-13 at 21:52 -0400, Nathan Froyd wrote:
> I don't know about HP-UX, IRIX, OSF/1, or AIX. Steve, Rainer and David,> could you please confirm that GCC defining __BYTE_ORDER__ et al will not> interfere with system headers on those targets with which you are> familiar?
HP-UX has uses of BYTE_ORDER in its headers but I don't see
__BYTE_ORDER__ used anywhere.
Steve Ellcey
sje@cup.hp.com

On Wed, 13 Oct 2010, Nathan Froyd wrote:
> The patch below is a reworking of the patch posted here:> > http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01081.html> > to take into account the need for documentation in cpp.texi and to use a> __BYTE_ORDER__-based scheme. I am a little uncertain about the use of> __BYTE_ORDER__ etc. as at least:
This patch is definitely unsafe. Not so much on account of __BYTE_ORDER__
(although codesearch.google.com shows plenty of matches for that), but on
account of __BIG_ENDIAN__ and __LITTLE_ENDIAN__. Those names are already
predefined for various targets by GCC to indicate "this is big-endian" or
"this is little-endian", so defining them unconditionally will break code
(glibc's sysdeps/sh/bits/endian.h, for example) that expects those
meanings.
Whatever macro you define for byte order, I think you can only safely
define one macros, not others such as __BIG_ENDIAN__ or variants thereof.
> +(word) of the quantity, respectively. If @code{__BYTE_ORDER__} is> +equal to @code{__PDP_ENDIAN__}, then bytes in 16-bit words are laid> +out in a little-endian fashion, whereas the 16-bit subwords of a> +32-bit quantity are laid out in big-endian fashion.
Are you sure that 16-bit and 32-bit reflect exactly how the
machine-independent code in GCC handles the target macros: does it really
have those sizes hardcoded?

On 10/14/2010 09:29 AM, Joseph S. Myers wrote:
> On Wed, 13 Oct 2010, Nathan Froyd wrote:> >> The patch below is a reworking of the patch posted here:>>>> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01081.html>>>> to take into account the need for documentation in cpp.texi and to use a>> __BYTE_ORDER__-based scheme. I am a little uncertain about the use of>> __BYTE_ORDER__ etc. as at least:> > This patch is definitely unsafe. Not so much on account of __BYTE_ORDER__ > (although codesearch.google.com shows plenty of matches for that), but on > account of __BIG_ENDIAN__ and __LITTLE_ENDIAN__. Those names are already > predefined for various targets by GCC to indicate "this is big-endian" or > "this is little-endian", so defining them unconditionally will break code > (glibc's sysdeps/sh/bits/endian.h, for example) that expects those > meanings.
We could define __BYTE_ORDER_{BIG,LITTLE,PDP}_ENDIAN__ instead, surely?
r~

On Thu, 14 Oct 2010, Richard Henderson wrote:
> On 10/14/2010 09:29 AM, Joseph S. Myers wrote:> > On Wed, 13 Oct 2010, Nathan Froyd wrote:> > > >> The patch below is a reworking of the patch posted here:> >>> >> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01081.html> >>> >> to take into account the need for documentation in cpp.texi and to use a> >> __BYTE_ORDER__-based scheme. I am a little uncertain about the use of> >> __BYTE_ORDER__ etc. as at least:> > > > This patch is definitely unsafe. Not so much on account of __BYTE_ORDER__ > > (although codesearch.google.com shows plenty of matches for that), but on > > account of __BIG_ENDIAN__ and __LITTLE_ENDIAN__. Those names are already > > predefined for various targets by GCC to indicate "this is big-endian" or > > "this is little-endian", so defining them unconditionally will break code > > (glibc's sysdeps/sh/bits/endian.h, for example) that expects those > > meanings.> > We could define __BYTE_ORDER_{BIG,LITTLE,PDP}_ENDIAN__ instead, surely?
It does appear those names are not used in anything known to
codesearch.google.com, although the variants without trailing underscores
are.

On Oct 14, 2010, at 4:22 AM, Rainer Orth wrote:
> Nathan Froyd <froydnj@codesourcery.com> writes:> >> I don't know about HP-UX, IRIX, OSF/1, or AIX. Steve, Rainer and David,>> could you please confirm that GCC defining __BYTE_ORDER__ et al will not>> interfere with system headers on those targets with which you are>> familiar?> > At least on IRIX 6.5 and Tru64 UNIX V5.1B, there's no instance of> __BYTE_ORDER__ in the system headers.
I was worried about darwin, I checked... No instance there there...

On Thu, Oct 14, 2010 at 04:29:54PM +0000, Joseph S. Myers wrote:
> On Wed, 13 Oct 2010, Nathan Froyd wrote:> > to take into account the need for documentation in cpp.texi and to use a> > __BYTE_ORDER__-based scheme. I am a little uncertain about the use of> > __BYTE_ORDER__ etc. as at least:> > This patch is definitely unsafe. Not so much on account of __BYTE_ORDER__ > (although codesearch.google.com shows plenty of matches for that), but on > account of __BIG_ENDIAN__ and __LITTLE_ENDIAN__.
Thanks for pointing this out. I will submit an updated patch.
> > +(word) of the quantity, respectively. If @code{__BYTE_ORDER__} is> > +equal to @code{__PDP_ENDIAN__}, then bytes in 16-bit words are laid> > +out in a little-endian fashion, whereas the 16-bit subwords of a> > +32-bit quantity are laid out in big-endian fashion.> > Are you sure that 16-bit and 32-bit reflect exactly how the > machine-independent code in GCC handles the target macros: does it really > have those sizes hardcoded?
No idea; I doubt that it does. Can we just ditch the pdp11 port? ;)
-Nathan

On 10/18/2010 5:21 AM, Nathan Froyd wrote:
> No idea; I doubt that it does. Can we just ditch the pdp11 port? ;)
In all seriousness, why shouldn't we? The usual response is that
someone out there somewhere is willing to maintain it. But, are there
really enough users to make it worth it?

I'm indeed willing to keep maintaining it (though admittedly I haven't been all that active -- that may change a bit soon). On the other hand, I'll admit that I don't know if there are all that many users.
paul
On Oct 19, 2010, at 1:51 PM, Mark Mitchell wrote:
> On 10/18/2010 5:21 AM, Nathan Froyd wrote:> >> No idea; I doubt that it does. Can we just ditch the pdp11 port? ;)> > In all seriousness, why shouldn't we? The usual response is that> someone out there somewhere is willing to maintain it. But, are there> really enough users to make it worth it?> > -- > Mark Mitchell> CodeSourcery> mark@codesourcery.com> (650) 331-3385 x713

On 10/19/2010 11:07 AM, Paul Koning wrote:
> I'm indeed willing to keep maintaining it (though admittedly I> haven't been all that active -- that may change a bit soon). On the> other hand, I'll admit that I don't know if there are all that many> users.
I certainly don't mean to criticize; a key idea for FOSS is that anyone
can make the software do what they want, and I'm all for people porting
GCC to whatever platform is of interest to them!
I'm just skeptical that maintaining PDP11 support in GCC is worthwhile
if it has any non-trivial cost for users without a stake in PDP11. This
is a situation where it seems like it's a hassle, and given that my
inclination would be just to remove PDP11 support from GCC.

Thanks, and I understood your comments that way.
I don't see that there is a significant cost. Yes, pdp11 is one of the few (though apparently not the only) platform that has mixed endian. But that has very little impact (one example, curiously, being a 3 year old bug I just fixed...).
From what I recall, Nathan's original comment was triggered essentially by the question of what a "word" is in WORD_BIG_ENDIAN. "Is it hardcoded" was the question that was asked. I believe the answer is no, "WORD" is a register. So in the case of the pdp11, where registers are 16 bits, mixed endian means 3412, but if one of the other mixed endian platforms has wider words (wider registers) then that doesn't carry over.
Isn't "WORD" a concept that occurs in many places? And certainly the size of a word is not consistent across all platforms. So I don't know that the existence of the pdp11 creates unique levels of pain here.
paul
On Oct 19, 2010, at 3:57 PM, Mark Mitchell wrote:
> On 10/19/2010 11:07 AM, Paul Koning wrote:> >> I'm indeed willing to keep maintaining it (though admittedly I>> haven't been all that active -- that may change a bit soon). On the>> other hand, I'll admit that I don't know if there are all that many>> users.> > I certainly don't mean to criticize; a key idea for FOSS is that anyone> can make the software do what they want, and I'm all for people porting> GCC to whatever platform is of interest to them!> > I'm just skeptical that maintaining PDP11 support in GCC is worthwhile> if it has any non-trivial cost for users without a stake in PDP11. This> is a situation where it seems like it's a hassle, and given that my> inclination would be just to remove PDP11 support from GCC.> > -- > Mark Mitchell> CodeSourcery> mark@codesourcery.com> (650) 331-3385 x713