Inconsistent libm-err ULP Table Generation for RISC-V

Inconsistent libm-err ULP Table Generation for RISC-V

[Tom Coldrick]

Hi,

While performing some reproducibility testing of glibc builds, we noticed that
the ULP values for RISC-V in the libm section of libc.info-8 can change between
builds. The root cause of this is that both
sysdeps/riscv/rv32/rvd/libm-test-ulps-name and
sysdeps/riscv/rv64/rvd/libm-test-ulps-name contain "RISC-V", which means they
collide in the generation of the table.

The net result is that the values in the ULP value table could be either the
32-bit variant or the 64-bit variant, with no indication as to which is used.
The determining factor of which is used is an unsorted call to Python's
os.walk(), which gives results in an order dependent upon the filesystem
implementation on which it was called (that is, whatever order readdir() gives.)
This can cause reproducibility issues, as well as meaning that the values in the
manual are unclear on which variant they are for.

I noticed that MIPS has 32- and 64-bit variants in separate columns, should this
be done for RISC-V too?

Thanks,

-- 
Tom Coldrick                                https://www.codethink.co.uk
(He/Him)

Re: Inconsistent libm-err ULP Table Generation for RISC-V

[Florian Weimer]

* Tom Coldrick via Libc-alpha:

> While performing some reproducibility testing of glibc builds, we noticed that
> the ULP values for RISC-V in the libm section of libc.info-8 can change between
> builds. The root cause of this is that both
> sysdeps/riscv/rv32/rvd/libm-test-ulps-name and
> sysdeps/riscv/rv64/rvd/libm-test-ulps-name contain "RISC-V", which means they
> collide in the generation of the table.
>
> The net result is that the values in the ULP value table could be either the
> 32-bit variant or the 64-bit variant, with no indication as to which is used.
> The determining factor of which is used is an unsorted call to Python's
> os.walk(), which gives results in an order dependent upon the filesystem
> implementation on which it was called (that is, whatever order readdir() gives.)
> This can cause reproducibility issues, as well as meaning that the values in the
> manual are unclear on which variant they are for.
>
> I noticed that MIPS has 32- and 64-bit variants in separate columns, should this
> be done for RISC-V too?

I guess you could also have a shared sysdeps/riscv/libm-test-ulps-name
file.  Is it valuable to track accuracy separately for different RISC-V
variants?

Thanks,
Florian

Re: Inconsistent libm-err ULP Table Generation for RISC-V

[Joseph Myers]

On Fri, 11 Feb 2022, Florian Weimer via Libc-alpha wrote:

> > I noticed that MIPS has 32- and 64-bit variants in separate columns, 
> > should this be done for RISC-V too?
> 
> I guess you could also have a shared sysdeps/riscv/libm-test-ulps-name
> file.  Is it valuable to track accuracy separately for different RISC-V
> variants?

There should be one libm-test-ulps-name file for each libm-test-ulps file, 
and each should have a different name.

MIPS has separate files because MIPS32 has long double = double.

There's an orthogonal question of whether we could find a way to share 
libm-test-ulps files for the common case of architectures that (a) don't 
have any architecture-specific implementations of any libm functions not 
fully determined by IEEE semantics, (b) don't use ldbl-96 or ldbl-128ibm 
and (c) don't have float128 supported as a distinct format from long 
double.  In other words, everything other than x86_64, i386, ia64, m68k 
and powerpc, I think.  There's still some variation between those 
architectures (they vary in whether they have long double = double or = 
binary128, whether rounding modes and exceptions support is available, 
whether contraction to produce fused multiply-add occurs).  But they're 
still similar enough it might make sense to have just one or two 
libm-test-ulps files with the maximum known ulps across all those 
architectures.  (And (c) is probably not an essential point if any of 
those architectures gets float128 support in future.  Nor should float16 
support be an essential issue for sharing libm-test-ulps files, if we add 
float16 functions to glibc in future.)

-- 
Joseph S. Myers
joseph@codesourcery.com