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 allows some contractions disallowed by the > > standard. > > Not fully, see below. > > > But GCC is in C++ and I'm not sure if the C++ standard has the same > > definition for allowed contractions as C. > > It doesn't, but in GCC we should aim to provide the same semantics in C++ > as in C. > > > > (Or is the severity of lack of support sufficiently different in the two > > > cases that this is fine -- i.e. not compile vs may trigger floating > > > point rounding inaccuracies?) > > > > It's possible that the test itself is flaky. Can you provide some > > detail about how it fails? > > 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? > Now that multiple platforms are hitting this, can we _please_ get rid > of the questionable attempt to compute time in a floating-point variable > and just use an uint64_t storing nanoseconds? To me this is the correct thing to do. -- Xi Ruoyao <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University
