Andrew Pinski <quic_apin...@quicinc.com> writes: > The problem here is when f16 is enabled, movbf_aarch64 accepts `Ufc` > as a constraint: > [ w , Ufc ; fconsts , fp16 ] fmov\t%h0, %1 > But that is for fmov values and in this case fmov represents f16 rather than > bfloat16 values. > This means we would get the wrong value in the register. > > Built and tested for aarch64-linux-gnu with no regressions. Also tested with > `-march=armv9-a+sve2, > gcc.dg/torture/bfloat16-basic.c and gcc.dg/torture/bfloat16-builtin.c no > longer fail. > > gcc/ChangeLog: > > PR target/111867 > * config/aarch64/aarch64.cc (aarch64_float_const_representable_p): For > BFmode, > only accept +0.0. > > Signed-off-by: Andrew Pinski <quic_apin...@quicinc.com> > --- > gcc/config/aarch64/aarch64.cc | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc > index 5cffdabc62e..d48f5a1ba4b 100644 > --- a/gcc/config/aarch64/aarch64.cc > +++ b/gcc/config/aarch64/aarch64.cc > @@ -23904,6 +23904,7 @@ aarch64_float_const_representable_p (rtx x) > > r = *CONST_DOUBLE_REAL_VALUE (x); > > + > /* We cannot represent infinities, NaNs or +/-zero. We won't > know if we have +zero until we analyse the mantissa, but we > can reject the other invalid values. */
Seems like a stray change. OK without that, thanks. Richard > @@ -23911,6 +23912,10 @@ aarch64_float_const_representable_p (rtx x) > || REAL_VALUE_MINUS_ZERO (r)) > return false; > > + /* For BFmode, only handle 0.0. */ > + if (GET_MODE (x) == BFmode) > + return real_iszero (&r, false); > + > /* Extract exponent. */ > r = real_value_abs (&r); > exponent = REAL_EXP (&r);
