On 3/23/20 11:10 AM, Jakub Jelinek wrote:
On Mon, Mar 23, 2020 at 11:00:21AM +0100, Martin Liška wrote:
On 3/23/20 10:43 AM, Jakub Jelinek wrote:
On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote:
Hi.
As seen in the PR, sparc64 LTO test-suite fails due to missing
definition of __BIG_ENDIAN__ macro. That said, I updated the
endianess detection to use __BYTE_ORDER__.
I tested the detection on x86_64-linux-gnu, ppc64-linux-gnu and
lto.exp testsuite survives on a sparc64-linux machine.
Those are GCC specific macros, are you sure plugin-api.h will be always
compiled just with GCC and no other compiler?
And Clang supports that. The header file is used for GCC LTO plug-in
(which is like a run-time library) and then it's consumed by binutils.
So I don't how much portable it should be?
GCC only supports that since GCC 4.6 and Clang copied that from that.
If it is only used in the LTO plugin and nothing else, I guess you can rely
in it being compiled by GCC only, but if it is e.g. used by binutils itself
too, then no.
All right...
You can use them but should be prepared for some fallback (e.g. endian.h,
whatever else).
And there is also PDP endian...
Huh, are we talking about something so complex like:
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/int_endianness.h
I'd say even that is very simplified. E.g. on glibc there is <endian.h>
with its macros, etc.
Btw. do we force our run-time libraries to be built with GCC?
Some of our run-time libraries rely on being built by GCC, sure.
But I thought include/ is shared with binutils and there we don't really say
which compiler must be used to compile it.
... and can we then rely on configure detection of the endianess done by bfd
and gold:
gold/config.h:#define GOLD_DEFAULT_BIG_ENDIAN false
bfd/PORTING:
TARGET_IS_BIG_ENDIAN_P
Should be defined if <target> is big-endian.
?
Martin
Jakub
