[Bug tree-optimization/79460] gcc fails to optimise out a trivial additive loop for seemingly arbitrary numbers of iterations

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@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.