https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #37 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Richard Biener from comment #36) > Created attachment 46396 [details] > poor mans solution^Whack > > So this is what a hack looks like, basically sprinkling those asm()s > throughout the code automatically. > > Note I need to protect inputs, not outputs, otherwise the last > testcase isn't fixed. Actually, you need to protect both inputs *and* outputs... > Improving this poor-mans solution by writing in some flow-sensitivity > like tracking which values are already protected At least if you use "=x" (or whatever the right constraint is on each target) it doesn't really hurt to have a dozen protections on the same variable. > and if there's a possibly > harmful FENV access in between maybe in a similar way tree-complex.c tracks > complex components might work. > > Note that the FENV pragma does _not_ enable -frounding-math (it really has > no effect!) so you need to supply -frounding-math yourself (or fix the > frontends to do that). If you protect even constants, the current effects of -frounding-math become redundant.