Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Hans-Peter Nilsson <hp@bitrange.com>]

On Tue, 31 Mar 2020, Maciej W. Rozycki wrote:
> Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
> detection.") and fix a typo in the __BYTE_ORDER fallback macro check
> that causes compilation errors like:
>
> .../include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
>
> on systems that do not provide the __BYTE_ORDER__ macro.

> Index: binutils/include/plugin-api.h
> ===================================================================
> --- binutils.orig/include/plugin-api.h
> +++ binutils/include/plugin-api.h
> @@ -51,7 +51,7 @@
>  /* Older GCC releases (<4.6.0) can make detection from glibc macros.  */
>  #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__)
>  #include <endian.h>
> -#ifdef _BYTE_ORDER
> +#ifdef __BYTE_ORDER
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
>  #define PLUGIN_LITTLE_ENDIAN 1
>  #elif __BYTE_ORDER == __BIG_ENDIAN

FWIW, I was about to commit that as obvious, also the bignum.h
inclusion thing!

The only question being, how the typo passed any kind of testing
in the first place...  No actually, there's also the question
why the plugin-API needs to bother with host endianness.  It's
not like endians are going to be different between plugins and
gcc on host.

brgds, H-P