When removing some dead big endian checks in the RISC-V code Nick
suggested that we should have some generic sanity checks. I don't think
we should have thos inside the RISC-V code, but maybe it might make
sense to have these in the generic byteorder headers. Note that these
are UAPI headers and some compilers might not actually define
__BYTE_ORDER__, so we first check that it actually exists.
Suggested-by: Nick Kossifidis <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
---
include/uapi/linux/byteorder/big_endian.h | 4 ++++
include/uapi/linux/byteorder/little_endian.h | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/include/uapi/linux/byteorder/big_endian.h b/include/uapi/linux/byteorder/big_endian.h
index 2199adc6a6c2..34a5864526d2 100644
--- a/include/uapi/linux/byteorder/big_endian.h
+++ b/include/uapi/linux/byteorder/big_endian.h
@@ -2,6 +2,10 @@
#ifndef _UAPI_LINUX_BYTEORDER_BIG_ENDIAN_H
#define _UAPI_LINUX_BYTEORDER_BIG_ENDIAN_H
+#if defined(__BYTE_ORDER__) && __BYTE_ORDER__ != __ORDER_BIG_ENDIAN__
+#error "Unsupported endianess, check your toolchain"
+#endif
+
#ifndef __BIG_ENDIAN
#define __BIG_ENDIAN 4321
#endif
diff --git a/include/uapi/linux/byteorder/little_endian.h b/include/uapi/linux/byteorder/little_endian.h
index 601c904fd5cd..0cdf3583e19f 100644
--- a/include/uapi/linux/byteorder/little_endian.h
+++ b/include/uapi/linux/byteorder/little_endian.h
@@ -2,6 +2,10 @@
#ifndef _UAPI_LINUX_BYTEORDER_LITTLE_ENDIAN_H
#define _UAPI_LINUX_BYTEORDER_LITTLE_ENDIAN_H
+#if defined(__BYTE_ORDER__) && __BYTE_ORDER__ != __ORDER_LITTLE_ENDIAN__
+#error "Unsupported endianess, check your toolchain"
+#endif
+
#ifndef __LITTLE_ENDIAN
#define __LITTLE_ENDIAN 1234
#endif
--
2.20.1
On Fri, Apr 12, 2019 at 4:36 PM Christoph Hellwig <[email protected]> wrote:
>
> When removing some dead big endian checks in the RISC-V code Nick
> suggested that we should have some generic sanity checks. I don't think
> we should have thos inside the RISC-V code, but maybe it might make
> sense to have these in the generic byteorder headers. Note that these
> are UAPI headers and some compilers might not actually define
> __BYTE_ORDER__, so we first check that it actually exists.
>
> Suggested-by: Nick Kossifidis <[email protected]>
> Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Extra checking like this is good in general, but I'm not sure I see
exactly what kind of issue one might expect to prevent with this:
All architecture asm/byteorder.h headers either include the only
possible option, or they check the compiler defined macros:
arch/arc/include/uapi/asm/byteorder.h:#ifdef __BIG_ENDIAN__
arch/arm/include/uapi/asm/byteorder.h:#ifdef __ARMEB__
arch/arm64/include/uapi/asm/byteorder.h:#ifdef __AARCH64EB__
arch/c6x/include/uapi/asm/byteorder.h:#ifdef _BIG_ENDIAN
arch/microblaze/include/uapi/asm/byteorder.h:#ifdef __MICROBLAZEEL__
arch/mips/include/uapi/asm/byteorder.h:#if defined(__MIPSEB__)
arch/nds32/include/uapi/asm/byteorder.h:#ifdef __NDS32_EB__
arch/powerpc/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
arch/sh/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
arch/xtensa/include/uapi/asm/byteorder.h:#ifdef __XTENSA_EL__
Are you worried about toolchains that define those differently
from what these headers expect? Did you encounter such a case?
Arnd
On Fri, Apr 12, 2019 at 04:53:28PM +0200, Arnd Bergmann wrote:
> On Fri, Apr 12, 2019 at 4:36 PM Christoph Hellwig <[email protected]> wrote:
> >
> > When removing some dead big endian checks in the RISC-V code Nick
> > suggested that we should have some generic sanity checks. I don't think
> > we should have thos inside the RISC-V code, but maybe it might make
> > sense to have these in the generic byteorder headers. Note that these
> > are UAPI headers and some compilers might not actually define
> > __BYTE_ORDER__, so we first check that it actually exists.
> >
> > Suggested-by: Nick Kossifidis <[email protected]>
> > Signed-off-by: Christoph Hellwig <[email protected]>
>
> Acked-by: Arnd Bergmann <[email protected]>
>
> Extra checking like this is good in general, but I'm not sure I see
> exactly what kind of issue one might expect to prevent with this:
I'm personally not worried at all. Just trying to respond to Nicks
review comment and make it reasonable generic if we have to have these
checks at all. I personally would be ok without them, I just don't
want them hidden somewhere in the RISC-V code (RISC-V is always little
endian at least right now).
On Fri, Apr 12, 2019 at 4:55 PM Christoph Hellwig <[email protected]> wrote:
>
> On Fri, Apr 12, 2019 at 04:53:28PM +0200, Arnd Bergmann wrote:
> > On Fri, Apr 12, 2019 at 4:36 PM Christoph Hellwig <[email protected]> wrote:
> > >
> > > When removing some dead big endian checks in the RISC-V code Nick
> > > suggested that we should have some generic sanity checks. I don't think
> > > we should have thos inside the RISC-V code, but maybe it might make
> > > sense to have these in the generic byteorder headers. Note that these
> > > are UAPI headers and some compilers might not actually define
> > > __BYTE_ORDER__, so we first check that it actually exists.
> > >
> > > Suggested-by: Nick Kossifidis <[email protected]>
> > > Signed-off-by: Christoph Hellwig <[email protected]>
> >
> > Acked-by: Arnd Bergmann <[email protected]>
> >
> > Extra checking like this is good in general, but I'm not sure I see
> > exactly what kind of issue one might expect to prevent with this:
>
> I'm personally not worried at all. Just trying to respond to Nicks
> review comment and make it reasonable generic if we have to have these
> checks at all. I personally would be ok without them, I just don't
> want them hidden somewhere in the RISC-V code (RISC-V is always little
> endian at least right now).
Ok, makes sense.
Note: I hope we won't ever see big-endian RISC-V, I think that ship has
sailed long ago, regardless of any personal preferences one might hold.
The architectures that allow both (arm, arc, mips, c6x, microblaze,
modern ppc64, superh) tend to just use little-endian in practice, and the
ones that are hardcoded to big-endian (sparc, parisc, m68k, h8300, s390,
ppc32, some mips) are all 25+ years old and do so only for historic
reasons, with openrisc being the notable exception.
Arnd
Στις 2019-04-12 17:53, Arnd Bergmann έγραψε:
> On Fri, Apr 12, 2019 at 4:36 PM Christoph Hellwig <[email protected]> wrote:
>>
>> When removing some dead big endian checks in the RISC-V code Nick
>> suggested that we should have some generic sanity checks. I don't
>> think
>> we should have thos inside the RISC-V code, but maybe it might make
>> sense to have these in the generic byteorder headers. Note that these
>> are UAPI headers and some compilers might not actually define
>> __BYTE_ORDER__, so we first check that it actually exists.
>>
>> Suggested-by: Nick Kossifidis <[email protected]>
>> Signed-off-by: Christoph Hellwig <[email protected]>
>
> Acked-by: Arnd Bergmann <[email protected]>
>
> Extra checking like this is good in general, but I'm not sure I see
> exactly what kind of issue one might expect to prevent with this:
>
> All architecture asm/byteorder.h headers either include the only
> possible option, or they check the compiler defined macros:
>
> arch/arc/include/uapi/asm/byteorder.h:#ifdef __BIG_ENDIAN__
> arch/arm/include/uapi/asm/byteorder.h:#ifdef __ARMEB__
> arch/arm64/include/uapi/asm/byteorder.h:#ifdef __AARCH64EB__
> arch/c6x/include/uapi/asm/byteorder.h:#ifdef _BIG_ENDIAN
> arch/microblaze/include/uapi/asm/byteorder.h:#ifdef __MICROBLAZEEL__
> arch/mips/include/uapi/asm/byteorder.h:#if defined(__MIPSEB__)
> arch/nds32/include/uapi/asm/byteorder.h:#ifdef __NDS32_EB__
> arch/powerpc/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
> arch/sh/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
> arch/xtensa/include/uapi/asm/byteorder.h:#ifdef __XTENSA_EL__
>
> Are you worried about toolchains that define those differently
> from what these headers expect? Did you encounter such a case?
>
> Arnd
The following architectures just include the header file without
checking for any compiler macro:
alpha: little_endian.h
csky: little_endian.h
h8300: big_endian.h
hexagon: little_endian.h
ia64: little_endian.h
m68k: big_endian.h
nios2: little_endian.h
openrisc: big_endian.h
parisc: big_endian.h
riscv: little_endian.h
s390: big_endian.h
sparc: big_endian.h
unicore32: little_endian.h
x86: little_endian.h
Of those who do check for a compiler macro, they don't use the
generic macros (__ORDER_*_ENDIAN__) but arch-specific ones.
Only two architectures (mips and xtensa) that support both big
and little endian return an error in case the endianess can't be
determined, the rest will move on without including any
of *_endian.h files.
I think it's good to have a sanity check in-place for consistency.
Regards,
Nick
From: Nick Kossifidis <[email protected]>
Date: Fri, Apr 12, 2019 at 6:08 PM
To: Arnd Bergmann
Cc: Christoph Hellwig, Linus Torvalds, Andrew Morton, linux-arch,
<[email protected]>, Linux Kernel Mailing List
> Στις 2019-04-12 17:53, Arnd Bergmann έγραψε:
> > On Fri, Apr 12, 2019 at 4:36 PM Christoph Hellwig <[email protected]> wrote:
> >>
> >> When removing some dead big endian checks in the RISC-V code Nick
> >> suggested that we should have some generic sanity checks. I don't
> >> think
> >> we should have thos inside the RISC-V code, but maybe it might make
> >> sense to have these in the generic byteorder headers. Note that these
> >> are UAPI headers and some compilers might not actually define
> >> __BYTE_ORDER__, so we first check that it actually exists.
> >>
> >> Suggested-by: Nick Kossifidis <[email protected]>
> >> Signed-off-by: Christoph Hellwig <[email protected]>
> >
> > Acked-by: Arnd Bergmann <[email protected]>
> >
> > Extra checking like this is good in general, but I'm not sure I see
> > exactly what kind of issue one might expect to prevent with this:
> >
> > All architecture asm/byteorder.h headers either include the only
> > possible option, or they check the compiler defined macros:
> >
> > arch/arc/include/uapi/asm/byteorder.h:#ifdef __BIG_ENDIAN__
> > arch/arm/include/uapi/asm/byteorder.h:#ifdef __ARMEB__
> > arch/arm64/include/uapi/asm/byteorder.h:#ifdef __AARCH64EB__
> > arch/c6x/include/uapi/asm/byteorder.h:#ifdef _BIG_ENDIAN
> > arch/microblaze/include/uapi/asm/byteorder.h:#ifdef __MICROBLAZEEL__
> > arch/mips/include/uapi/asm/byteorder.h:#if defined(__MIPSEB__)
> > arch/nds32/include/uapi/asm/byteorder.h:#ifdef __NDS32_EB__
> > arch/powerpc/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
> > arch/sh/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
> > arch/xtensa/include/uapi/asm/byteorder.h:#ifdef __XTENSA_EL__
> >
> > Are you worried about toolchains that define those differently
> > from what these headers expect? Did you encounter such a case?
> >
> > Arnd
>
> The following architectures just include the header file without
> checking for any compiler macro:
>
> alpha: little_endian.h
> csky: little_endian.h
> h8300: big_endian.h
> hexagon: little_endian.h
> ia64: little_endian.h
> m68k: big_endian.h
> nios2: little_endian.h
> openrisc: big_endian.h
> parisc: big_endian.h
> riscv: little_endian.h
> s390: big_endian.h
> sparc: big_endian.h
> unicore32: little_endian.h
> x86: little_endian.h
>
> Of those who do check for a compiler macro, they don't use the
> generic macros (__ORDER_*_ENDIAN__) but arch-specific ones.
>
> Only two architectures (mips and xtensa) that support both big
> and little endian return an error in case the endianess can't be
> determined, the rest will move on without including any
> of *_endian.h files.
>
> I think it's good to have a sanity check in-place for consistency.
Hi,
This broke our cross-builds from x86. I am using:
$ powerpc64le-linux-gnu-gcc --version
powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
and it says that it's little-endian somehow:
$ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
Is it broke compiler? Or I always hold it wrong? Is there some
additional flag I need to add?
Thanks
On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <[email protected]> wrote:
> >
> > I think it's good to have a sanity check in-place for consistency.
>
>
> Hi,
>
> This broke our cross-builds from x86. I am using:
>
> $ powerpc64le-linux-gnu-gcc --version
> powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
>
> and it says that it's little-endian somehow:
>
> $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
>
> Is it broke compiler? Or I always hold it wrong? Is there some
> additional flag I need to add?
It looks like a bug in the kernel Makefiles to me. powerpc32 is always
big-endian,
powerpc64 used to be big-endian but is now usually little-endian. There are
often three separate toolchains that default to the respective user
space targets
(ppc32be, ppc64be, ppc64le), but generally you should be able to build
any of the
three kernel configurations with any of those compilers, and have the Makefile
pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
depending on the kernel configuration. It seems that this is not happening
here. I have not checked why, but if this is the problem, it should be
easy enough
to figure out.
Arnd
From: Arnd Bergmann <[email protected]>
Date: Sat, May 11, 2019 at 2:51 AM
To: Dmitry Vyukov
Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
linux-arch, Linux Kernel Mailing List, linuxppc-dev
> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <[email protected]> wrote:
> > >
> > > I think it's good to have a sanity check in-place for consistency.
> >
> >
> > Hi,
> >
> > This broke our cross-builds from x86. I am using:
> >
> > $ powerpc64le-linux-gnu-gcc --version
> > powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
> >
> > and it says that it's little-endian somehow:
> >
> > $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
> > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
> >
> > Is it broke compiler? Or I always hold it wrong? Is there some
> > additional flag I need to add?
>
> It looks like a bug in the kernel Makefiles to me. powerpc32 is always
> big-endian,
> powerpc64 used to be big-endian but is now usually little-endian. There are
> often three separate toolchains that default to the respective user
> space targets
> (ppc32be, ppc64be, ppc64le), but generally you should be able to build
> any of the
> three kernel configurations with any of those compilers, and have the Makefile
> pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
> depending on the kernel configuration. It seems that this is not happening
> here. I have not checked why, but if this is the problem, it should be
> easy enough
> to figure out.
Thanks! This clears a lot.
This may be a bug in our magic as we try to build kernel files outside
of make with own flags (required to extract parts of kernel
interfaces).
So don't spend time looking for the Makefile bugs yet.
On Mon, May 13, 2019 at 01:50:19PM +0200, Dmitry Vyukov wrote:
> > We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> > fixed now. These days I build most of my kernels with a bi-endian 64-bit
> > toolchain, and switching endian without running `make clean` also works.
>
> For the record, yes, it turn out to be a problem in our code (a latent
> bug). We actually used host (x86) gcc to build as-if ppc code that can
> run on the host, so it defined neither LE no BE macros. It just
> happened to work in the past :)
So Nick was right and these checks actually are useful..
Dmitry Vyukov <[email protected]> writes:
> From: Arnd Bergmann <[email protected]>
> Date: Sat, May 11, 2019 at 2:51 AM
> To: Dmitry Vyukov
> Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
> linux-arch, Linux Kernel Mailing List, linuxppc-dev
>
>> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <[email protected]> wrote:
>> > >
>> > > I think it's good to have a sanity check in-place for consistency.
>> >
>> >
>> > Hi,
>> >
>> > This broke our cross-builds from x86. I am using:
>> >
>> > $ powerpc64le-linux-gnu-gcc --version
>> > powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
>> >
>> > and it says that it's little-endian somehow:
>> >
>> > $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
>> > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
>> >
>> > Is it broke compiler? Or I always hold it wrong? Is there some
>> > additional flag I need to add?
>>
>> It looks like a bug in the kernel Makefiles to me. powerpc32 is always
>> big-endian,
>> powerpc64 used to be big-endian but is now usually little-endian. There are
>> often three separate toolchains that default to the respective user
>> space targets
>> (ppc32be, ppc64be, ppc64le), but generally you should be able to build
>> any of the
>> three kernel configurations with any of those compilers, and have the Makefile
>> pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
>> depending on the kernel configuration. It seems that this is not happening
>> here. I have not checked why, but if this is the problem, it should be
>> easy enough
>> to figure out.
>
>
> Thanks! This clears a lot.
> This may be a bug in our magic as we try to build kernel files outside
> of make with own flags (required to extract parts of kernel
> interfaces).
> So don't spend time looking for the Makefile bugs yet.
OK :)
We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
fixed now. These days I build most of my kernels with a bi-endian 64-bit
toolchain, and switching endian without running `make clean` also works.
cheers
From: Michael Ellerman <[email protected]>
Date: Mon, May 13, 2019 at 1:33 PM
To: Dmitry Vyukov, Arnd Bergmann
Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
linux-arch, Linux Kernel Mailing List, linuxppc-dev
> Dmitry Vyukov <[email protected]> writes:
> > From: Arnd Bergmann <[email protected]>
> > Date: Sat, May 11, 2019 at 2:51 AM
> > To: Dmitry Vyukov
> > Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
> > linux-arch, Linux Kernel Mailing List, linuxppc-dev
> >
> >> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <[email protected]> wrote:
> >> > >
> >> > > I think it's good to have a sanity check in-place for consistency.
> >> >
> >> >
> >> > Hi,
> >> >
> >> > This broke our cross-builds from x86. I am using:
> >> >
> >> > $ powerpc64le-linux-gnu-gcc --version
> >> > powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
> >> >
> >> > and it says that it's little-endian somehow:
> >> >
> >> > $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
> >> > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
> >> >
> >> > Is it broke compiler? Or I always hold it wrong? Is there some
> >> > additional flag I need to add?
> >>
> >> It looks like a bug in the kernel Makefiles to me. powerpc32 is always
> >> big-endian,
> >> powerpc64 used to be big-endian but is now usually little-endian. There are
> >> often three separate toolchains that default to the respective user
> >> space targets
> >> (ppc32be, ppc64be, ppc64le), but generally you should be able to build
> >> any of the
> >> three kernel configurations with any of those compilers, and have the Makefile
> >> pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
> >> depending on the kernel configuration. It seems that this is not happening
> >> here. I have not checked why, but if this is the problem, it should be
> >> easy enough
> >> to figure out.
> >
> >
> > Thanks! This clears a lot.
> > This may be a bug in our magic as we try to build kernel files outside
> > of make with own flags (required to extract parts of kernel
> > interfaces).
> > So don't spend time looking for the Makefile bugs yet.
>
> OK :)
>
> We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> fixed now. These days I build most of my kernels with a bi-endian 64-bit
> toolchain, and switching endian without running `make clean` also works.
For the record, yes, it turn out to be a problem in our code (a latent
bug). We actually used host (x86) gcc to build as-if ppc code that can
run on the host, so it defined neither LE no BE macros. It just
happened to work in the past :)
+Andrew
On Mon, May 13, 2019 at 2:04 PM Christoph Hellwig <[email protected]> wrote:
>
> On Mon, May 13, 2019 at 01:50:19PM +0200, Dmitry Vyukov wrote:
> > > We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> > > fixed now. These days I build most of my kernels with a bi-endian 64-bit
> > > toolchain, and switching endian without running `make clean` also works.
> >
> > For the record, yes, it turn out to be a problem in our code (a latent
> > bug). We actually used host (x86) gcc to build as-if ppc code that can
> > run on the host, so it defined neither LE no BE macros. It just
> > happened to work in the past :)
>
> So Nick was right and these checks actually are useful..
Yes, definitely. I wonder if we should also bring back the word size check
from include/asm-generic/bitsperlong.h, which was disabled right
after I originally added that.
Arnd
On Fri, 12 Apr 2019, Christoph Hellwig wrote:
> diff --git a/include/uapi/linux/byteorder/big_endian.h b/include/uapi/linux/byteorder/big_endian.h
> index 2199adc6a6c2..34a5864526d2 100644
> --- a/include/uapi/linux/byteorder/big_endian.h
> +++ b/include/uapi/linux/byteorder/big_endian.h
> @@ -2,6 +2,10 @@
> #ifndef _UAPI_LINUX_BYTEORDER_BIG_ENDIAN_H
> #define _UAPI_LINUX_BYTEORDER_BIG_ENDIAN_H
>
> +#if defined(__BYTE_ORDER__) && __BYTE_ORDER__ != __ORDER_BIG_ENDIAN__
> +#error "Unsupported endianess, check your toolchain"
Typo here: s/endianess/endianness/.
> diff --git a/include/uapi/linux/byteorder/little_endian.h b/include/uapi/linux/byteorder/little_endian.h
> index 601c904fd5cd..0cdf3583e19f 100644
> --- a/include/uapi/linux/byteorder/little_endian.h
> +++ b/include/uapi/linux/byteorder/little_endian.h
> @@ -2,6 +2,10 @@
> #ifndef _UAPI_LINUX_BYTEORDER_LITTLE_ENDIAN_H
> #define _UAPI_LINUX_BYTEORDER_LITTLE_ENDIAN_H
>
> +#if defined(__BYTE_ORDER__) && __BYTE_ORDER__ != __ORDER_LITTLE_ENDIAN__
> +#error "Unsupported endianess, check your toolchain"
Likewise.
Maciej
On Thu, May 30, 2019 at 01:46:18AM +0000, Maciej Rozycki wrote:
> > +#if defined(__BYTE_ORDER__) && __BYTE_ORDER__ != __ORDER_BIG_ENDIAN__
> > +#error "Unsupported endianess, check your toolchain"
>
> Typo here: s/endianess/endianness/.
The original patch has already been merged, please send a fixup.