This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4 06/10] RISC-V: Regenerate ULPs of RISC-V
Joseph Myers <joseph@codesourcery.com> 於 2018年12月4日 週二 上午2:11寫道:
>
> On Sat, 1 Dec 2018, Zong Li wrote:
>
> > @@ -532,16 +532,16 @@ double: 1
> > float: 1
> > idouble: 1
> > ifloat: 1
> > -ildouble: 1
> > -ldouble: 1
> > +ildouble: 8
> > +ldouble: 8
> >
> > Function: Imaginary part of "catan":
> > double: 1
> > float: 1
> > idouble: 1
> > ifloat: 1
> > -ildouble: 1
> > -ldouble: 1
> > +ildouble: 4
> > +ldouble: 4
>
> This, and the corresponding changes for catanh and in the rvd file, looks
> wrong.
>
> If you look at the results for AArch64, or for float128 for x86_64, you'll
> see those have 1ulp here. All these architectures use software floating
> point for the binary128 format, so there is no question of differences in
> contracting multiply and add into a fused operation producing different
> results; rather, the functions for this format should produce identical
> results on all such architectures (they might produce slightly different
> results in some cases on architectures, such as S/390 and POWER9, where
> there is hardware support for this format, if that hardware support
> results in the compiler producing fused operations).
>
> So having different results suggests you either have a soft-fp bug, or a
> bug in how soft-fp is configured for RISC-V (or specifically for 32-bit
> RISC-V). You should find what inputs produce different results on RISC-V
> from AArch64 or x86_64 float128 and trace through the function calls in
> question to determine exactly which arithmetic operation is producing
> different results, so you can see what result is correct and where the bug
> is.
>
Ok, I would check this and compare the result with AArch64 or x84_64 float128.