Wed Aug 5 18:01:56 GMT 2020
I updated the patch discussed in
and pushed it as something like refs/users/glisse/heads/fenv (first user
branch in gcc's git, I hope it worked). I am also attaching the diff here.
I managed to compile and run real-world code with it, which is a good sign
As should be obvious looking at the diff, there is a lot of work left.
Experts may also find much better ways to rewrite several parts of the
The option is called -ffenv-access so it doesn't interfere with
-frounding-math, at least until we have something good enough to replace
-frounding-math without too much performance regression.
I switched to hex float constants for DBL_MAX and others for C99+, I don't
care about making fenv_access work in prehistoric modes. On the other
hand, since I haven't started on fenv_round, this is probably useless for
Several changes, in particular the constexpr stuff, was needed to parse
standard headers, otherwise I would have delayed the implementation.
Currently the floating point environment is represented by "memory" in
general. Refining it so the compiler knows that storing a float does not
change the rounding mode (for instance) should wait, in my opinion.
Conversions look like
.FENV_CONVERT (arg, (target_type*)0, 0)
the pointer is there so we know the target type, even if the lhs
disappears at some point. The last 0 is the same as for all the others, a
place to store options about the operation (do we care about rounding,
about exceptions, etc), it is just a placeholder for now. I could rename
it to .FENV_NOP since we seem to generate NOP usually, but it looked
strange to me.
I did not do anything for templates in C++. As long as we have a constant
global flag, it doesn't matter, but as soon as we will have a pragma,
things will get messy, we will need to remember what the mode was when
parsing, so we can use it at instantiation time... (or just declare that
the pragma doesn't work with templates in a first version)
I am trying to have enough infrastructure in place so that the
functionality is useful, and also so that implementing other pieces
(parsing the pragma, C front-end, gimple optimizations, target hook for
the asm string, opcode and target optimization, simd, etc) become
independent and can be done by different people. It is unlikely that I can
find the time to do everything. If other people want to contribute or even
take over (assuming the branch does not look hopelessly bad to them), that
would be great! That's also why I pushed it as a branch.
Apart from the obvious (making sure it bootstraps, running the testsuite,
adding a few tests), what missing pieces do you consider a strict
requirement for this to have a chance to reach master one day as an
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 19210 bytes
More information about the Gcc-patches