--- 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|ASSIGNE
--- 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
--- 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 some
--- 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,
--- 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:
W
--- 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
> > tri
--- 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
--- 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 optimiza
--- 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
--- 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.333
--- 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
--- 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
> --
--- 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
--- 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
--- 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
--- 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_20
--- 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
--- 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
--- 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
--- 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
--
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
--- 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.re
--- 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:
--- 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
--- 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-da
--- 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
--- 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
--- 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
--- 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
--- 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
30 matches
Mail list logo
