Hi!

On Fri, Sep 04, 2020 at 12:44:17PM -0300, Raoni Fassina Firmino wrote:
> > > +  switch (INTVAL (operands[1]))
> > > +    {
> > > +    case (1 << (31 - 6)): /* FE_INEXACT */
> > 
> > I would just write it as 0x020000000 etc.?  much clearer, and you have
> > the comment demagicificating it anyway!
> 
> At first I used the plain hex numbers, but I worried that it was easy to
> get it wrong (too many zeroes)

That's why you always use exactly 8 digits (which I got wrong, not
making a very strong case there, lol).

The "31 -" always is annoying noise, and (1 << 31) is *negative* (or
undefined if you want), so you need 1U (or 1ULL) really, making it even
less readable.

So pick your poison, there are no great solutions :-/

> and thought that copying verbatim from
> glibc was the way to go.

That would be nice, certainly.

> > > +OPTAB_D (fegetround_optab, "fegetround$a")
> > > +OPTAB_D (feclearexcept_optab, "feclearexcept$a")
> > > +OPTAB_D (feraiseexcept_optab, "feraiseexcept$a")
> > 
> > Should those be documented somewhere?  (In gcc/doc/ somewhere).
> 
> I am lost on that one. I took a look on the docs (I hope looking on the
> online docs was good enough)

If you looked at the internals documentation that has exactly all
content, yes.
  https://gcc.gnu.org/onlinedocs/gccint/
  https://gcc.gnu.org/onlinedocs/gccint.pdf
(but it sounds like you looked at the user manual instead?)

Many such things are documented in md.texi .

> > > --- /dev/null
> > > +++ 
> > > b/gcc/testsuite/gcc.target/powerpc/builtin-feclearexcept-feraiseexcept-1.c
> > > @@ -0,0 +1,64 @@
> > > +/* { dg-do run { target { powerpc*-*-* } } } */
> > 
> > All files in gcc.target/powerpc/ are run for powerpc already; just
> > /* { dg-do run } */
> > please.
> 
> Another case of me copying-around. Done.

There are so many bad (or dated) examples in existing tests :-(

> > > +/* { dg-options "-lm -fno-builtin" } */
> > 
> > Does that work everywhere?  AIX, Darwin, other non-Linux systems, systems
> > without OS, etc.
> 
> You mean because I am linking the tests with libm right, not the
> -fno-builtin?  I guess, in principle we don't need a libc to test the
> builtins, but I thought I would ended up reimplementing the builtins
> themselves and other fenv.h functions (with chances of getting them
> wrong), and that doing the test comparing against the standard library
> implementation would be more robust.  Should I change it?

I don't know, that's why I asked :-)  We'll just have to try it out.

Thanks,


Segher

Reply via email to