[RFC] Fix PR tree-optimization/34036

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

This is a regression present both on the mainline and 4.2 branch with the
combination of options -O2 -fnon-call-exceptions -ffast-math -fsignaling-nans.

Before the first tree reassociation pass, we have

<bb 3>:
  D.2140_6 = xMeasure_4(D) * yMeasure_5(D);

<bb 4>:
  D.2141_8 = D.2140_6 * zMeasure_7(D);

which gets turned by the pass into

$9 = (struct basic_block_def *) 0x2a95b28e40
(gdb) p debug_bb_n(3)
;; basic block 3, loop depth 0, count 0
;; prev block 2, next block 4
;; pred:       2 [100.0%]  (fallthru,exec)
;; succ:       7 (ab,eh,exec) 4 [100.0%]  (fallthru,exec)
<bb 3>:

(gdb) p debug_bb_n(4)
;; basic block 4, loop depth 0, count 0
;; prev block 3, next block 5
;; pred:       3 [100.0%]  (fallthru,exec)
;; succ:       7 (ab,eh,exec) 5 [100.0%]  (fallthru,exec)
<bb 4>:
D.2140_6 = xMeasure_4(D) * zMeasure_7(D);
D.2141_8 = D.2140_6 * yMeasure_5(D);

so the EH semantics is not preserved and a CFG verification failure is raised
because the first statement is "in the middle" of basic block 4.


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.

It seems to me that we should formalize the "doesn't make much sense":

  /* We cannot reassociate if we want traps or signed zeros.  */
  if (flag_trapping_math || flag_signed_zeros)
    flag_associative_math = 0;

but maybe we'd better not further play dominoes like that.  Thoughts?

-- 
Eric Botcazou