From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id BF46B385828A; Fri, 19 Jan 2024 18:46:45 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF46B385828A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1705690005;
	bh=yNd306wTCWW59XmmR4dJWanKnyuG44llrPzU82SvUqc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=oHH/wsvdPvg8YpzEwKLoG9f0uNcn9Dilnweg3VfujM9MRqEDy+OUgdAJIUM3MPYvb
	 3S7wWgLpRreGw5YvAtOcX6TYjzvqoz3+D1mrODzmhTbtOnFskvAHCrfkgW+Qv+TMF/
	 eHFh1hz6YZ22w2ExCAO33QSgq7yjIYJO8p7ygsk8=
From: "mikael at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/113377] Wrong code passing optional dummy argument to
 elemental procedure with optional dummy
Date: Fri, 19 Jan 2024 18:46:45 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikael at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113377-4-E2DYjX8erp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113377-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113377-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113377

--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #2)
> Note that adding a scalar call in function one:
>=20
>     r(1) =3D two (i(1), j)
>=20
> generates sane code:
>=20
>   *((integer(kind=3D4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE=
_EXPR
> <stride.0>) * 4)) =3D two (&(*i)[0], j !=3D 0B ? *j : 0, j !=3D 0B);
>=20
> (...)
>=20
> There is another observation: using the value attribute for j also in one,
> the scalar call from above becomes a straight
>=20
>   *((integer(kind=3D4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE=
_EXPR
> <stride.0>) * 4)) =3D two (&(*i)[0], j, .j);
>=20
> while the scalarizer produces:
>=20
>     integer(kind=3D4) * D.4340;
> ...
>     D.4340 =3D &j;
> ...
>           *((integer(kind=3D4) *) __result.0 + (sizetype) ((S.3 * D.4342 +
> D.4339) * 4)) =3D two (&(*i)[S.3 + -1], *D.4340);
>=20
> which looks more complicated (besides being wrong...)

Wrong I agree, but is it really more complicated?


(In reply to anlauf from comment #3)
> Created attachment 57108 [details]
> Patch to play with
>=20
> This is a first attempt to outline code for handling scalar dummies with =
the
> VALUE attribute.
>=20
> This fixes the following variants of the declaration of dummy argument j
> in function one:
>=20
>     integer, value,      optional :: j
>     integer, intent(in), optional :: j
>     integer, intent(in), optional :: j(4)
>     integer, intent(in), optional :: j(:)
>=20
Looks promising, maybe push a fix for just these cases as a first step?

> However,
>=20
>     integer, allocatable,optional :: j
>=20
Allocatable AND optional?
The standard seems to accept those, but do we support them?
... (searches) ...
Alright, we have some in the testsuite.
... (searches) ...
The argument passing convention is a double pointer in this case.

> still does not work: the code *in* the generated loop looks fine to me, b=
ut
> the scalarizer dereferences j before the loop.
>=20
> I think that this is correct F2018+, as ifx handles it fine.
> Not sure how to proceed here.
>=20
>=20
> Furthermore, the patch tries to cope (=3D prevent an ICE) with
>=20
>     integer, allocatable,optional :: j(:)
>=20
> which I think might be invalid.  At least it also crashed with ifx...
>=20
There is an error to report if it's invalid, but I doubt it is.=