On 07/05/15 19:07, Jeff Law wrote:
On 05/06/2015 05:36 AM, Szabolcs Nagy wrote:
On 30/04/15 00:18, Joseph Myers wrote:
On Wed, 29 Apr 2015, Szabolcs Nagy wrote:
only affects [u]int_fastN_t types
(on 64bit systems for N=16,32 musl uses int but glibc uses long)
i can fix glibc-stdint.h, but it's yet another way in which the
compiler is tied to a particular libc.
...
(i'd prefer if the compiler did not know about these types, but
...
The compiler also needs to know these types for the Fortran C bindings.
This is a work around patch so -mmusl or default musl libc
changes the [U]INT_FAST{16,32}_TYPE macro definitions.
The undef/define logic is needed because glibc-stdint.h is
used on non-linux targets where OPTION_MUSL would not be
defined and it is used both before and after config/linux.h on
various linux targets.
I did not find any cleaner workaround. (Separate musl-stdint.h
would need significant changes in config.gcc.)
gcc/Changelog:
2015-05-06 Szabolcs Nagy <szabolcs.n...@arm.com>
* config/glibc-stdint.h (OPTION_MUSL): Define.
(INT_FAST16_TYPE, INT_FAST32_TYPE, UINT_FAST16_TYPE, UINT_FAST32_TYPE):
Change the definition based on OPTION_MUSL for 64 bit targets.
* config/linux.h (OPTION_MUSL): Redefine.
* config/alpha/linux.h (OPTION_MUSL): Redefine.
* config/rs6000/linux.h (OPTION_MUSL): Redefine.
* config/rs6000/linux64.h (OPTION_MUSL): Redefine.
I really don't like the MUSL bits inside glibc-stdint.h. But I don't
see an easy way to avoid it.
OK for the trunk.
I've committed this on Szabolcs' behalf with r222905.
Kyrill
jeff
