This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Fix PR tree-optimization/34036


On Nov 18, 2007 2:33 PM, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:
> > The problem stems from the combination of options, in particular the FP
> > part -ffast-math -fsignaling-nans.  With these, flag_associative_math is
> > true so the pass doesn't stop immediately; but we have in process_options
> >
> >   /* The presence of IEEE signaling NaNs, implies all math can trap.  */
> >   if (flag_signaling_nans)
> >     flag_trapping_math = 1;
> >
> > so every FP operation is deemed potentially trapping.   Now, according to
> > the documentation for the option, -fassociative-math "doesn't make much
> > sense without -fno-signed-zeros or -fno-trapping-math" so we have a
> > conflict here.
>
> Hum... -funsafe-math-optimizations turns on -fassociative-math but not
> -fno-trapping-math and this "doesn't make much sense" according to our docs.

Because for example re-association may introduce or remove traps on +Inf
for example.

> As a result,
>
> >   /* We cannot reassociate if we want traps or signed zeros.  */
> >   if (flag_trapping_math || flag_signed_zeros)
> >     flag_associative_math = 0;
>
> will partially disable -funsafe-math-optimizations.
>
> Should -funsafe-math-optimizations turn on -fno-trapping-math and
> -fno-signed-zeros too?

I guess so.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]