------- Comment #24 from dominiq at lps dot ens dot fr 2010-05-06 15:34 ------- > > Now the questions are: > > (1) why a change dealing with the propagation of minus signs interferes with > > reciprocal-math? > > (2) why moving VEC_safe_push from negate_value to eliminate_plus_minus_pair > > trigger the miscompilation? > > Just to be clear, I do not think there is a miscompilation here.
Just to be clear, (1) I have understood your point from the very beginning, (2) I disagree with it: if you get the right result with '-O3 -ffast-math' on *-linux-* and I get a segmentation fault on x86_64-apple-darwin10, it means that doduc.f90 is miscompiled for the latter. Note that I have gotten the correct result for doduc.f90 with '-O3 -ffast-math' several hundred times over the past years. > The patch that [among other things] moved VEC_safe_push from > negate_value to eliminate_plus_minus_pair did that to enable "(a + (-b)) > -> (a - b)" optimization in more cases. Unless I missed something, the only significant change in revision 158105 is the move of VEC_safe_push. The other ones are renaming "broken_up_subtracts" to "plus_negates" and moving static VEC(tree, heap) *plus_negates; where it is needed due to the move of VEC_safe_push. Unless there is something very weird, I cannot see how these two changes can affect the generated code. Note also that if the only effect of moving VEC_safe_push was to enable "(a + (-b))-> (a - b)" optimization, it should not interfere with the optimization "a/b -> a*(1.0/b))". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
