[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-06-05 10:36 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #28 from dominiq at lps dot ens dot fr 2010-06-05 09:54 --- Is there any interest to understand what broke the test and what fixed it? If not, I'll close this pr as fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #27 from dominiq at lps dot ens dot fr 2010-05-09 14:19 --- > VEC_safe_push is quite safe, actually. But it may re-allocate the VEC. If you > really believe that VEC_safe_push is the problem here, then you should perhaps > look if a VEC is being passed around incorrectly somewhere, so that > reallocating it would make things disappear. Could you give me more precise idea about what I am supposed to do to "look if a VEC is being passed around incorrectly somewhere"? BTW I would think the problem is not before some "reallocation", but after it, see: ... . The latter will reallocate the vector, if needed. Reallocation causes an exponential increase in vector size. I have found a long comment at the beginning of gcc/vec.h, is VEC_safe_push documented elsewhere? I have done the following changes in the subroutine s9.f90: (1) --- s9.f90 2010-04-18 22:04:36.0 +0200 +++ s9_yy.f90 2010-05-09 15:19:43.0 +0200 @@ -45,6 +45,7 @@ &NDPdt , NDBsor , NHSor DOUBLE PRECISION M , cc(22,2) coef = 144.D+00/778.D+00 + zzz = 1.0/VVFs DO i = 2 , NC1 j = i - 1 ity = ITYp(i) and I get the same assembly compared with the original one (for both revision 159105 and 159106). (2) --- s9.f90 2010-04-18 22:04:36.0 +0200 +++ s9_xx.f90 2010-05-09 15:22:25.0 +0200 @@ -45,6 +45,7 @@ &NDPdt , NDBsor , NHSor DOUBLE PRECISION M , cc(22,2) coef = 144.D+00/778.D+00 + zzz = 1.0/VVFs DO i = 2 , NC1 j = i - 1 ity = ITYp(i) @@ -76,7 +77,7 @@ AA(i,k) = VV(i,k)*DM(i,k) + DVVh(i,k)*cc(i,k) DV(i,k) = AA(i,k) + BB(i,k)*DPDt IF ( DABS(DV(i,k)).LT.1.D-10 ) DV(i,k) = 0.D+00 - epsm = DELm*VC(i)/VVFs + epsm = DELm*VC(i)*zzz ym = M(i,k) IF ( ym.LT.epsm ) ym = epsm DH(i,k) = (cc(i,k)+coef*V(i,k)*DPDt)/ym i.e., I have replaced the division with the multiplication by the inverse (if I am not mistaken, this optimization is done with revision 159105 but not with 159106). The assembly is very different and the executable does not crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #26 from steven at gcc dot gnu dot org 2010-05-08 10:38 --- VEC_safe_push is quite safe, actually. But it may re-allocate the VEC. If you really believe that VEC_safe_push is the problem here, then you should perhaps look if a VEC is being passed around incorrectly somewhere, so that reallocating it would make things disappear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #25 from dominiq at lps dot ens dot fr 2010-05-08 10:31 --- This PR is "fixed" by revision 159106. Apparently there is a rampant bug (at least on Darwin) with the use of "VEC_safe_push". How safe is "VEC_safe_push"? -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||richard dot guenther at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- 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
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #23 from mkuvyrkov at gcc dot gnu dot org 2010-05-06 15:07 --- Subject: Re: [4.6 Regression] Revision 158105 miscompiles doduc.f90 On 5/6/10 6:59 PM, dominiq at lps dot ens dot fr wrote: ... > 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. 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- 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.0 +0200 +++ doduc_nr.f902010-05-06 15:38:37.0 +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
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #21 from mkuvyrkov at gcc dot gnu dot org 2010-05-05 20:28 --- Dominique, Have you been able to identify if there is an invalid optimization? It seems using -ffast-math -ffinite-math-only is very error-prone. -ffast-math implies -fassociative-math, which can generate NaNs, and -ffinite-math-only can further worsen the precision by additional optimizations. It may not be obvious to a casual GCC user that -ffinite-math-only gives more freedom to the optimization passes, not restricts the compiler to keep all math finite. FYI, -fassociative-math Allow re-association of operands in series of floating-point operations. This violates the ISO C and C++ language standard by possibly changing computa- tion result. NOTE: re-ordering may change the sign of zero as well as ignore NaNs and inhibit or create underflow or overflow (and thus cannot be used on a code which relies on rounding behavior like (x + 2**52) - 2**52). May also reorder floating-point comparisons and thus may not be used when ordered comparisons are required. This option requires that both -fno-signed-zeros and -fno-trapping-math be in effect. Moreover, it doesnt make much sense with -frounding-math. For Fortran the option is automatically enabled when both -fno-signed-zeros and -fno-trapping-math are in effect. The default is -fno-associative-math. ... -ffinite-math-only Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs. This option is not turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications. The default is -fno-finite-math-only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #20 from dominiq at lps dot ens dot fr 2010-04-14 13:06 --- I have been able to get the following values before the crash: DEBav = 0.59252398402327489 1.58848116996742547E-002 2.31157896165751706E-002 8.33002598145726886E-002 9.03564427292446321E-002 -596152.33325048804 -173.27129371256277284192.62549692224 -226.34926169938268 -2145.27852830281346880.238594878283025825.135912393274 26997.892028831531NaN 0. 0.0.0. 0.0.0. XA = 0.1.1. 1.1.1. 1. 0.999891. 1.1. 0.49470835610659347 NaN NaN 0. 0.0.0. 0.0.0. XB = 0.0. 4.95714580495132420E-018 0.0.0. 0.0.0. 0.0. 7.34677397984116187E-002 NaN NaN 0. 0.0.0. 0.0.0. ie = I - 1 debe = DEBav(ie) debs = DEBav(I) deve = XA(ie)*debe + XB(ie) devs = XA(I)*debs + XB(I) sec = SCApa(I) debm = (deve+devs)/2.D+00 eps = 1.D+00 IF ( debm.LT.0. ) eps = -1.D+00 vis = (r+s*tf)/3600.D+00 Re = eps*debm*DIAhy/(vis*sec) So if I= 13, 14, or 15, Re is a NaN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #19 from dominiq at lps dot ens dot fr 2010-04-14 10:25 --- > Can you track where the NaN comes from and if it is indeed unexpected > even with -ffast-math -ffinite-math-only? First '-ffast-math' implies '-funsafe-math-optimizations -ffinite-math-only'. To reach > This is because Re is a NaN because debm is a NaN. I tried to print deve and > devs, but this make the code to work. I have added an IF in S00061 that print some results if i1 is less than 1 or greater than 20 (i.e., a poor man's bound check). With that I see that Re is a NaN when the code crashes an nothing when the code works (e.g., after reverting revision 158105). The bad news is that the code "works" if I try to print the variables deve or devs (Re=(deve+devs)/2.0) and I did not find a way to overcome it. From my experience, a change of behavior when printing something is a good clue that there is some memory mismanagement (usually due to using arrays outside their bounds). Note also that S00061 is compiled the same way before of after r158105 (I have even checked it before opening this pr). I have no knowledge at all of doduc (see http://www.spec.org/cpu92/DESCR.015 ). The first time I heard anything about it (~20 years ago) was because it was considered at that time as a "compiler breaker". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #18 from mkuvyrkov at gcc dot gnu dot org 2010-04-14 10:02 --- Subject: Re: [4.6 Regression] Revision 158105 miscompiles doduc.f90 On 4/14/10 1:55 PM, dominiq at lps dot ens dot fr wrote: > --- Comment #17 from dominiq at lps dot ens dot fr 2010-04-14 09:55 > --- >> Well, it indeed looks invalid if there is NaNs involved and you use >> -ffinite-math-only. > > The NaN appears in the miscompiled executable. Note that I am not the author > of > the doduc test, but it has been compiled by gfortran with -O3 -ffast-math for > years and ran without failure. Can you track where the NaN comes from and if it is indeed unexpected even with -ffast-math -ffinite-math-only? >> While I will not argue that my patch is 100% bug-free, this seems to be an >> invalid testcase. > > It may happen that the changes in revision 158105 is exposing a latent bug. That is always a possibility. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #17 from dominiq at lps dot ens dot fr 2010-04-14 09:55 --- > Well, it indeed looks invalid if there is NaNs involved and you use > -ffinite-math-only. The NaN appears in the miscompiled executable. Note that I am not the author of the doduc test, but it has been compiled by gfortran with -O3 -ffast-math for years and ran without failure. > While I will not argue that my patch is 100% bug-free, this seems to be an > invalid testcase. It may happen that the changes in revision 158105 is exposing a latent bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-04-14 09:44 --- Well, it indeed looks invalid if there is NaNs involved and you use -ffinite-math-only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-13 20:45 --- (In reply to comment #13) > Here we have index `i1' calculated from fp values and then casted to int. > Segmentation fault occurs in `y1 = y(i1)' with i1 equal to > 0x800c. > This is in function S00061 in doduc_red.f90, not in s33022.f90. This is because Re is a NaN because debm is a NaN. I tried to print deve and devs, but this make the code to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #14 from mkuvyrkov at gcc dot gnu dot org 2010-04-13 20:01 --- (In reply to comment #10) > - D.1850_209 = -alt_90; > - D.2093_151 = -alb_86; > - D.1849_208 = D.1848_207 - alb_86; > + D.2093_151 = -alt_90; > + D.1849_208 = D.1848_207 - alt_90; >D.1851_210 = D.1849_208 + -1.0e+0; > - z1a_211 = D.1851_210 + D.1850_209; > + D.2094_497 = -alb_86; > + z1a_211 = D.1851_210 - alb_86; > > this doesn't look like an identity transform. You have to be careful with > non-single use vars and make sure they do not end up on a reassociation > chain. Though it does look fishy, this transformation is OK. In fact, the compiler oscillates a couple of times between using `-alb_86' and `-alt_90'. E.g., the "before" compiler does the following transformation during reassoc1: == - D.1849_208 = D.1848_207 - alb_86; + D.2045_228 = -alb_86; + D.1850_209 = -alt_90; + D.1849_208 = D.1848_207 + D.1850_209; == -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #13 from mkuvyrkov at gcc dot gnu dot org 2010-04-13 19:32 --- The SIGSEGV is due to -funsafe-math-optimizations being used with code like: == Re = eps*debm*DIAhy/(vis*sec) reo = Re IF ( Re.LT.1000. ) THEN i1 = INT(Re/200.) + 1 ELSEIF ( Re.LT.4000. ) THEN i1 = INT(Re/500.) + 4 ELSEIF ( Re.LT.1. ) THEN i1 = INT(Re/2000.) + 10 ELSEIF ( Re.GE.3. ) THEN IF ( Re.GE.4. ) Re = 4.D+00 i1 = INT(Re/1.) + 16 ELSE i1 = INT(Re/5000.) + 13 ENDIF i2 = i1 + 1 y1 = y(i1) y2 = y(i2) == Here we have index `i1' calculated from fp values and then casted to int. Segmentation fault occurs in `y1 = y(i1)' with i1 equal to 0x800c. This is in function S00061 in doduc_red.f90, not in s33022.f90. Also, to trigger the SIGSEGV it is necessary to compile both doduc_red.f90 and s33022.f90 with "-O3 -funsafe-math-optimizations -ffinite-math-only". If either of the modules is compiled with -O2 the SIGSEGV does not occur. While I will not argue that my patch is 100% bug-free, this seems to be an invalid testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-13 14:09 --- A few additional notes: (1) with revision 158105 reverted, the test gcc.dg/tree-ssa/reassoc-19.c fails with -m32, but passes with -m64. (2) revision 158265 with/without revision 158105 reverted (after some surgery to replace plus_negates with broken_up_subtracts) also miscompiles doduc.f90. (3) Following comment #10, is it possible to rule out a critical loss of precision due to the reassociation? (4) From Jerry Delisle, the diff before and after r158105 on fedora is $ diff s33022.s.before s33022.s.after 315c315 < subsd 296(%rsp), %xmm14 --- > subsd 288(%rsp), %xmm14 321c321 < subsd 288(%rsp), %xmm14 --- > subsd 296(%rsp), %xmm14 458c458 < xorpd .LC12(%rip), %xmm12 --- > mulsd 384(%rsp), %xmm15 461,462d460 < mulsd 384(%rsp), %xmm15 < subsd 368(%rsp), %xmm12 467d464 < mulsd 232(%rsp), %xmm12 499,501c496,498 < movsd 296(%rsp), %xmm3 < subsd 272(%rsp), %xmm3 < subsd %xmm12, %xmm15 --- > movsd 368(%rsp), %xmm3 > xorpd .LC12(%rip), %xmm3 > subsd %xmm12, %xmm3 504c501 < mulsd %xmm8, %xmm3 --- > mulsd 232(%rsp), %xmm3 505a503,506 > subsd %xmm3, %xmm15 > movsd 296(%rsp), %xmm3 > subsd 272(%rsp), %xmm3 > mulsd %xmm8, %xmm3 -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2010-04-12 16:38 --- Confirmed with mac os x gcc build. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-12 16:38:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-04-12 11:21 --- - D.1850_209 = -alt_90; - D.2093_151 = -alb_86; - D.1849_208 = D.1848_207 - alb_86; + D.2093_151 = -alt_90; + D.1849_208 = D.1848_207 - alt_90; D.1851_210 = D.1849_208 + -1.0e+0; - z1a_211 = D.1851_210 + D.1850_209; + D.2094_497 = -alb_86; + z1a_211 = D.1851_210 - alb_86; this doesn't look like an identity transform. You have to be careful with non-single use vars and make sure they do not end up on a reassociation chain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #9 from dominiq at lps dot ens dot fr 2010-04-10 19:32 --- Created an attachment (id=20359) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20359&action=view) bzipped tar file with the outputs of -fdump-tree-reassoc reassoc.tar.bz2 contains the files s33022_*.f90.082t.reassoc1 and s33022_*.f90.121t.reassoc2, with *==w for the working compiler and *==n for the non-working one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2010-04-10 19:20 --- Hm, I'm having hard time reproducing this on linux. Would you please attach dumps produced with -fdump-tree-reassoc for both before and after compilers. Thanks. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC|maxim at trivialbugs dot com|mkuvyrkov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #7 from dominiq at lps dot ens dot fr 2010-04-10 18:49 --- The problem seems to occur within these lines: tt = -t*rmp/rm z1at = -Dalb - Dalt z2at = drg*(alt-2.*al) + drf*(alb-2.*al) + rg*Dalt + & &rf*Dalb sdt = z2at*vgj + z2a*vgjt + z2t*vgja + z2*vgjat - g*z1at -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #6 from dominiq at lps dot ens dot fr 2010-04-10 18:41 --- Created an attachment (id=20358) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20358&action=view) doduc.in Using built-in specs. COLLECT_GCC=gfcp COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper Target: x86_64-apple-darwin10 Configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.6p --mandir=/opt/gcc/gcc4.6p/share/man --infodir=/opt/gcc/gcc4.6p/share/info --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 --enable-languages=c,fortran --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cloog=/opt/sw64 --with-ppl=/opt/sw64 --with-mpc=/opt/sw64 Thread model: posix gcc version 4.6.0 20100408 (experimental) [trunk revision 158105] (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.3' '-v' '-c' '-mtune=generic' /opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/4.6.0/f951 doduc_red.f90 -fPIC -quiet -dumpbase doduc_red.f90 -mmacosx-version-min=10.6.3 -mtune=generic -auxbase doduc_red -version -fintrinsic-modules-path /opt/gcc/gcc4.6p/lib/gcc/x86_64-apple-darwin10/4.6.0/finclude -o /var/folders/LW/LW1oufkMGIqlLpjYn45fBU+++TI/-Tmp-//ccrL4xwD.s GNU Fortran (GCC) version 4.6.0 20100408 (experimental) [trunk revision 158105] (x86_64-apple-darwin10) compiled by GNU C version 4.6.0 20100408 (experimental) [trunk revision 158104], GMP version 5.0.1, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20100408 (experimental) [trunk revision 158105] (x86_64-apple-darwin10) compiled by GNU C version 4.6.0 20100408 (experimental) [trunk revision 158104], GMP version 5.0.1, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.3' '-v' '-c' '-mtune=generic' as -arch x86_64 -force_cpusubtype_ALL -o doduc_red.o /var/folders/LW/LW1oufkMGIqlLpjYn45fBU+++TI/-Tmp-//ccrL4xwD.s COMPILER_PATH=/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/4.6.0/:/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/4.6.0/:/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/:/opt/gcc/gcc4.6p/lib/gcc/x86_64-apple-darwin10/4.6.0/:/opt/gcc/gcc4.6p/lib/gcc/x86_64-apple-darwin10/ LIBRARY_PATH=/opt/gcc/gcc4.6p/lib/gcc/x86_64-apple-darwin10/4.6.0/:/opt/gcc/gcc4.6p/lib/gcc/x86_64-apple-darwin10/4.6.0/../../../:/usr/lib/ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.3' '-v' '-c' '-mtune=generic' COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.3' '-v' '-c' '-mtune=generic' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-04-10 18:28 --- Would you please attach doduc.in so that I can reproduce this. == At line 161 of file /home/maxim/tmp/doduc_red.f90 (unit = 5, file = 'doduc.in') Fortran runtime error: End of file == Also, what is your configure line and with which exact parameters f951 gets invoked? (The compiler prints out the later if you add `-v' option to the command line). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-10 16:42 --- Created an attachment (id=20357) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20357&action=view) Miscompiled assembly for subroutine S3302 The diff between the working (-) and miscompiled (+) assembly files is --- s33022_w.s 2010-04-10 13:04:09.0 +0200 +++ s33022_n.s 2010-04-10 13:04:31.0 +0200 @@ -311,13 +311,13 @@ L28: movsd -144(%rbp), %xmm3 mulsd %xmm9, %xmm1 mulsd %xmm4, %xmm3 - subsd -144(%rbp), %xmm14 + subsd -136(%rbp), %xmm14 movsd -136(%rbp), %xmm9 divsd %xmm10, %xmm1 subsd %xmm2, %xmm9 addsd LC18(%rip), %xmm14 movsd %xmm9, -104(%rbp) - subsd -136(%rbp), %xmm14 + subsd -144(%rbp), %xmm14 movsd (%r8), %xmm10 movsd %xmm10, -216(%rbp) mulsd %xmm7, %xmm10 @@ -454,16 +454,13 @@ L28: movsd -88(%rbp), %xmm6 mulsd %xmm4, %xmm3 mulsd %xmm2, %xmm6 - xorpd LC12(%rip), %xmm12 + mulsd -232(%rbp), %xmm15 addsd -200(%rbp), %xmm14 mulsd %xmm9, %xmm3 - mulsd -232(%rbp), %xmm15 - subsd -216(%rbp), %xmm12 movsd %xmm3, -456(%rbp) movapd %xmm13, %xmm3 mulsd %xmm1, %xmm14 addsd %xmm13, %xmm3 - mulsd -80(%rbp), %xmm12 addsd %xmm6, %xmm3 movsd -120(%rbp), %xmm6 addsd %xmm6, %xmm6 @@ -495,13 +492,17 @@ L28: mulsd -112(%rbp), %xmm14 mulsd %xmm0, %xmm3 addsd %xmm3, %xmm15 - movsd -144(%rbp), %xmm3 - subsd -120(%rbp), %xmm3 - subsd %xmm12, %xmm15 + movsd -216(%rbp), %xmm3 + xorpd LC12(%rip), %xmm3 + subsd %xmm12, %xmm3 movsd -136(%rbp), %xmm12 subsd -120(%rbp), %xmm12 - mulsd %xmm8, %xmm3 + mulsd -80(%rbp), %xmm3 mulsd -96(%rbp), %xmm12 + subsd %xmm3, %xmm15 + movsd -144(%rbp), %xmm3 + subsd -120(%rbp), %xmm3 + mulsd %xmm8, %xmm3 addsd %xmm12, %xmm3 movapd %xmm4, %xmm12 mulsd %xmm0, %xmm12 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-10 16:39 --- Created an attachment (id=20356) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20356&action=view) Working assembly for subroutine S33022 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-10 16:38 --- Created an attachment (id=20355) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20355&action=view) Fortran source for doduc.f90 with subroutine S33022 commented -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-10 16:36 --- Created an attachment (id=20354) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20354&action=view) Fortran source for subroutine S33022 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
