User account creation filtered due to spam.
gfortran -g -flto gfortran.dg/gamma_5.f90 fails when calculating gamma.
Simplified version below. Without -flto it prints:
1 1.5000000 0.88622695
while with -flto it shows:
1 1.5000000 -0.12078223
integer :: n
real :: xs
n = 1
xs = n + 0.5
print *, n, xs, gamma(xs)
Dump (w/ putting "xs" on an extra line):
n = 1;
xs = (real(kind=4)) n + 5.0e-1;
xs = __builtin_tgammaf (xs);
This is because the Fortran frontend has different DECL_FUNCTION_CODE for the
same builtins as the middle-end, so they get mixed up (in this case LGAMMA
This needs to be fixed.
I also see
/* We define these separately as the fortran versions have different
semantics (they return an integer type) */
gfc_define_builtin ("__builtin_roundl", mfunc_longdouble,
BUILT_IN_ROUNDL, "roundl", true);
ugh. You can't overload existing builtin names with different semantics.
The middle-end expects that of gcc/builtins.def. For the above case
there exists BUILT_IN_LROUNDL.
(In reply to comment #2)
> /* We define these separately as the fortran versions have different
> semantics (they return an integer type) */
> gfc_define_builtin ("__builtin_roundl", mfunc_longdouble,
> ugh. You can't overload existing builtin names with different semantics.
> The middle-end expects that of gcc/builtins.def. For the above case
> there exists BUILT_IN_LROUNDL.
My impression is that the comment is old and does not apply to "roundl" as the trans-intrinsics.c uses both BUILT_IN_ROUND* and BUILT_IN_LROUND - and given that the "round*" were added much later than the comment according to svn blame.
Having said that, I think one should check the other intrinsics in that file (f95-lang.c) and remove then the bogus comment.
Subject: Bug 43040
Date: Tue Feb 16 08:35:05 2010
New Revision: 156796
2010-02-16 Tobias Burnus <email@example.com>
* gfortran.h (gfc_isym_id): Rename GFS_ISYM_GAMMA to
* intrinsic.c (add_functions): Ditto.
* iresolve.c (gfc_resolve_gamma): Call tgamma instead of gamma.
* mathbuiltins.def: Use TGAMMA instead of GAMMA with "tgamma".
I think the comment applies only to FLOOR and ROUND - at least when it was first written those were the only ones present. If I read the source code correctly, the ME floor(l,f) is not directly called but instead the following is generated:
FLOOR(x) = INT(x) <= x ? INT(x) : INT(x) - 1
cf. trans-intrinsic.c. I also believe that ROUND [(l)round(l,f)] is properly handled, which means that the PR could be closed. However, I leave it open for someone else to cross check.
I'm currently looking at math builtins for __float128 support, so I'll check that.
Subject: Bug 43040
Date: Wed Jun 9 10:17:56 2010
New Revision: 160459
* f95-lang.c (gfc_init_builtin_functions): Remove comment.
Checked that it is not an issue.