https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460
--- Comment #10 from amker at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #9) > (In reply to rguent...@suse.de from comment #8) > > On Tue, 14 Feb 2017, jakub at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460 > > > > > > --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > > > Shouldn't it (both in the vectorizer and in scev) be dependent not just on > > > flag_fp_contract_mode but also on some -ffast-math subflag? Doing several > > > additions can e.g. raise different exceptions and have different > > > roundings from > > > doing it as just one multiply. > > > > Maybe, but I don't see which (apart from flag_unsafe_math_optimizations > > of course but we'd want to get rid of that...). reassoc uses > > flag_unsafe_math_optimizations (and does this for SCALAR_FLOAT_TYPE_P > > only). The docs only mention FMA for fp-contract... > > fp-contract is I believe only about whether you are allowed to transform x = > a + b * c; into a FMA or not (or similar expressions), so I think isn't even > related to this. Even if we want to get rid of > flag_unsafe_math_optimizations eventually, it is better to use that if we > don't know what exactly rather than emit wrong-code with -fno-fast-math, > we'll have to eventually add some new flags or figure it out. I also think we need flag_unsafe_math_optimizations or similar on this, this is risky transformation and we may put iterative numerical algorithms in danger.
