https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-09-05
Ever confirmed|0 |1
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrey Guskov from comment #5)
> This is the actual guilty line:
>
> sw_absorption.F90: chlamnt = 10**(logchl)
>
> It computes 'chlamnt' and then compares it to the list of acceptable values.
> When -Ofast is enabled, CPU2017::628 considers 'chlamnt' unacceptable.
It actually computes which interval it falls in:
chlamnt = 10**(logchl)
do m=1,nchl-1
if (chlcnc(m) .le. chlamnt .and. &
chlamnt .le. chlcnc(m+1) ) then
mc = m
goto 30
but the list of values is
real (r8), parameter, dimension(nchl) :: &!chl for table look-up
chlcnc = (/ &
.001_r8, .005_r8, .01_r8, .02_r8, &
.03_r8, .05_r8, .10_r8, .15_r8, &
so in case logchl is -3 and we get sth like 0.009999 it doesn't find anything.
Maybe we just need to make sure to compute log with round away from zero.
Or, instead of
+ /* pow(C,x) -> exp(log(C)*x) if C > 0. */
+ (for pows (POW)
+ exps (EXP)
+ logs (LOG)
+ (simplify
+ (pows REAL_CST@0 @1)
+ (if (real_compare (GT_EXPR, TREE_REAL_CST_PTR (@0), &dconst0)
+ && real_isfinite (TREE_REAL_CST_PTR (@0)))
+ (exps (mult (logs @0) @1)))))
compute the log and the multiplication with extra precision. On x86
this would mean using x87 math here, on other targets we might have to
give up for double. Or we need to restrict @0 to the case where log (@0)
is exactly representable.
I wonder if for the case of pow (10., x) using exp10 (x) would work
in practice for pop2. Note that simply using exp10 in a pattern like
above likely wouldn't work given fortran/mathbuiltins.def doesn't include
exp10 (it's a GNU extension so including it wouldn't be ok I guess).
Note cases like this are unfortunate but within -ffast-math / -Ofast they
are to be expected. Still our intention for -Ofast is that it doesn't
cause SPEC miscompares.
I suppose reporting this to SPEC folks and requesting a chlcnc table
change to .009999_r8 isn't going to fly ;)
