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

["amker at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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 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.

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.