------- Comment #22 from dominiq at lps dot ens dot fr 2010-05-06 14:59 -------
> Have you been able to identify if there is an invalid optimization?
I have started to follow the spaghetti plate without success so far. However,
although I don't think the problem comes from any "invalid optimization", I
realized that '-funsafe-math-optimizations' (implied by -ffast-math) implies
'-freciprocal-math'. Thus with a vanilla trunk at revision 159085 (gfcp), I
tried:
gfcp -O3 -ffast-math -fno-reciprocal-math ../doduc.f90
which worked. Then I did the following change:
--- doduc.f90 2005-10-11 14:53:32.000000000 +0200
+++ doduc_nr.f90 2010-05-06 15:38:37.000000000 +0200
@@ -2378,13 +2378,13 @@
dvg = DNUg(I)
drf = -dvf*rf*rf
drg = -dvg*rg*rg
- rp = r*(dvf/vf-dvg/vg)
+ rp = r*(dvf*rf-dvg/vg)
alo = .925*(vf/vg)**.239
a = .67
IF ( al.GE.alo ) a = .47
vgj = VGJo(I)
alop = alo*rp*.239/r
- vbcrp = .25*vbcr*(dvf/vf-rp/(1.-r))
+ vbcrp = .25*vbcr*(dvf*rf-rp/(1.-r))
alb = ALFb(I)
alt = ALFt(I)
tao = alop/(a*alo)
(since rf = 1./vf) and it worked too (note that it did not with only one change
in rp or vbcrp).
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?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
