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 8FBF93858D28; Sun, 14 Jan 2024 20:05:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8FBF93858D28
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1705262751;
	bh=vWdyMrsbVpYAoR6a4nSJ4Y8XVQk6TWQe2IsaSz6/BXk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=W+4b/h/Wy4Ou+EXJbeYVelQcJLCS9XOqGJE18fWKcu2QaKgAquuRP4yh45jHL9Ik3
	 skaq93siBStOAcdEx0PG04z9ZjSUyhdCUZ97hXzhMPCTcdKGRnpyegig2jkyblNUX2
	 fXr/dXNFF59aTlav86wNSY/Z10TB4YkFNDDy5KBc=
From: "anlauf 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: Sun, 14 Jan 2024 20:05:51 +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: anlauf 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-Ti5aYpTtAM@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 #2 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #1)
> (In reply to anlauf from comment #0)
> > The dump-tree suggests that the scalarizer sees the loop invariant j,
> > unconditionally dereferences it outside the loop,
>=20
> Note that the copy to the variable before the loop does NOT dereference t=
he
> pointer.

You are right: I was mistaken as I was looking at the code generated for
PR67277, especially at testcase gfortran.dg/ishftc_optional_size_1.f90,
function ishftc4_ref_4, where the scalarization deferences the optional
argument size_,

    D.4389 =3D *size_;

outside of the loop.

> This case is explicitly supported by the scalarizer, see
> gfc_scalar_elemental_arg_saved_as_reference (and
> gfc_walk_elemental_function_args for the initialization of the
> can_be_null_ref field).

I'll need to have a closer look here.

Note that adding a scalar call in function one:

    r(1) =3D two (i(1), j)

generates sane code:

  *((integer(kind=3D4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE_E=
XPR
<stride.0>) * 4)) =3D two (&(*i)[0], j !=3D 0B ? *j : 0, j !=3D 0B);

> Normally this is sufficient to support optional dummies (there is also
> additional support for class wrappers in gfc_conv_procedure_call), except=
 if
> value comes into play.
>=20
> > generates code that
> > unconditionally dereferences j in the invocation of two, and uses a
> > wrong interface:
> These are the topics to investigate.
> I suppose we need to duplicate (or factor) the code for optional, value
> dummies that was added for non-elemental procedures in
> gfc_conv_procedure_call.

Probably yes.

There is another observation: using the value attribute for j also in one,
the scalar call from above becomes a straight

  *((integer(kind=3D4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE_E=
XPR
<stride.0>) * 4)) =3D two (&(*i)[0], j, .j);

while the scalarizer produces:

    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);

which looks more complicated (besides being wrong...)=