Re: Passing the complex args in the GPR's

[Joseph Myers]

On Tue, 6 Jun 2023, Andrew Pinski via Gcc wrote:

> You are looking at the wrong ABI document.
> That is for the 64bit ABI.
> The 32bit ABI document is located at:
> http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf
> 
> Plus the 32bit ABI document does not document Complex argument passing
> as it was written in 1995 and never updated.

For the 32-bit ABI see 
https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf
 
(sources at https://github.com/ryanarn/powerabi - power.org has long since 
disappeared).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

[Joseph Myers]

On Thu, 4 Jun 2020, Daniel Kolesa wrote:

> The ELFv2 document specifies things like passing of quadruple precision 
> floats. Indeed, VSX is needed there, but that's not a concern if you 
> *don't* use quadruple precision floats.

My understanding is that the registers used for argument passing are all 
ones that exactly correspond to the Vector registers in earlier 
instruction set versions.  In other words, you could *in principle* 
produce an object, or a whole libm shared library, that (a) passes or 
receives _Float128 values in registers, (b) does not use any instructions 
beyond those available with -mcpu=970, (c) would work as intended whether 
executed on a 970 or on POWER8 and (d) when executed on POWER8, would 
fully interoperate with objects receiving or passing _Float128 values and 
compiled for POWER8 to use VSX instructions for that purpose.  GCC may not 
support _Float128 for older processors, but that doesn't prevent you from 
maintaining patches to add such support.  (But if you want to support 
those 64-bit processors that don't have Vector registers at all, you 
indeed can't use binary128 and interoperate with code using VSX for that 
format in POWER8.)

(Cf. how the Arm hard-float ABI variant works even on processors with 
single-precision-only VFP, because such processors still have the 
double-precision loads and stores although not double-precision 
arithmetic.  When working on that ABI support in GCC some years ago, I 
also made sure that GNU vector types corresponding to NEON vector types 
were passed consistently for the hard-float ABI whether or not any vector 
instructions were present - thus, avoiding depending on the machine modes 
for those vector types because GCC could choose a different machine mode 
depending on the instructions available.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ppc64le and 32-bit LE userland compatibility

[Joseph Myers]

On Mon, 1 Jun 2020, Segher Boessenkool wrote:

> > The supported glibc ABIs are listed at 
> > .
> 
> powerpcle-linux already does work somewhat, and that should also he
> worth something, official or not ;-)
> 
> (It has worked for very many years already...  That is, I have built it
> a lot, I have no idea about running a full distro that way).

Greg McGary's patches as referenced at 
 were 
never merged, and I don't know how big the changes to .S files were or if 
they were ever posted.  Many files were subsequently fixed as part of 
bringing up support for powerpc64le, but without actual 32-bit LE testing 
as part of each release cycle there's not much evidence of correctness for 
LE of code not used for powerpc64le.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ppc64le and 32-bit LE userland compatibility

[Joseph Myers]

On Tue, 2 Jun 2020, Daniel Kolesa wrote:

> not be limited to being just userspace under ppc64le, but should be 
> runnable on a native kernel as well, which should not be limited to any 
> particular baseline other than just PowerPC.

This is a fairly unusual approach to bringing up a new ABI.  Since new 
ABIs are more likely to be used on new systems rather than switching ABI 
on an existing installation, and since it can take quite some time for all 
the software support for a new ABI to become widely available in 
distributions, people developing new ABIs are likely to think about what 
new systems are going to be relevant in a few years' time when working out 
the minimum hardware requirements for the new ABI.  (The POWER8 minimum 
for powerpc64le fits in with that, for example.)

> either the AIX/ELFv1 nor the ELFv2 ABIs) If we were to introduce new 
> ports, what would those use? ld64.so.3 for BE/v2? ld.so.2 for LE/32-bit? 

Rather than relying on numbers such as "3" or 2" in a particular place 
being unique across all (architecture, ABI) pairs supported by glibc, 
something more obviously specific to a particular architecture and ABI, 
e.g. ld-linux-powerpc64be-elfv2.so.1, would be better.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ppc64le and 32-bit LE userland compatibility

[Joseph Myers]

On Mon, 1 Jun 2020, Joseph Myers wrote:

> The minimum supported architecture for powerpc64le (POWER8) has VSX.  My 
> understanding was that the suggestion was for 32-bit userspace to run 
> under powerpc64le kernels running on POWER8 or later, meaning that such a 
> 32-bit LE port, and any ABI designed for such a port, can assume VSX is 
> available.  Or does VSX not work, at the hardware level, for 32-bit 
> POWER8?  (In which case you could pick another ABI for binary128 argument 
> passing and return.)

In fact, my understanding is that the ABI for passing binary128 values in 
vector registers is perfectly implementable for processors with just VMX 
(AltiVec) and not VSX.  So if you do want to support binary128 for a new 
ABI for either 32-bit LE or 32-bit or 64-bit BE, you don't need to require 
VSX for that ABI, you just need to change any GCC requirement for VSX for 
binary128 to allow it with VMX when building for your new ABI.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ppc64le and 32-bit LE userland compatibility

[Joseph Myers]

On Tue, 2 Jun 2020, Daniel Kolesa wrote:

> Are you sure this would be a new port? Glibc already works in this 
> combination, as it seems to me it'd be best if it was just a variant of 
> the existing 32-bit PowerPC port, sharing most conventions besides 
> endianness with the BE port.

The supported glibc ABIs are listed at 
.  This would be a new ABI, 
which should have a new ABI-and-architecture-specific dynamic linker name 
(all new ports are expected to have a unique dynamic linker name for each 
ABI, to support systems using multiarch directory arrangements), new 
symbol versions and avoid legacy features such as 32-bit time or offsets 
or IBM long double.

> 128-bit IEEE long double would not work, since that relies on VSX being 
> present (gcc will explicitly complain if it's not). I'd be all for using 

The minimum supported architecture for powerpc64le (POWER8) has VSX.  My 
understanding was that the suggestion was for 32-bit userspace to run 
under powerpc64le kernels running on POWER8 or later, meaning that such a 
32-bit LE port, and any ABI designed for such a port, can assume VSX is 
available.  Or does VSX not work, at the hardware level, for 32-bit 
POWER8?  (In which case you could pick another ABI for binary128 argument 
passing and return.)

> There is also one more thing while we're at this. The 64-bit big endian 
> Void port uses the ELFv2 ABI, even on glibc. This is not officially 
> supported on glibc as far as I can tell, but it does work out of box, 
> without any patching (things in general match little endian then, i.e. 
> ld64.so.2 etc, but they're big endian). Is there any chance of making 
> that support official?

If you want to support ELFv2 for 64-bit big endian in glibc, again that 
should have a unique dynamic linker name, new symbol versions, only 
binary128 long double, etc. - avoid all the legacy aspects of the existing 
ELFv1 port rather than selectively saying that "ELFv1" itself is the only 
legacy aspect and keeping the others (when it's the others that are 
actually more problematic in glibc).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ppc64le and 32-bit LE userland compatibility

[Joseph Myers]

On Fri, 29 May 2020, Will Springer via Binutils wrote:

> Hey all, a couple of us over in #talos-workstation on freenode have been
> working on an effort to bring up a Linux PowerPC userland that runs in 32-bit
> little-endian mode, aka ppcle. As far as we can tell, no ABI has ever been
> designated for this (unless you count the patchset from a decade ago [1]), so
> it's pretty much uncharted territory as far as Linux is concerned. We want to
> sync up with libc and the relevant kernel folks to establish the best path
> forward.

As a general comment on the glibc side of things, if this is considered 
like a new port, and it probably is, the same principles that apply to new 
ports apply here.

There's a general discussion at 
, although much of that is 
only applicable when adding new CPU architecture support.  More specific 
points include that new 32-bit ports should default to 64-bit time and 
file offsets from the start, with no support for 32-bit time or offsets 
(meaning that if you want to use this with some kind of library call 
translation, the library call translation will need to deal with 
corresponding type size conversions).  And a new port should not be added 
that uses the IBM long double format.  You can use IEEE binary128 long 
double, possibly with an ABI similar to that used on powerpc64le, or can 
use long double = double, but should not support IBM long double, and 
preferably should only have one long double format rather than using the 
glibc support for building with different options resulting in functions 
for different long double formats being called.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: powerpc Linux scv support and scv system call ABI proposal

[Joseph Myers]

On Tue, 28 Jan 2020, Florian Weimer wrote:

> I don't think we can save LR in a regular register around the system
> call, explicitly in the inline asm statement, because we still have to
> generate proper unwinding information using CFI directives, something
> that you cannot do from within the asm statement.

What other architectures in glibc have done for code sequences for 
syscalls that are problematic for compiler-generated CFI is made the C 
syscall macros call separate functions defined in a .S file (see 
sysdeps/unix/sysv/linux/arm/libc-do-syscall.S, 
sysdeps/unix/sysv/linux/i386/libc-do-syscall.S, 
sysdeps/unix/sysv/linux/mips/mips32/mips-syscall[567].S).  I don't know if 
you can do that in this case and still get the performance benefits of the 
new instruction.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

[Joseph Myers]

On Tue, 9 Apr 2019, Florian Weimer wrote:

> diff --git a/sysdeps/unix/sysv/linux/Makefile 
> b/sysdeps/unix/sysv/linux/Makefile
> index 52ac6ad484..4cb5e4f0d2 100644
> --- a/sysdeps/unix/sysv/linux/Makefile
> +++ b/sysdeps/unix/sysv/linux/Makefile
> @@ -156,6 +156,7 @@ endif
>  
>  ifeq ($(subdir),termios)
>  sysdep_headers += termio.h
> +tests += tst-termios2
>  endif

This is missing the addition of bits/termios2-struct.h to the installed 
headers.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 00/15] arch: synchronize syscall tables in preparation for y2038

[Joseph Myers]

On Thu, 10 Jan 2019, Arnd Bergmann wrote:

> - Add system calls that have not yet been integrated into all
>   architectures but that we definitely want there.

glibc has a note that alpha lacks statfs64, any plans for that?

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH] powerpc: fix 32-bit ppc_fadvise64_64 for 64-bit offset

[Joseph Myers]

Consider the following test, built for 32-bit powerpc and run under a
32-bit kernel.

#define _GNU_SOURCE
#include 
#include 
#include 
#include 

int
main (void)
{
  int fd = open ("/dev/null", O_RDWR);
  int ret = posix_fadvise64 (fd, 0, -1, POSIX_FADV_NORMAL);
  if (ret == EINVAL)
puts ("posix_fadvise64 returned EINVAL as expected");
  else
printf ("posix_fadvise64 returned %d, expected EINVAL = %d\n",
ret, EINVAL);
  close (fd);
  return 0;
}

For 32-bit powerpc, posix_fadvise64 uses the fadvise64_64 syscall.
The negative length means it should return EINVAL.

That syscall uses the ppc_fadvise64_64 function to rearrange the
arguments into the form used by the architecture-independent syscall
implementation.  That function calls sys_fadvise64.  sys_fadvise64
uses type size_t for the length argument, and passes its arguments
through to sys_fadvise64_64, which uses type loff_t.

This works OK under a 64-bit kernel, where size_t is 64-bit.  Under a
32-bit kernel, however, passing the length through sys_fadvise64
results in it being truncated to 32-bit size_t and then zero-extended
back to 64-bit, so resulting in 0 rather than EINVAL being returned
for the above test.

This patch fixes this bug by calling sys_fadvise64_64 directly from
ppc_fadvise64_64.

Signed-off-by: Joseph Myers <jos...@codesourcery.com>

---

Please note that I encountered this problem with older kernels, and
while the relevant area has not changed recently and the above
analysis and this patch are based on current sources, I ran into an
unrelated build failure when attempting to build current kernels to
test this fix.  Thus, the patch should only be applied given testing
that the problem is indeed reproducible with current 32-bit kernels
and is fixed by this patch.

diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index de04c9f..7753f77 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -119,8 +119,8 @@ long ppc64_personality(unsigned long personality)
 long ppc_fadvise64_64(int fd, int advice, u32 offset_high, u32 offset_low,
  u32 len_high, u32 len_low)
 {
-   return sys_fadvise64(fd, (u64)offset_high << 32 | offset_low,
-(u64)len_high << 32 | len_low, advice);
+   return sys_fadvise64_64(fd, (u64)offset_high << 32 | offset_low,
+   (u64)len_high << 32 | len_low, advice);
 }
 
 long sys_switch_endian(void)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [powerpc:test 6/9] arch/sh/math-emu/math.c:129:1: warning: ISO C90 forbids mixed declarations and code

[Joseph Myers]

On Wed, 18 Nov 2015, kbuild test robot wrote:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git test
> head:   ebb77ceeb18554a309846f9025a432fe848ddc8e
> commit: a4572d52d6d662db3956d1bc91a745e39a376979 [6/9] sh/math-emu: Move sh 
> from math-emu-old to math-emu
> config: sh-allyesconfig (attached as .config)
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout a4572d52d6d662db3956d1bc91a745e39a376979
> # save the attached .config to linux build tree
> make.cross ARCH=sh 
> 
> All warnings (new ones prefixed by >>):
> 
>In file included from arch/sh/math-emu/math.c:23:0:
>include/math-emu/single.h:76:21: warning: "__BIG_ENDIAN" is not defined 
> [-Wundef]
>In file included from arch/sh/math-emu/math.c:24:0:
>include/math-emu/double.h:81:22: warning: "__BIG_ENDIAN" is not defined 
> [-Wundef]
>arch/sh/math-emu/math.c:54:0: warning: "WRITE" redefined [enabled by 
> default]
>include/linux/fs.h:198:0: note: this is the location of the previous 
> definition
>arch/sh/math-emu/math.c:55:0: warning: "READ" redefined [enabled by 
> default]
>include/linux/fs.h:197:0: note: this is the location of the previous 
> definition
>arch/sh/math-emu/math.c: In function 'fadd':
> >> arch/sh/math-emu/math.c:129:1: warning: ISO C90 forbids mixed declarations 
> >> and code [-Wdeclaration-after-statement]
> >> arch/sh/math-emu/math.c:129:1: warning: ISO C90 forbids mixed declarations 
> >> and code [-Wdeclaration-after-statement]
>arch/sh/math-emu/math.c: In function 'fsub':
>arch/sh/math-emu/math.c:136:1: warning: ISO C90 forbids mixed declarations 
> and code [-Wdeclaration-after-statement]
>arch/sh/math-emu/math.c:136:1: warning: ISO C90 forbids mixed declarations 
> and code [-Wdeclaration-after-statement]

This looks rather like it could be some sort of false positive with the 
warning tracking / pre-existing condition given that only the warnings in 
one function are reported as new.  In any case, diagnostics with macro 
expansion tracking enabled would be more helpful.  But if genuine and not 
specific to the kernel code, I'd suggest using 
-Wno-declaration-after-statement here - as externally maintained code, it 
doesn't make sense to apply such kernel-specific coding-style rules to it.  
(It seems some other architectures disable all warnings when using this 
code.)

-- 
Joseph S. Myers
jos...@codesourcery.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [powerpc:test 7/8] include/math-emu/quad.h:72:1: error: unable to emulate 'TF'

[Joseph Myers]

On Tue, 17 Nov 2015, kbuild test robot wrote:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git test
> head:   e37d8480fbd6b9ad3665ac85a903098413ba67ae
> commit: 71fa67f178c6c3c338d0b99644bce808f2f0965e [7/8] sparc/math-emu: Move 
> sparc from math-emu-old to math-emu
> config: sparc-defconfig (attached as .config)
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 71fa67f178c6c3c338d0b99644bce808f2f0965e
> # save the attached .config to linux build tree
> make.cross ARCH=sparc 
> 
> All errors (new ones prefixed by >>):
> 
>In file included from arch/sparc/math-emu/math_32.c:77:0:
> >> include/math-emu/quad.h:72:1: error: unable to emulate 'TF'
> typedef float TFtype __attribute__ ((mode (TF)));

Is this with a compiler that defaults to -mlong-double-64 (which is, I 
think, now an unusual configuration on SPARC - it might arise for 
bootstrap compilers, but any normal distribution compiler should default 
to -mlong-double-128)?

If so, the old code would have been quietly building with a union that 
contains the "wrong" long double type, when using such a compiler.  And 
actually I think that because of the particular subset of macros used, 
this would have worked; the long double member of the union wouldn't have 
been used in this code.

My inclination would be to use

CFLAGS_math_32.o = -mlong-double-128
CFLAGS_math_64.o = -mlong-double-128

in arch/sparc/math-emu/Makefile to fix this properly (the "unable to 
emulate" error is for modes that fail GCC's scalar_mode_supported_p hook, 
which by default allows the modes for all standard types, hence an error 
for -mlong-double-64 when TFmode isn't used by a standard type).  Untested 
incremental patch follows.

Signed-off-by: Joseph Myers <jos...@codesourcery.com>

---

diff --git a/arch/sparc/math-emu/Makefile b/arch/sparc/math-emu/Makefile
index 825dbee..6df8769 100644
--- a/arch/sparc/math-emu/Makefile
+++ b/arch/sparc/math-emu/Makefile
@@ -5,4 +5,9 @@
 # suppress all warnings - as math.c produces a lot!
 ccflags-y := -w
 
+# Emulation of quad instructions requires -mlong-double-128 for
+# __attribute__ ((mode (TF))) to be accepted.
+CFLAGS_math_32.o = -mlong-double-128
+CFLAGS_math_64.o = -mlong-double-128
+
 obj-y:= math_$(BITS).o


-- 
Joseph S. Myers
jos...@codesourcery.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Ping Re: [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp

[Joseph Myers]

On Thu, 20 Aug 2015, Michael Ellerman wrote:

 On Wed, 2015-08-19 at 14:39 +, Joseph Myers wrote:
  I'd like to ping this patch series, not having seen any comments on it.
  
  [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp
  https://lkml.org/lkml/2015/7/2/394
  
  [PATCH 1/8] math-emu: Move math-emu to math-emu-old
  https://lkml.org/lkml/2015/7/2/395
  
  [PATCH 2/8] math-emu: Import current glibc soft-fp as include/math-emu
  https://lkml.org/lkml/2015/7/2/398
  
  [PATCH 3/8] alpha/math-emu: Move alpha from math-emu-old to math-emu
  https://lkml.org/lkml/2015/7/2/399
  
  [PATCH 4/8] powerpc/math-emu: Move powerpc from math-emu-old to math-emu
  https://lkml.org/lkml/2015/7/2/400
  
  [PATCH 5/8] s390/math-emu: Move s390 from math-emu-old to math-emu
  https://lkml.org/lkml/2015/7/2/401
  
  [PATCH 6/8] sh/math-emu: Move sh from math-emu-old to math-emu
  https://lkml.org/lkml/2015/7/2/402
  
  [PATCH 7/8] sparc/math-emu: Move sparc from math-emu-old to math-emu
  https://lkml.org/lkml/2015/7/2/404
  
  [PATCH 8/8] math-emu: Remove math-emu-old
  https://lkml.org/lkml/2015/7/2/405
  
  As noted in patch 0, the dependencies are as follows: patch 2 depends on 
  patch 1, patches 3-7 depend on patches 1 and 2 but are independent of each 
  other, patch 8 depends on all the other patches.
 
 Hi Joseph,
 
 I have done some testing on powerpc, and it seems good.
 
 I'm reluctant to proceed with merging them though until we've heard at least
 *something* from the other maintainers.

Ping again for the other-architecture maintainers (alpha, s390, sh, 
sparc)

-- 
Joseph S. Myers
jos...@codesourcery.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Ping Re: [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp

[Joseph Myers]

I'd like to ping this patch series, not having seen any comments on it.

[PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp
https://lkml.org/lkml/2015/7/2/394

[PATCH 1/8] math-emu: Move math-emu to math-emu-old
https://lkml.org/lkml/2015/7/2/395

[PATCH 2/8] math-emu: Import current glibc soft-fp as include/math-emu
https://lkml.org/lkml/2015/7/2/398

[PATCH 3/8] alpha/math-emu: Move alpha from math-emu-old to math-emu
https://lkml.org/lkml/2015/7/2/399

[PATCH 4/8] powerpc/math-emu: Move powerpc from math-emu-old to math-emu
https://lkml.org/lkml/2015/7/2/400

[PATCH 5/8] s390/math-emu: Move s390 from math-emu-old to math-emu
https://lkml.org/lkml/2015/7/2/401

[PATCH 6/8] sh/math-emu: Move sh from math-emu-old to math-emu
https://lkml.org/lkml/2015/7/2/402

[PATCH 7/8] sparc/math-emu: Move sparc from math-emu-old to math-emu
https://lkml.org/lkml/2015/7/2/404

[PATCH 8/8] math-emu: Remove math-emu-old
https://lkml.org/lkml/2015/7/2/405

As noted in patch 0, the dependencies are as follows: patch 2 depends on 
patch 1, patches 3-7 depend on patches 1 and 2 but are independent of each 
other, patch 8 depends on all the other patches.

-- 
Joseph S. Myers
jos...@codesourcery.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 4/8] powerpc/math-emu: Move powerpc from math-emu-old to math-emu

[Joseph Myers]

From: Joseph Myers jos...@codesourcery.com

This patch moves powerpc from math-emu-old to math-emu, updating it
for the API changes.

The following cleanups or bug fixes (that might change how the
emulation behaves, or that go beyond mechanical conversion to new
APIs) are included in this patch because of their close connection to
the API changes:

* On PowerPC, fused multiply-add operations now use the new soft-fp
  fma support (meaning they are properly fused rather than only having
  3 extra bits precision on the intermediate result of the
  multiplication).

* On PowerPC for SPE floating-point emulation, the pre-existing bug of
  comparisons using cooked unpacking is fixed (as the structure of the
  code meant unpacking types naturally needed specifying explicitly
  for all operations).  This should not in fact change how the
  emulation behaves, other than making it more efficient.  Various
  operations that should not have unpacked at all now no longer unpack
  instead of using cooked unpacking, so avoiding spurious exceptions
  on signaling NaNs (on the other case of arguments that are actually
  a different floating-point type but would wrongly be interpreted as
  signaling NaNs by the unpacking, FP_CLEAR_EXCEPTIONS may have
  avoided the issue).

Signed-off-by: Joseph Myers jos...@codesourcery.com

---

diff --git a/arch/powerpc/include/asm/sfp-machine.h 
b/arch/powerpc/include/asm/sfp-machine.h
index d89beab..607ee14 100644
--- a/arch/powerpc/include/asm/sfp-machine.h
+++ b/arch/powerpc/include/asm/sfp-machine.h
@@ -82,6 +82,9 @@
 #define _FP_MUL_MEAT_S(R,X,Y)   
_FP_MUL_MEAT_1_wide(_FP_WFRACBITS_S,R,X,Y,umul_ppmm)
 #define _FP_MUL_MEAT_D(R,X,Y)   
_FP_MUL_MEAT_2_wide(_FP_WFRACBITS_D,R,X,Y,umul_ppmm)
 
+#define _FP_MUL_MEAT_DW_S(R,X,Y)   
_FP_MUL_MEAT_DW_1_wide(_FP_WFRACBITS_S,R,X,Y,umul_ppmm)
+#define _FP_MUL_MEAT_DW_D(R,X,Y)   
_FP_MUL_MEAT_DW_2_wide(_FP_WFRACBITS_D,R,X,Y,umul_ppmm)
+
 #define _FP_DIV_MEAT_S(R,X,Y)  _FP_DIV_MEAT_1_udiv_norm(S,R,X,Y)
 #define _FP_DIV_MEAT_D(R,X,Y)  _FP_DIV_MEAT_2_udiv(D,R,X,Y)
 
@@ -96,6 +99,7 @@
 #define _FP_NANSIGN_Q  0
 
 #define _FP_KEEPNANFRACP 1
+#define _FP_QNANNEGATEDP 0
 
 #ifdef FP_EX_BOOKE_E500_SPE
 #define FP_EX_INEXACT  (1  21)
@@ -178,15 +182,40 @@
_FP_PACK_RAW_2_P(D, val, X);\
} while (0)
 
+#define __FP_PACK_SEMIRAW_D(val,X) \
+   do {
\
+   _FP_PACK_SEMIRAW(D, 2, X);  \
+   if (!FP_CUR_EXCEPTIONS || !__FPU_TRAP_P(FP_CUR_EXCEPTIONS)) \
+   _FP_PACK_RAW_2_P(D, val, X);\
+   } while (0)
+
 #define __FP_PACK_DS(val,X)
\
do {
\
   FP_DECL_S(__X);  
\
-  FP_CONV(S, D, 1, 2, __X, X); 
\
+  if (X##_c != FP_CLS_NAN) 
\
+  _FP_FRAC_SRS_2(X, _FP_WFRACBITS_D - _FP_WFRACBITS_S, 
\
+  _FP_WFRACBITS_D);
\
+  else 
\
+  _FP_FRAC_SRL_2(X, _FP_WFRACBITS_D - _FP_WFRACBITS_S);
\
+  _FP_FRAC_COPY_1_2(__X, X);   
\
+  __X##_e = X##_e; 
\
+  __X##_c = X##_c; 
\
+  __X##_s = X##_s; 
\
   _FP_PACK_CANONICAL(S, 1, __X);   
\
   if (!FP_CUR_EXCEPTIONS || !__FPU_TRAP_P(FP_CUR_EXCEPTIONS)) {
\
-  _FP_UNPACK_CANONICAL(S, 1, __X); 
\
-  FP_CONV(D, S, 2, 1, X, __X); 
\
-  _FP_PACK_CANONICAL(D, 2, X); 
\
+  FP_EXTEND(D, S, 2, 1, X, __X);   
\
+  if (!FP_CUR_EXCEPTIONS || !__FPU_TRAP_P(FP_CUR_EXCEPTIONS))  
\
+  _FP_PACK_RAW_2_P(D, val, X); 
\
+  }
\
+   } while (0)
+
+#define __FP_PACK_SEMIRAW_DS(val,X)
\
+   do {
\
+  FP_DECL_S(__X);  
\
+  FP_TRUNC(S, D, 1, 2, __X, X);
\
+  _FP_PACK_SEMIRAW(S, 1, __X

[PATCH 1/8] math-emu: Move math-emu to math-emu-old

[Joseph Myers]

From: Joseph Myers jos...@codesourcery.com

The include/math-emu code (used for alpha powerpc sh sparc, and to a
very limited extent for s390) was taken from an old version of glibc's
soft-fp code around 15 years ago (in the pre-git era, anyway, and some
of the initial code may have been developed around 1997-9 with a view
to being used in both places).  Since then, there have only been a
handful of small changes in the kernel version, while the glibc
version has been extensively developed, with many bug fixes,
performance improvements and miscellaneous cleanups, and is also now
used in libgcc, including for __float128 on x86_64 since GCC 4.3 (see
https://ols.fedoraproject.org/GCC/Reprints-2006/sidwell-reprint.pdf
for more information regarding performance improvements and use in
libgcc).

Thus the kernel version is missing those various improvements and it
would make sense to update it to include them (as was noted back in
2006 https://sourceware.org/ml/libc-alpha/2006-02/msg00075.html when
a large group of changes went into glibc).  I believe it also makes
sense to aim to have *exactly* the same code in both places to
simplify future updates of the kernel version.  (And in particular, as
external code imported largely verbatim into the kernel,
include/math-emu has never followed the kernel coding style and it
doesn't make sense for it to do so.)

I made an analysis of what kernel-local changes there were to this
code in https://sourceware.org/ml/libc-alpha/2013-10/msg00345.html,
and since then have added the various missing features to the glibc
version so that it is feature-complete regarding features used in the
kernel and so that exactly the same code is usable in both places.

This patch moves the include/math-emu code to math-emu-old, updating
#includes, in preparation for importing glibc's current soft-fp code
as include/math-emu without requiring all architectures to be updated
for API changes at the same time.

Signed-off-by: Joseph Myers jos...@codesourcery.com

---

diff --git a/arch/alpha/math-emu/math.c b/arch/alpha/math-emu/math.c
index 58c2669..917196e 100644
--- a/arch/alpha/math-emu/math.c
+++ b/arch/alpha/math-emu/math.c
@@ -6,9 +6,9 @@
 #include asm/uaccess.h
 
 #include sfp-util.h
-#include math-emu/soft-fp.h
-#include math-emu/single.h
-#include math-emu/double.h
+#include math-emu-old/soft-fp.h
+#include math-emu-old/single.h
+#include math-emu-old/double.h
 
 #defineOPC_PAL 0x00
 #define OPC_INTA   0x10
diff --git a/arch/powerpc/math-emu/fadd.c b/arch/powerpc/math-emu/fadd.c
index 0158a16..3c821be 100644
--- a/arch/powerpc/math-emu/fadd.c
+++ b/arch/powerpc/math-emu/fadd.c
@@ -3,8 +3,8 @@
 #include asm/uaccess.h
 
 #include asm/sfp-machine.h
-#include math-emu/soft-fp.h
-#include math-emu/double.h
+#include math-emu-old/soft-fp.h
+#include math-emu-old/double.h
 
 int
 fadd(void *frD, void *frA, void *frB)
diff --git a/arch/powerpc/math-emu/fadds.c b/arch/powerpc/math-emu/fadds.c
index 5930f40..14bc579 100644
--- a/arch/powerpc/math-emu/fadds.c
+++ b/arch/powerpc/math-emu/fadds.c
@@ -3,9 +3,9 @@
 #include asm/uaccess.h
 
 #include asm/sfp-machine.h
-#include math-emu/soft-fp.h
-#include math-emu/double.h
-#include math-emu/single.h
+#include math-emu-old/soft-fp.h
+#include math-emu-old/double.h
+#include math-emu-old/single.h
 
 int
 fadds(void *frD, void *frA, void *frB)
diff --git a/arch/powerpc/math-emu/fcmpo.c b/arch/powerpc/math-emu/fcmpo.c
index 5bce011..3c4afbf 100644
--- a/arch/powerpc/math-emu/fcmpo.c
+++ b/arch/powerpc/math-emu/fcmpo.c
@@ -3,8 +3,8 @@
 #include asm/uaccess.h
 
 #include asm/sfp-machine.h
-#include math-emu/soft-fp.h
-#include math-emu/double.h
+#include math-emu-old/soft-fp.h
+#include math-emu-old/double.h
 
 int
 fcmpo(u32 *ccr, int crfD, void *frA, void *frB)
diff --git a/arch/powerpc/math-emu/fcmpu.c b/arch/powerpc/math-emu/fcmpu.c
index d4fb1ba..948d9db 100644
--- a/arch/powerpc/math-emu/fcmpu.c
+++ b/arch/powerpc/math-emu/fcmpu.c
@@ -3,8 +3,8 @@
 #include asm/uaccess.h
 
 #include asm/sfp-machine.h
-#include math-emu/soft-fp.h
-#include math-emu/double.h
+#include math-emu-old/soft-fp.h
+#include math-emu-old/double.h
 
 int
 fcmpu(u32 *ccr, int crfD, void *frA, void *frB)
diff --git a/arch/powerpc/math-emu/fctiw.c b/arch/powerpc/math-emu/fctiw.c
index f694440..d3efc14 100644
--- a/arch/powerpc/math-emu/fctiw.c
+++ b/arch/powerpc/math-emu/fctiw.c
@@ -3,8 +3,8 @@
 #include asm/uaccess.h
 
 #include asm/sfp-machine.h
-#include math-emu/soft-fp.h
-#include math-emu/double.h
+#include math-emu-old/soft-fp.h
+#include math-emu-old/double.h
 
 int
 fctiw(u32 *frD, void *frB)
diff --git a/arch/powerpc/math-emu/fctiwz.c b/arch/powerpc/math-emu/fctiwz.c
index 71e782f..cce3457 100644
--- a/arch/powerpc/math-emu/fctiwz.c
+++ b/arch/powerpc/math-emu/fctiwz.c
@@ -3,8 +3,8 @@
 #include asm/uaccess.h
 
 #include asm/sfp-machine.h
-#include math-emu/soft-fp.h
-#include math-emu/double.h
+#include math-emu-old/soft-fp.h
+#include math-emu-old

[PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp

[Joseph Myers]

From: Joseph Myers jos...@codesourcery.com

The include/math-emu code (used for alpha powerpc sh sparc, and to a
very limited extent for s390) was taken from an old version of glibc's
soft-fp code around 15 years ago (in the pre-git era, anyway, and some
of the initial code may have been developed around 1997-9 with a view
to being used in both places).  Since then, there have only been a
handful of small changes in the kernel version, while the glibc
version has been extensively developed, with many bug fixes,
performance improvements and miscellaneous cleanups, and is also now
used in libgcc, including for __float128 on x86_64 since GCC 4.3 (see
https://ols.fedoraproject.org/GCC/Reprints-2006/sidwell-reprint.pdf
for more information regarding performance improvements and use in
libgcc).

Thus the kernel version is missing those various improvements and it
would make sense to update it to include them (as was noted back in
2006 https://sourceware.org/ml/libc-alpha/2006-02/msg00075.html when
a large group of changes went into glibc).  I believe it also makes
sense to aim to have *exactly* the same code in both places to
simplify future updates of the kernel version.  (And in particular, as
external code imported largely verbatim into the kernel,
include/math-emu has never followed the kernel coding style and it
doesn't make sense for it to do so.)

I made an analysis of what kernel-local changes there were to this
code in https://sourceware.org/ml/libc-alpha/2013-10/msg00345.html,
and since then have added the various missing features to the glibc
version so that it is feature-complete regarding features used in the
kernel and so that exactly the same code is usable in both places.
This patch series updates the include/math-emu code, and its kernel
users, so that the shared code is identical to glibc's current soft-fp
code.

Regarding what testing seems appropriate for this patch series, see my
notes in https://sourceware.org/ml/libc-alpha/2015-02/msg00107.html.
I've done that testing for powerpc (both e500 and emulation of classic
hard float).  For reports of testing on other architectures, see
https://sourceware.org/ml/libc-alpha/2015-05/msg00372.html (alpha),
https://sourceware.org/ml/libc-alpha/2015-04/msg00154.html (s390),
http://marc.info/?l=linux-shm=142440262415395w=2 (sh),
http://marc.info/?l=linux-sparcm=142437304707509w=2 (sparc); the
fixes indicated in those reports as needed on particular architectures
have been integrated into this version.

The bulk of the changes are updating the code from glibc, and a
detailed review of that part probably does not make sense in this
context if you want to aim for the same code in both places.  The
trickier part is the architecture updates for the various API changes
in soft-fp since the version used by the kernel.  The following
changes have occurred in the soft-fp API since the version used in the
kernel and so are addressed in the architecture updates in this patch
series.  (This list only includes changes relating to features used in
the kernel, not pure new features that aren't relevant to updating
existing code, and not pure bug fixes.)

* https://sourceware.org/ml/libc-alpha/2006-02/msg00028.html

  - Semi-raw unpacking is added, as something intermediate between raw
and cooked unpacking, for efficiency.

  - Addition and subtraction are changed to work on semi-raw values.
Thus, cooked results of multiplication can't be passed directly
into addition, as was done in some kernel emulations of fused
multiply-add, but that isn't a proper fused operation anyway (a
proper fused operation involves using the unrounded multiplication
result in twice the input precision, not an intermediate value in
input precision plus three working bits); the appropriate fix is
to use the new fused multiply-add support in soft-fp.

  - Conversions from one floating-point type to another now use
FP_EXTEND (raw) and FP_TRUNC (semi-raw) instead of FP_CONV
(cooked).  Those operations now deal with quieting signaling NaNs.

  - Conversions from floating-point to integer now use raw inputs, and
require the integer variable passed to the FP_TO_INT macros to
have unsigned type.

  - Conversions from integer to floating-point now use raw outputs.

* https://sourceware.org/ml/libc-alpha/2006-02/msg00044.html

  - Conversions from integer to floating-point now pass the name of an
unsigned type to the FP_FROM_INT macros, not a signed type to
which unsigned is added in the macro definition.

* https://sourceware.org/ml/libc-alpha/2013-04/msg00646.html

  - soft-fp supports the reversed quiet NaN convention used on MIPS
and HPPA; sfp-machine.h must define _FP_QNANNEGATEDP (to 0, for
architectures using the normal convention; to 1, for architectures
using the MIPS convention).

* https://sourceware.org/ml/libc-alpha/2013-10/msg00348.html

  - Negation now works on raw values.

* https://sourceware.org/ml/libc-alpha/2014

Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

[Joseph Myers]

On Tue, 30 Jun 2015, Michael Ellerman wrote:

 Is there some way you can imagine of splitting this up into smaller chunks, so
 that different arches can merge the pieces separately?

Well, it could be split as:

1. Rename include/math-emu to math-emu-old and update architectures for 
the renaming (mechanically).

2. Add new include/math-emu.

3,4,5,6,7. Move each architecture from math-emu-old to math-emu.

8. Remove math-emu-old.

You still have patch 1 affecting all five architectures, but with the 
per-architecture changes being much simpler.

-- 
Joseph S. Myers
jos...@codesourcery.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Ping Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

[Joseph Myers]

Ping.  This patch https://lkml.org/lkml/2015/6/22/266 is pending review.

-- 
Joseph S. Myers
jos...@codesourcery.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC] Update kernel math-emu code from current glibc soft-fp

[Joseph Myers]

On Thu, 19 Feb 2015, David Miller wrote:

 From: Joseph Myers jos...@codesourcery.com
 Date: Fri, 6 Feb 2015 17:25:29 +
 
  * On SPARC, comparisons now use raw unpacking (this should not in fact
change how the emulation behaves, just make it more efficient).
 
 I did a sparc64 test build and it failed like so:
 
 arch/sparc/math-emu/math_64.c: In function ‘do_mathemu’:
 arch/sparc/math-emu/math_64.c:487:1: error: expected expression before 
 ‘return’
 arch/sparc/math-emu/math_64.c:488:1: error: expected expression before 
 ‘return’
 arch/sparc/math-emu/math_64.c:490:1: error: expected expression before 
 ‘return’
 arch/sparc/math-emu/math_64.c:491:1: error: expected expression before 
 ‘return’
 arch/sparc/math-emu/math_64.c:495:1: error: expected expression before 
 ‘return’
 
 I'm attaching a CPP processed math_64.c for your convenience:

Please try this patch on top of the previous one.  The way abort is 
redefined in the kernel code doesn't work for one place using it in an 
expression; this patch changes a comma expression to a statement 
expression.  This didn't appear in my powerpc testing because the powerpc 
emulation never uses FP_FROM_INT; I'm not sure how Kaz's sh testing 
avoided the problem appearing there.

diff --git a/include/math-emu/op-common.h b/include/math-emu/op-common.h
index b9f5e1a..8c059c3 100644
--- a/include/math-emu/op-common.h
+++ b/include/math-emu/op-common.h
@@ -1818,7 +1818,7 @@
 X##_e = (_FP_EXPBIAS_##fs + 2 * _FP_W_TYPE_SIZE - 1 \
  - _FP_FROM_INT_lz);   \
   })   \
-: (abort (), 0))); \
+: ({ abort (); 0; })));\
\
  if ((rsize) - 1 + _FP_EXPBIAS_##fs = _FP_EXPMAX_##fs \
   X##_e = _FP_EXPMAX_##fs)  \

-- 
Joseph S. Myers
jos...@codesourcery.com___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC] Update kernel math-emu code from current glibc soft-fp

[Joseph Myers]

On Fri, 6 Feb 2015, Randy Dunlap wrote:

 On 02/06/15 09:25, Joseph Myers wrote:
  At this point this patch is an RFC rather than yet being ready for
  inclusion, because I've only tested it for powerpc (both e500 and
  emulation of classic hard float); it's quite likely there are bugs in
  the changes for other architectures, quite possibly breaking the
  build.  I've also posted it to libc-alpha
  https://sourceware.org/ml/libc-alpha/2015-02/msg00107.html with a
  call for testing and notes on what testing might be appropriate.
 
 Is there a test suite?

In practice, the current glibc testsuite (make math/tests then look in 
math/subdir-tests.sum for FAILs and examine those in more detail - some 
may well be pre-existing and appear without my patch) provides pretty 
thorough coverage of basic floating-point operations.  There are at least 
two pre-existing bugs in the powerpc emulation that show up that way 
(running the testsuite, built for classic hard-float, on a processor where 
classic hard-float isn't supported in hardware), but as they are 
independent of this update I put them on my list of issues to look at 
later.  Various of the issues I fixed in Nov/Dec 2013 with the powerpc 
e500 SPE float emulation were also found through the glibc testsuite.

People have also used other testsuites such as TestFloat and ucbtest in 
the past to validate floating-point emulation (ucbtest was used to 
validate some of the past soft-fp changes, for example).  All of these end 
up testing some combination of compiler, library, hardware and kernel so 
it's not always immediately obvious where a failure is coming from.  If 
there are architectural tests of instruction semantics available, those 
could be used and might validate choices of results where they aren't 
fully specified by IEEE 754 (of course, the existing code may not always 
make such choices in a way that matches the hardware, either).  There 
isn't a testsuite specific to soft-fp.

-- 
Joseph S. Myers
jos...@codesourcery.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev