On Sun, 21 Nov 2021 19:59:35 +0100
Harald Anlauf wrote:
> Let's have a look at the tree-dump of the existing testcase:
>
> integer(kind=4) runtime_poppar (integer(kind=16) & restrict i)
> {
>integer(kind=4) res;
>
>{
> uint128_t D.4221;
>
> D.4221 = (uint128_t) *i;
> res
Let's have a look at the tree-dump of the existing testcase:
integer(kind=4) runtime_poppar (integer(kind=16) & restrict i)
{
integer(kind=4) res;
{
uint128_t D.4221;
D.4221 = (uint128_t) *i;
res = __builtin_parityll ((unsigned long) D.4221 ^ (unsigned long)
(D.4221 >> 64));
Le 19/11/2021 à 10:40, Jakub Jelinek via Fortran a écrit :
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Hello,
you know probably better than me or any fortran maintainer whether it’s
good or bad.
So OK from the fortran side.
Le 19/11/2021 à 20:47, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
scalariziation of the elemental intrinsic LEN_TRIM was ICEing
when the optional KIND argument was present.
The cleanest solution is to use the infrastructure added by
Mikael's fix for PR97896. In that case it is a 1-l
Le 15/11/2021 à 22:38, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
the attached patch fixes the handling of the DEC trigonometric intrinsics
for different argument kinds. It is based on the original patch by Steve,
which fixes the lookup for the needed intrinsics.
Regtested on x86_64
