Disable tests that require fesetround() on platforms without it

  Some tests check for fenv and then proceed to use fesetround() directly,
but some platforms (at least RISC-V soft-float) have fenv but don't
support rounding modes.  This adds a DG check that fesetround() actually
functions, which is then used by all the tests that call fesetround()
explicitly.

gcc/testsuite/ChangeLog

	* lib/target-supports.exp
	(check_effective_target_fenv_setround): New function.
	* gcc.dg/torture/fp-double-convert-float-1.c: Check
	fenv_fesetround.
	* gcc.dg/torture/fp-int-convert-float128-timode-3.c: Likewise.
	* gcc.dg/torture/fp-int-convert-timode-2.c: Likewise.
	* gcc.dg/torture/fp-int-convert-timode-3.c: Likewise.
	* gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.
	* gcc.dg/torture/fp-uint64-convert-double-1.c: Likewise.
	* gcc.dg/torture/fp-uint64-convert-double-2.c: Likewise.

---

I started getting a bunch of atomic-related failures with this patch,
but they persist when I've gone back and disabled it so I'm pretty sure
it's something in my environment.  Without this patch I get a bunch of
failures on the RISC-V soft float targets, I haven't tried anywhere
else.
---
 .../gcc.dg/torture/fp-double-convert-float-1.c |  2 +-
 .../torture/fp-int-convert-float128-timode-3.c |  2 +-
 .../gcc.dg/torture/fp-int-convert-timode-2.c   |  2 +-
 .../gcc.dg/torture/fp-int-convert-timode-3.c   |  2 +-
 .../gcc.dg/torture/fp-int-convert-timode-4.c   |  2 +-
 .../torture/fp-uint64-convert-double-1.c       |  2 +-
 .../torture/fp-uint64-convert-double-2.c       |  2 +-
 gcc/testsuite/lib/target-supports.exp          | 18 ++++++++++++++++++
 8 files changed, 25 insertions(+), 7 deletions(-)
  

On Thu, 28 Apr 2022, Palmer Dabbelt wrote:

> +proc check_effective_target_fenv_setround {} {
> +  return [check_runtime fenv_setround {
> +    #include <fenv.h>
> +    #include <stdlib.h>
> +    int
> +    main (void)
> +    {
> +      if (fesetround (1) == 0)

There is no reason to expect that 1 is a valid argument to fesetround.  
(It isn't with x86 glibc, for example.)  You need to use whatever FE_* 
rounding mode macro the test in question cares about.
  

On Thu, 28 Apr 2022 15:12:39 PDT (-0700), joseph@codesourcery.com wrote:
> On Thu, 28 Apr 2022, Palmer Dabbelt wrote:
>
>> +proc check_effective_target_fenv_setround {} {
>> +  return [check_runtime fenv_setround {
>> +    #include <fenv.h>
>> +    #include <stdlib.h>
>> +    int
>> +    main (void)
>> +    {
>> +      if (fesetround (1) == 0)
>
> There is no reason to expect that 1 is a valid argument to fesetround.
> (It isn't with x86 glibc, for example.)  You need to use whatever FE_*
> rounding mode macro the test in question cares about.

Sorry, I mis-read the man page and thought that list of numbers was ABI.  
At least some of the tests are using all the rounding modes, so unless 
you think it's worth splitting up both the tests and the DG check I'll 
just check for all of them?
  

On Thu, 28 Apr 2022, Palmer Dabbelt wrote:

> On Thu, 28 Apr 2022 15:12:39 PDT (-0700), joseph@codesourcery.com wrote:
> > On Thu, 28 Apr 2022, Palmer Dabbelt wrote:
> > 
> > > +proc check_effective_target_fenv_setround {} {
> > > +  return [check_runtime fenv_setround {
> > > +    #include <fenv.h>
> > > +    #include <stdlib.h>
> > > +    int
> > > +    main (void)
> > > +    {
> > > +      if (fesetround (1) == 0)
> > 
> > There is no reason to expect that 1 is a valid argument to fesetround.
> > (It isn't with x86 glibc, for example.)  You need to use whatever FE_*
> > rounding mode macro the test in question cares about.
> 
> Sorry, I mis-read the man page and thought that list of numbers was ABI.  At
> least some of the tests are using all the rounding modes, so unless you think
> it's worth splitting up both the tests and the DG check I'll just check for
> all of them?

I think checking for all four of the IEEE binary rounding modes is 
reasonable.  (If we add support for FE_TONEARESTFROMZERO in RISC-V glibc, 
that ought to be handled separately for any GCC tests involving that 
rounding mode, given that most architectures don't support it.)
  

On Thu, 28 Apr 2022 15:22:37 PDT (-0700), joseph@codesourcery.com wrote:
> On Thu, 28 Apr 2022, Palmer Dabbelt wrote:
>
>> On Thu, 28 Apr 2022 15:12:39 PDT (-0700), joseph@codesourcery.com wrote:
>> > On Thu, 28 Apr 2022, Palmer Dabbelt wrote:
>> >
>> > > +proc check_effective_target_fenv_setround {} {
>> > > +  return [check_runtime fenv_setround {
>> > > +    #include <fenv.h>
>> > > +    #include <stdlib.h>
>> > > +    int
>> > > +    main (void)
>> > > +    {
>> > > +      if (fesetround (1) == 0)
>> >
>> > There is no reason to expect that 1 is a valid argument to fesetround.
>> > (It isn't with x86 glibc, for example.)  You need to use whatever FE_*
>> > rounding mode macro the test in question cares about.
>>
>> Sorry, I mis-read the man page and thought that list of numbers was ABI.  At
>> least some of the tests are using all the rounding modes, so unless you think
>> it's worth splitting up both the tests and the DG check I'll just check for
>> all of them?
>
> I think checking for all four of the IEEE binary rounding modes is
> reasonable.  (If we add support for FE_TONEARESTFROMZERO in RISC-V glibc,
> that ought to be handled separately for any GCC tests involving that
> rounding mode, given that most architectures don't support it.)

Yep, I was just talking about the IEEE modes.  I'll send a v2.