Fix a few build warnings on SUPERH.
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: [email protected]
[PATCH 1/3] sh: convert xchg() to a statement expression
[RFC PATCH 2/3] sh: define __BIG_ENDIAN for math-emu
[PATCH 3/3] sh: fix READ/WRITE redefinition warnings
arch/sh/include/asm/cmpxchg.h | 2 -
arch/sh/math-emu/math.c | 44 ++++++++++++++++----------------
arch/sh/math-emu/sfp-util.h | 2 -
3 files changed, 24 insertions(+), 24 deletions(-)
Use a GCC statement expression (extension) for xchg(), as is done
in other arches.
Fixes this build warning:
../fs/ocfs2/file.c: In function 'ocfs2_file_write_iter':
../arch/sh/include/asm/cmpxchg.h:49:3: warning: value computed is not used [-Wunused-value]
49 | ((__typeof__(*(ptr)))__xchg((ptr),(unsigned long)(x), sizeof(*(ptr))))
Fixes: e839ca528718 ("Disintegrate asm/system.h for SH")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: [email protected]
Cc: David Howells <[email protected]>
---
This is similar to a patch from Arnd for m68k:
https://lore.kernel.org/linux-m68k/[email protected]/
arch/sh/include/asm/cmpxchg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20210528.orig/arch/sh/include/asm/cmpxchg.h
+++ linux-next-20210528/arch/sh/include/asm/cmpxchg.h
@@ -46,7 +46,7 @@ extern void __xchg_called_with_bad_point
})
#define xchg(ptr,x) \
- ((__typeof__(*(ptr)))__xchg((ptr),(unsigned long)(x), sizeof(*(ptr))))
+ ({(__typeof__(*(ptr)))__xchg((ptr),(unsigned long)(x), sizeof(*(ptr)));})
/* This function doesn't exist, so you'll get a linker error
* if something tries to do an invalid cmpxchg(). */
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 <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: [email protected]
---
arch/sh/math-emu/sfp-util.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 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
kernel.h defines READ and WRITE, so rename the SH math-emu macros
to MREAD and MWRITE.
Fixes these warnings:
../arch/sh/math-emu/math.c:54: warning: "WRITE" redefined
54 | #define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
In file included from ../arch/sh/math-emu/math.c:10:
../include/linux/kernel.h:37: note: this is the location of the previous definition
37 | #define WRITE 1
../arch/sh/math-emu/math.c:55: warning: "READ" redefined
55 | #define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
In file included from ../arch/sh/math-emu/math.c:10:
../include/linux/kernel.h:36: note: this is the location of the previous definition
36 | #define READ 0
Fixes: 4b565680d163 ("sh: math-emu support")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: [email protected]
Cc: Takashi YOSHII <[email protected]>
---
arch/sh/math-emu/math.c | 44 +++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 22 deletions(-)
--- linux-next-20210528.orig/arch/sh/math-emu/math.c
+++ linux-next-20210528/arch/sh/math-emu/math.c
@@ -51,8 +51,8 @@
#define Rn (regs->regs[n])
#define Rm (regs->regs[m])
-#define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
-#define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
+#define MWRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
+#define MREAD(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
#define PACK_S(r,f) FP_PACK_SP(&r,f)
#define UNPACK_S(f,r) FP_UNPACK_SP(f,&r)
@@ -157,11 +157,11 @@ fmov_idx_reg(struct sh_fpu_soft_struct *
{
if (FPSCR_SZ) {
FMOV_EXT(n);
- READ(FRn, Rm + R0 + 4);
+ MREAD(FRn, Rm + R0 + 4);
n++;
- READ(FRn, Rm + R0);
+ MREAD(FRn, Rm + R0);
} else {
- READ(FRn, Rm + R0);
+ MREAD(FRn, Rm + R0);
}
return 0;
@@ -173,11 +173,11 @@ fmov_mem_reg(struct sh_fpu_soft_struct *
{
if (FPSCR_SZ) {
FMOV_EXT(n);
- READ(FRn, Rm + 4);
+ MREAD(FRn, Rm + 4);
n++;
- READ(FRn, Rm);
+ MREAD(FRn, Rm);
} else {
- READ(FRn, Rm);
+ MREAD(FRn, Rm);
}
return 0;
@@ -189,12 +189,12 @@ fmov_inc_reg(struct sh_fpu_soft_struct *
{
if (FPSCR_SZ) {
FMOV_EXT(n);
- READ(FRn, Rm + 4);
+ MREAD(FRn, Rm + 4);
n++;
- READ(FRn, Rm);
+ MREAD(FRn, Rm);
Rm += 8;
} else {
- READ(FRn, Rm);
+ MREAD(FRn, Rm);
Rm += 4;
}
@@ -207,11 +207,11 @@ fmov_reg_idx(struct sh_fpu_soft_struct *
{
if (FPSCR_SZ) {
FMOV_EXT(m);
- WRITE(FRm, Rn + R0 + 4);
+ MWRITE(FRm, Rn + R0 + 4);
m++;
- WRITE(FRm, Rn + R0);
+ MWRITE(FRm, Rn + R0);
} else {
- WRITE(FRm, Rn + R0);
+ MWRITE(FRm, Rn + R0);
}
return 0;
@@ -223,11 +223,11 @@ fmov_reg_mem(struct sh_fpu_soft_struct *
{
if (FPSCR_SZ) {
FMOV_EXT(m);
- WRITE(FRm, Rn + 4);
+ MWRITE(FRm, Rn + 4);
m++;
- WRITE(FRm, Rn);
+ MWRITE(FRm, Rn);
} else {
- WRITE(FRm, Rn);
+ MWRITE(FRm, Rn);
}
return 0;
@@ -240,12 +240,12 @@ fmov_reg_dec(struct sh_fpu_soft_struct *
if (FPSCR_SZ) {
FMOV_EXT(m);
Rn -= 8;
- WRITE(FRm, Rn + 4);
+ MWRITE(FRm, Rn + 4);
m++;
- WRITE(FRm, Rn);
+ MWRITE(FRm, Rn);
} else {
Rn -= 4;
- WRITE(FRm, Rn);
+ MWRITE(FRm, Rn);
}
return 0;
@@ -445,11 +445,11 @@ id_sys(struct sh_fpu_soft_struct *fregs,
case 0x4052:
case 0x4062:
Rn -= 4;
- WRITE(*reg, Rn);
+ MWRITE(*reg, Rn);
break;
case 0x4056:
case 0x4066:
- READ(*reg, Rn);
+ MREAD(*reg, Rn);
Rn += 4;
break;
default:
Hi Randy!
On 6/3/21 1:14 AM, Randy Dunlap wrote:
> Fix a few build warnings on SUPERH.
>
> Cc: Yoshinori Sato <[email protected]>
> Cc: Rich Felker <[email protected]>
> Cc: [email protected]
>
> [PATCH 1/3] sh: convert xchg() to a statement expression
> [RFC PATCH 2/3] sh: define __BIG_ENDIAN for math-emu
> [PATCH 3/3] sh: fix READ/WRITE redefinition warnings
>
> arch/sh/include/asm/cmpxchg.h | 2 -
> arch/sh/math-emu/math.c | 44 ++++++++++++++++----------------
> arch/sh/math-emu/sfp-util.h | 2 -
> 3 files changed, 24 insertions(+), 24 deletions(-)
Thanks for your patches. I have been pondering to fix these warnings for a while
now glad someone else was quicker than me :-).
I will test your patches later today and see if there are any regressions.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Randy,
On Thu, Jun 3, 2021 at 1:17 AM Randy Dunlap <[email protected]> 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 <[email protected]>
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>?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On 6/3/21 12:54 AM, Geert Uytterhoeven wrote:
> Hi Randy,
>
> On Thu, Jun 3, 2021 at 1:17 AM Randy Dunlap <[email protected]> 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 <[email protected]>
>
> 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>?
Hi Geert,
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 <[email protected]>
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 <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: [email protected]
Cc: Geert Uytterhoeven <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
---
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
Hi Randy,
On Fri, Jun 4, 2021 at 1:19 AM Randy Dunlap <[email protected]> wrote:
> On 6/3/21 12:54 AM, Geert Uytterhoeven wrote:
> > On Thu, Jun 3, 2021 at 1:17 AM Randy Dunlap <[email protected]> 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 <[email protected]>
> >
> > 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 <[email protected]>
> 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 <[email protected]>
> Cc: Yoshinori Sato <[email protected]>
> Cc: Rich Felker <[email protected]>
> Cc: [email protected]
> Cc: Geert Uytterhoeven <[email protected]>
> Cc: John Paul Adrian Glaubitz <[email protected]>
> ---
> 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 <[email protected]>
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 -- [email protected]
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