https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (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.
