Le 20/05/2026 à 20:43, David Laight a écrit :
On Wed, 20 May 2026 15:14:40 +0200
"Christophe Leroy (CS GROUP)" <[email protected]> wrote:
Le 17/05/2026 à 15:54, David Laight a écrit :
On Sun, 17 May 2026 12:14:21 +0800
Mingcong Bai <[email protected]> wrote:
Similar to commit b929926f01f2 ("sh: define __BIG_ENDIAN for math-emu"),
define __LITTLE_ENDIAN and __BIG_ENDIAN as 0 to mitigate build-time
warnings:
./include/math-emu/double.h:59:21: error: ‘__BIG_ENDIAN’ is not defined,
evaluates to ‘0’ [-Werror=undef]
59 | #if __BYTE_ORDER == __BIG_ENDIAN
|
Cc: [email protected]
Fixes: 13da9e200fe4 ("Revert "endian: #define __BYTE_ORDER"")
Reported-by: kernel test robot <[email protected]>
Closes:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Foe-kbuild-all%2F202507301656.7FEX6J5W-lkp%40intel.com%2F&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C3ed26b8c3d6449fdc29608deb69fac66%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639148994069314641%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FfFnXxMPXXxoOMM8fYU4df5gMjk3B2dPgQsjwUagaNA%3D&reserved=0
Signed-off-by: Mingcong Bai <[email protected]>
---
arch/powerpc/include/asm/sfp-machine.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/sfp-machine.h
b/arch/powerpc/include/asm/sfp-machine.h
index 8b957aabb826d..db8525605c026 100644
--- a/arch/powerpc/include/asm/sfp-machine.h
+++ b/arch/powerpc/include/asm/sfp-machine.h
@@ -319,10 +319,12 @@
#define abort()
\
return 0
-#ifdef __BIG_ENDIAN
+#ifdef __BIG_ENDIAN__
#define __BYTE_ORDER __BIG_ENDIAN
+#define __LITTLE_ENDIAN 0
#else
#define __BYTE_ORDER __LITTLE_ENDIAN
+#define __BIG_ENDIAN 0
#endif
I thought the expected/correct value for __BYTE_ORDER__ was either 1234 or 4321.
(apart from pdp11's 2143).
That's the case, in include/linux/kconfig.h we have:
#ifdef CONFIG_CPU_BIG_ENDIAN
#define __BIG_ENDIAN 4321
#else
#define __LITTLE_ENDIAN 1234
#endif
But as far as I understand the problem is that math-emu expects
__BIG_ENDIAN to be defined at all time as it has tests like:
#if __BYTE_ORDER == __BIG_ENDIAN
The gcc docs have
(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fcpp%2FCommon-Predefined-Macros.html&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C3ed26b8c3d6449fdc29608deb69fac66%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639148994069350793%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D0BlZT73XnqHXHN2ukPFFUQw5lCCwaKfkmp6vMHz0Gk%3D&reserved=0):
__BYTE_ORDER__
__ORDER_LITTLE_ENDIAN__
__ORDER_BIG_ENDIAN__
__ORDER_PDP_ENDIAN__
__BYTE_ORDER__ is defined to one of the values __ORDER_LITTLE_ENDIAN__,
__ORDER_BIG_ENDIAN__, or __ORDER_PDP_ENDIAN__ to reflect the layout of
multi-byte and multi-word quantities in memory. If __BYTE_ORDER__ is equal to
__ORDER_LITTLE_ENDIAN__ or __ORDER_BIG_ENDIAN__, then multi-byte and multi-word
quantities are laid out identically: the byte (word) at the lowest address is
the least significant or most significant byte (word) of the quantity,
respectively. If __BYTE_ORDER__ is equal to __ORDER_PDP_ENDIAN__, then bytes in
16-bit words are laid out in a little-endian fashion, whereas the 16-bit
subwords of a 32-bit quantity are laid out in big-endian fashion.
You should use these macros for testing like this:
/* Test for a little-endian machine */
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
The doc doesn't mention the value, but __ORDER_BIG_ENDIAN__ is 4321 (decimal).
So the math-emu code is neither following gcc's rules or the kernel ones.
Your change will break anything that currently does:
#ifdef __BIG_ENDIAN
Any change would have to be limited to code that is implementing math-emu.
asm/sfp-machine.h is only included by math-emu it seems, so the change
should be safe.
Apparently math-emu predates git history, not sure where it comes from.
Christophe
