>
> 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 <palmer@dabbelt.com> wrote:

> On Wed, 22 May 2024 12:02:26 PDT (-0700), jeffreyalaw@gmail.com wrote:
> >
> >
> > On 5/22/24 12:15 PM, Palmer Dabbelt wrote:
> >> On Wed, 22 May 2024 11:01:16 PDT (-0700), jeffreyalaw@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