> > Ya, makes sense -- I guess the current values aren't that exciting for > execution, but we could just add some more interesting ones...
During the development of the patch, I have an issue with large numbers (2e34, -2e34). They are used in gfortran.fortran-torture/execute/intrinsic_aint_anint.f90 test. Besides that, a benchmark from Spec 2017 also failed (can not remember which one), Now we haven't an issue with them, Of course, I can add additional tests with large numbers. But it will be double-check (first fortran's test) On Wed, May 22, 2024 at 11:19 PM Palmer Dabbelt <pal...@dabbelt.com> wrote: > On Wed, 22 May 2024 12:02:26 PDT (-0700), jeffreya...@gmail.com wrote: > > > > > > On 5/22/24 12:15 PM, Palmer Dabbelt wrote: > >> On Wed, 22 May 2024 11:01:16 PDT (-0700), jeffreya...@gmail.com wrote: > >>> > >>> > >>> On 5/22/24 6:47 AM, Jivan Hakobyan wrote: > >>>> After 8367c996e55b2 commit several checks on round_32.c test started > to > >>>> fail. > >>>> The reason is that we prevent rounding DF->SI->DF on RV32 and instead > of > >>>> a conversation sequence we get calls to appropriate library functions. > >>>> > >>>> > >>>> gcc/testsuite/ChangeLog: > >>>> * testsuite/gcc.target/riscv/round_32.c: Fixed test > >>> I wonder if this test even makes sense for rv32 anymore given we can't > >>> do a DF->DI as a single instruction and DF->SI is going to give > >>> incorrect results. So the underlying optimization to improve those > >>> rounding cases just doesn't apply to DF mode objects for rv32. > >>> > >>> Thoughts? > >> > >> Unless I'm missing something, we should still be able to do the float > >> roundings on rv32? > > I initially thought that as well. The problem is we don't have a DF->DI > > conversion instruction for rv32. We can't use DF->SI as the range of > > representable values is wrong. > > Ya, right. I guess we'd need to be calling roundf(), not round(), for > those? So maybe we should adjust the tests to do that? > > >> I think with Zfa we'd also have testable sequences for the double/double > >> and float/float roundings, which could be useful to test. I'm not > >> entirely sure there, though, as I always get a bit lost in which FP > >> rounding flavors map down. > > Zfa is a different story as it has instructions with the proper > > semantics ;-) We'd just emit those new instructions and wouldn't have > > to worry about the initial range test. > > and I guess that'd just be an entirely different set of scan-assembly > sets than round_32 or round_64, so maybe it's not a reason to keep these > around. > > >> I'd also kicked off some run trying to promote these to executable > >> tests. IIRC it was just DG stuff (maybe just adding a `dg-do run`?) > >> but I don't know where I stashed the results... > > Not a bad idea, particularly if we test the border cases. > > Ya, makes sense -- I guess the current values aren't that exciting for > execution, but we could just add some more interesting ones... > > > jeff > -- With the best regards Jivan Hakobyan
