linux-sh.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	Linux-sh list <linux-sh@vger.kernel.org>
Subject: Re: [RFC PATCH 3/4] sh: define __BIG_ENDIAN for math-emu
Date: Fri, 4 Jun 2021 09:24:23 +0200	[thread overview]
Message-ID: <CAMuHMdVUp2+C7QbLQvDqXCZ6FK-dEoz90aNk7Tu84YTRb3B_ww@mail.gmail.com> (raw)
In-Reply-To: <cde0b1fc-eec3-2267-3872-1099840f5670@infradead.org>

Hi Randy,

On Fri, Jun 4, 2021 at 1:19 AM Randy Dunlap <rdunlap@infradead.org> wrote:
> On 6/3/21 12:54 AM, Geert Uytterhoeven wrote:
> > On Thu, Jun 3, 2021 at 1:17 AM Randy Dunlap <rdunlap@infradead.org> wrote:
> >> The headers in include/math-emu/ test for __BYTE_ORDER == __BIG_ENDIAN
> >> without checking to see if these macros are defined, so add
> >> a define for __BIG_ENDIAN before pulling in these headers.
> >>
> >> This placates these build warnings:
> >>
> >> In file included from ../arch/sh/math-emu/math.c:23:
> >> ../include/math-emu/single.h:50:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
> >>    50 | #if __BYTE_ORDER == __BIG_ENDIAN
> >> In file included from ../arch/sh/math-emu/math.c:24:
> >> ../include/math-emu/double.h:59:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
> >>    59 | #if __BYTE_ORDER == __BIG_ENDIAN
> >>
> >> Fixes: 4b565680d163 ("sh: math-emu support")
> >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> >
> > Thanks for your patch!
> >
> >> --- linux-next-20210528.orig/arch/sh/math-emu/sfp-util.h
> >> +++ linux-next-20210528/arch/sh/math-emu/sfp-util.h
> >> @@ -70,4 +70,4 @@
> >>
> >>  #define __BYTE_ORDER __LITTLE_ENDIAN
> >>
> >> -
> >> +#define __BIG_ENDIAN 0
> >
> > I don't think this is the right fix.
> >
> > I think the right values should be picked up from:
> >
> >     include/uapi/linux/byteorder/big_endian.h:#define __BIG_ENDIAN 4321
> >     include/uapi/linux/byteorder/little_endian.h:#define __LITTLE_ENDIAN 1234
> >
> > How is this picked up on other architectures using <math-emu/single.h>?
>
> There isn't very much to compare to in other arch/.
> I've made a v2 patch that is done like arch/nds32/ does.
> What do you think about this one?
>
> thanks.
> ---
> From: Randy Dunlap <rdunlap@infradead.org>
> Subject: [RFC PATCH 2/3 v2] sh: define __BIG_ENDIAN for math-emu
>
> Fix this by defining both ENDIAN macros in
> <asm/sfp-machine.h> so that they can be utilized in
> <math-emu/soft-fp.h> according to the latter's comment:
> /* Allow sfp-machine to have its own byte order definitions. */
>
> (This is what is done in arch/nds32/include/asm/sfp-machine.h.)
>
> This placates these build warnings:
>
> In file included from ../arch/sh/math-emu/math.c:23:
> ../include/math-emu/single.h:50:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
>    50 | #if __BYTE_ORDER == __BIG_ENDIAN
> In file included from ../arch/sh/math-emu/math.c:24:
> ../include/math-emu/double.h:59:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
>    59 | #if __BYTE_ORDER == __BIG_ENDIAN
>
> Fixes: 4b565680d163 ("sh: math-emu support")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: linux-sh@vger.kernel.org
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> ---
>  arch/sh/include/asm/sfp-machine.h |    8 ++++++++
>  1 file changed, 8 insertions(+)
>
> --- linux-next-20210528.orig/arch/sh/include/asm/sfp-machine.h
> +++ linux-next-20210528/arch/sh/include/asm/sfp-machine.h
> @@ -13,6 +13,14 @@
>  #ifndef _SFP_MACHINE_H
>  #define _SFP_MACHINE_H
>
> +#ifdef __BIG_ENDIAN__
> +#define __BYTE_ORDER __BIG_ENDIAN
> +#define __LITTLE_ENDIAN 0
> +#else
> +#define __BYTE_ORDER __LITTLE_ENDIAN
> +#define __BIG_ENDIAN 0
> +#endif
> +
>  #define _FP_W_TYPE_SIZE                32
>  #define _FP_W_TYPE             unsigned long
>  #define _FP_WS_TYPE            signed long

These checks match with what is set by my sh cross-compiler (gcc
8.1.0):

diff <(sh4-linux-gcc-8.1.0 -ml -dM -E - < /dev/null | grep -E
"(BYTE_ORDER|ENDIAN)") <(sh4-linux-gcc-8.1.0 -mb -dM -E - < /dev/null
| grep -E "(BYTE_ORDER|ENDIAN)")
--- /dev/fd/63 2021-06-04 09:15:50.689928352 +0200
+++ /dev/fd/62 2021-06-04 09:15:50.689928352 +0200
@@ -1,6 +1,6 @@
 #define __ORDER_LITTLE_ENDIAN__ 1234
-#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
+#define __BIG_ENDIAN__ 1
+#define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__
 #define __ORDER_PDP_ENDIAN__ 3412
-#define __LITTLE_ENDIAN__ 1
 #define __ORDER_BIG_ENDIAN__ 4321
-#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+#define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__

So
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Note that powerpc checks on _BIG_ENDIAN, which works as my powerpc
cross-compiler (gcc 9.3.0) defines both _BIG_ENDIAN and _BIG_ENDIAN__.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2021-06-04  7:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 23:14 [PATCH 0/3] sh: fixes for various build warnings Randy Dunlap
2021-06-02 23:14 ` [PATCH 1/4] sh: convert xchg() to a statement expression Randy Dunlap
2021-06-02 23:14 ` [RFC PATCH 3/4] sh: define __BIG_ENDIAN for math-emu Randy Dunlap
2021-06-03  7:54   ` Geert Uytterhoeven
2021-06-03 23:19     ` Randy Dunlap
2021-06-04  7:24       ` Geert Uytterhoeven [this message]
2021-06-02 23:14 ` [PATCH 4/4] sh: fix READ/WRITE redefinition warnings Randy Dunlap
2021-06-03  6:51 ` [PATCH 0/3] sh: fixes for various build warnings John Paul Adrian Glaubitz

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=CAMuHMdVUp2+C7QbLQvDqXCZ6FK-dEoz90aNk7Tu84YTRb3B_ww@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=dalias@libc.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=ysato@users.sourceforge.jp \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).