Re: Reset HWCAP2_AFP bits in FPCR for default fenv.

[Szabolcs Nagy <Szabolcs.Nagy@arm.com>]

The 06/29/2022 11:54, Florian Weimer wrote:
> * Tejas Belagod via Libc-alpha:
> 
> > The AFP feature (Alternate floating-point behavior) was added in
> > Armv8.7-A and introduced new FPCR bits.
> >
> > Currently, HWCAP2_AFP bits (bit 0, 1, 2) in FPCR are preserved when
> > fenv is set to default environment.  This is a deviation from standard
> > behavior.  Clear these bits when setting the fenv to default.
> >
> > There is no libc API to modify the new FPCR bits.  Restoring those
> > bits matters if the user changed them directly.
> >
> > OK for master?
> 
> What do you propose as commit message?
> 
> I think we have that definition of _FPU_RESERVED because the we cannot
> know the semantics of those bits (obviosuly), and changing them
> underneath the user's code could be wrong.
> 
> What do these bits do, actually?  If this adds additional FPU state, how
> does it interact with compiler behavior and optimizations?  Can it even
> be safely changed after process startup?

i think you will have to check the details in the arm arm
https://developer.arm.com/documentation/ddi0487/latest

in short, the new bits

FPCR.NEP: changes output of scalar fp instructions in top vector lanes.
FPCR.AH: changes flush to zero exception, underflow and nan propagation.
FPCR.FIZ: subnormal inputs are flushed to zero (instead of outputs).

(note that the alternate fp behaviour is carefully designed so
it's easy to emulate fp instructions of other architectures, i.e.
the bits are likely not used to change math library behaviour but
to execute a foreign binary on aarch64.)

technically these should be 0 in c code (then save/restore is noop).
it seems the existing reserved bits are not consistent:

- DN is reserved (when set, default nan is returned instead of
  propagating nan payload)

- FZ is not reserved (subnormal flush to zero)

These are non-conforming settings so fenv apis could ignore both
or save/restore both.

i don't have a strong opinion, but i thought it made sense to
restore all these special bits with fesetenv(FE_DFL_ENV).
(e.g. in an async signal handler one could do

  fegetenv(&e);
  fesetenv(FE_DFL_ENV);
  // fp operations
  fesetenv(&e);

to get sane fenv. this is ub in iso c, but not unreasonable.)