Re: [PATCH] Reduce floating-point difficulties in timevar.cc

2023-07-21 Thread Andrew Pinski via Gcc-patches
On Fri, Jul 21, 2023 at 5:13 AM Matthew Malcomson via Gcc-patches wrote: > > On some AArch64 bootstrapped builds, we were getting a flaky test > because the floating point operations in `get_time` were being fused > with the floating point operations in `timevar_accumulate`. > > This meant that th

Re: [PATCH] Reduce floating-point difficulties in timevar.cc

2023-07-21 Thread Alexander Monakov
On Fri, 21 Jul 2023, Xi Ruoyao wrote: > > See also PR 99903 for an earlier known issue which appears due to x87 > > excess precision and so tweaking -ffp-contract wouldn't help: > > > >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99903 > > Does it affect AArch64 too? Well, not literally (A

Re: [PATCH] Reduce floating-point difficulties in timevar.cc

2023-07-21 Thread Matthew Malcomson via Gcc-patches
On 7/21/23 14:45, Xi Ruoyao wrote: On Fri, 2023-07-21 at 14:11 +0100, Matthew Malcomson wrote: My understanding is that this is not a hardware bug and that it's specified that rounding does not happen on the multiply "sub-part" in `FNMSUB`, but rounding happens on the `FMUL` that generates some

Re: [PATCH] Reduce floating-point difficulties in timevar.cc

2023-07-21 Thread Xi Ruoyao via Gcc-patches
On Fri, 2023-07-21 at 16:58 +0300, Alexander Monakov wrote: > > On Fri, 21 Jul 2023, Xi Ruoyao via Gcc-patches wrote: > > > Perhaps -ffp-contract=on (not off) is enough to fix the issue (if you > > are building GCC 14 snapshot).  The default is "fast" (if no -std= > > option is used), which allow

Re: [PATCH] Reduce floating-point difficulties in timevar.cc

2023-07-21 Thread Alexander Monakov
On Fri, 21 Jul 2023, Xi Ruoyao via Gcc-patches wrote: > Perhaps -ffp-contract=on (not off) is enough to fix the issue (if you > are building GCC 14 snapshot). The default is "fast" (if no -std= > option is used), which allows some contractions disallowed by the > standard. Not fully, see below

Re: [PATCH] Reduce floating-point difficulties in timevar.cc

2023-07-21 Thread Xi Ruoyao via Gcc-patches
On Fri, 2023-07-21 at 14:11 +0100, Matthew Malcomson wrote: > My understanding is that this is not a hardware bug and that it's > specified that rounding does not happen on the multiply "sub-part" in > `FNMSUB`, but rounding happens on the `FMUL` that generates some input > to it. AFAIK the C st

Re: [PATCH] Reduce floating-point difficulties in timevar.cc

2023-07-21 Thread Richard Biener via Gcc-patches
> Am 21.07.2023 um 15:12 schrieb Matthew Malcomson : > > Responding to two emails at the same time ;-) > >> On 7/21/23 13:47, Richard Biener wrote: >>> On Fri, 21 Jul 2023, Matthew Malcomson wrote: >>> On some AArch64 bootstrapped builds, we were getting a flaky test >>> because the floating

Re: [PATCH] Reduce floating-point difficulties in timevar.cc

2023-07-21 Thread Matthew Malcomson via Gcc-patches
Responding to two emails at the same time ;-) On 7/21/23 13:47, Richard Biener wrote: On Fri, 21 Jul 2023, Matthew Malcomson wrote: On some AArch64 bootstrapped builds, we were getting a flaky test because the floating point operations in `get_time` were being fused with the floating point ope

Re: [PATCH] Reduce floating-point difficulties in timevar.cc

2023-07-21 Thread Xi Ruoyao via Gcc-patches
On Fri, 2023-07-21 at 13:11 +0100, Matthew Malcomson via Gcc-patches wrote: > This change ensures those operations are not fused and hence stops the test > being flaky on that particular machine.  There is no expected change in the > generated code. > Bootstrap & regtest on AArch64 passes with no r

Re: [PATCH] Reduce floating-point difficulties in timevar.cc

2023-07-21 Thread Richard Biener via Gcc-patches
On Fri, 21 Jul 2023, Matthew Malcomson wrote: > On some AArch64 bootstrapped builds, we were getting a flaky test > because the floating point operations in `get_time` were being fused > with the floating point operations in `timevar_accumulate`. > > This meant that the rounding behaviour of our