On Tue, 2021-09-21 at 12:41 +0100, Roger Sayle wrote: > > I was wondering if I may ask the C++ language experts for their > opinion > on whether (potential) floating point exceptions/traps can be ignored > in constant expressions; this is related to PR c++/96862. I think my > question boils down to whether (or not) the following is valid C++: > > constexpr float my_inf = 7.0 / 0.0;
It's not. C++ disallows constexpr from invoking undefined behaviors in Clauses 4 through 19, while division by zero is an undefined behavior in Clause 8. > [This is currently an error with "-O2", but OK with "-O2 -ffast- > math"!] > There's a long history of g++'s semantics being accidentally tied to > the middle-end's constant folding, such that the current status quo > is that some middle-end bugs can't be fixed without breaking C++, > and vice versa. I'm hoping that the patch below (following Jakub's > lead with rounding math) might be a next step to improving things, > provided that my understanding of the desired/correct behaviour of > the C++ front-end is correct. > > This patch has been tested on x86_64-pc-linux-gnu with a "make > bootstrap" > and "make -k check" with no new failures after tweaking two checks in > g++.dg/ubsan/pr63956.C. > With this change the middle-end can become more > strict about respecting flag_trapping_math without affecting C++'s > behavior. Ideally, what the front-end considers valid should be > independent of whether the user specified -fno-trapping-math (or > -ffast-math) to the middle-end. I think we can allow a constexpr to contain floating div-by-zero with - fno-trapping-math, if we consider -fno-trapping-math make the behavior "no longer undefined" but I'm not sure. However -ffast-math also enables -ffinite-math-only, which makes div-by- zero absolutely undefined. So to me the expected behavior is: g++ t.cc -> Compile error g++ t.cc -ffast-math -> Compile error g++ t.cc -fno-trapping-math -> Ok g++ t.cc -fno-trapping-math -ffinite-math-only -> Compile Error > Thoughts? Ok for mainline? Based on the reasoning above I think it's not OK. But anyway I'm not a maintainer. > 2021-09-21 Roger Sayle <ro...@nextmovesoftware.com> > > gcc/cp/ChangeLog > * constexpr.c (cxx_eval_outermost_const_expr): Temporarily > disable > the middle-end from honoring floating point exceptions/traps > while > folding "manifestly constant" expressions. > > gcc/testsuite/ChangeLog > * g++.dg/ubsan/pr63956.C: Update to (always) allow floating > point > division in constexpr (if both operands are constexpr). > > Roger > -- > -- Xi Ruoyao <xry...@mengyan1223.wang> School of Aerospace Science and Technology, Xidian University
