To whom it may concern:
In general, the logic of the gcc/config/arm/linux-elf.h file dictates that if
the target is big-endian arm, gcc will use big-endian defaults (like
-mbig_endian); otherwise, gcc will use little-endian defaults. However, there
is apparently one exception to this rule. MUTLILIB_DEFAULTS is hard-coded to
little-endian for both big-endian and little-endian arm:
#undef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS \
{ "marm", "mlittle-endian", "mhard-float", "mno-thumb-interwork" }
To be to consistent with the rest of the header file, shouldn't this read:
#undef MULTILIB_DEFAULTS
#if TARGET_BIG_ENDIAN_DEFAULT
#define MULTILIB_DEFAULTS \
{ "marm", "mbig-endian", "mhard-float", "mno-thumb-interwork" }
#else
#define MULTILIB_DEFAULTS \
{ "marm", "mlittle-endian", "mhard-float", "mno-thumb-interwork" }
#endif
or better yet:
#undef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS \
{ "marm", TARGET_ENDIAN_OPTION, "mhard-float", "mno-thumb-interwork" }
Otherwise, on a big-endian arm target in which multi-lib is enabled,
potentially some options would be set by default to big-endian, others to
little-endian, and the compiler would get confused. At least that's how it
appears to me.
If this is by design rather than a minor bug that fell through the cracks (I
know that arm is natively little-endian, and thus there may be a reason to
always default it to little-endian in certain cases) please disregard this
message and close this bug report. Thanks.
Regards,
Tom
--
Summary: big-endian arm MULTILIB_DEFAULTS hard-coded to little-
endian
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom at giftssoft dot com
GCC target triplet: arm*b-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42081
