All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
Cc: Mingcong Bai <jeffbai@aosc.io>,
	linux-kernel@vger.kernel.org, Xi Ruoyao <xry111@xry111.site>,
	Kexy Biscuit <kexybiscuit@aosc.io>,
	stable@vger.kernel.org, kernel test robot <lkp@intel.com>,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc: define __LITTLE_ENDIAN and __BIG_ENDIAN for math-emu
Date: Wed, 20 May 2026 19:43:01 +0100	[thread overview]
Message-ID: <20260520194301.06d96a5f@pumpkin> (raw)
In-Reply-To: <eb93d563-7042-458e-a5c0-b5389343d41b@kernel.org>

On Wed, 20 May 2026 15:14:40 +0200
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org> wrote:

> Le 17/05/2026 à 15:54, David Laight a écrit :
> > On Sun, 17 May 2026 12:14:21 +0800
> > Mingcong Bai <jeffbai@aosc.io> 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: stable@vger.kernel.org
> >> Fixes: 13da9e200fe4 ("Revert "endian: #define __BYTE_ORDER"")
> >> Reported-by: kernel test robot <lkp@intel.com>
> >> 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.leroy%40csgroup.eu%7C08977974fb1c495e9bd508deb41bd275%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639146228768693730%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4qGulR%2BL7i7inksEbEH9jNGZS8HG80uvm3I9IyYzZww%3D&reserved=0
> >> Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
> >> ---
> >>   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://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html):
     
__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.

-- David

> 
> Christophe
> 


  reply	other threads:[~2026-05-20 18:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-17  4:14 [PATCH] powerpc: define __LITTLE_ENDIAN and __BIG_ENDIAN for math-emu Mingcong Bai
2026-05-17 13:54 ` David Laight
2026-05-17 15:40   ` Xi Ruoyao
2026-05-20 13:14   ` Christophe Leroy (CS GROUP)
2026-05-20 18:43     ` David Laight [this message]
2026-05-20 22:05       ` Christophe Leroy (CS GROUP)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260520194301.06d96a5f@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=chleroy@kernel.org \
    --cc=jeffbai@aosc.io \
    --cc=kexybiscuit@aosc.io \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lkp@intel.com \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=xry111@xry111.site \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.