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 CEA173885C34; Thu, 24 Nov 2022 21:40:34 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CEA173885C34
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1669326034;
	bh=kfbqcSfwvQ8uLgu+sa/ReyvHag0kxzxo3kXxbtuV4LY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=iIKPzAx+0+mnSOgsaBzG7ODSMEynAIiSpve+SY3NlCbZtdPdB2oHSGK0gxBfef890
	 XSEu9Ow12uA1omE51HrXaqgHX75j3SDmXlN24STvKItBVKNoBjlGd4aFg49D9LyIC4
	 /Z0iJncY3CiddEMs3qQgmIH7g/xvfgHK75UaHixM=
From: "mikael at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at
 fortran/dependency.cc:978
Date: Thu, 24 Nov 2022 21:40:34 +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: 13.0
X-Bugzilla-Keywords: ice-on-invalid-code, ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikael at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-107819-4-pcCJXM1w79@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107819-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107819-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=3D107819

--- Comment #8 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #3)
> Could need help by some expert on this...

I guess I qualify as expert.
Reading the code again after years, it is not exactly crystal clear...

Here is a dump of what I could gather about the gfc_check_fncall_dependency=
 and
friends functions.


The different gfc_dep_check cases are the following:


ELEM_DONT_CHECK_VARIABLE:
This is the simple case of direct subroutine call.
As per the 15.5.2.13 I quoted above, this is invalid:
  call elem_sub(a(2:n), a(1:n-1))
while this isn't
  call elem_sub(a, a)

so we can always generate:
  do i =3D ...
    call elem_sub(a(...), a(...))
  end do

without caring for temporaries


ELEM_CHECK_VARIABLE:
This is the case of multiple elemental procedures.
For example:
  call elem_sub(a, elem_func(a))

The semantics is like:
  tmp =3D elem_func(a)
  call elem_sub(a, tmp)

Here, elem_sub can write to a without modifying tmp, and we have to
preserve that.
We generate code like this:
  do i =3D ...
    call elem_sub(tmp(i), elem_func(a(i)))
  end do
  a =3D tmp
and try to avoid the temporary tmp if possible.
we explore the second argument to elem_sub and look for the same variable
as the expression from the first one, and we generate a temporary
if we find it.  But there is no need if they are strictly the same
variable reference.


NOT_ELEMENTAL:
This is the case of the presence of transpose in the expression
For example, for elem_sub(var, elem_func(transpose(var))), the semantics is:
  tmp1 =3D transpose(var)
  tmp2 =3D elem_func(tmp1)
  call elem_sub(var, tmp2)

which we try to preserve, but with less temporaries.
We try to generate
  do i =3D ..., j =3D ...
    call elem_sub(tmp(i,j), elem_func(var(j,i)))
  end do
  var =3D tmp

and try to avoid the temporary tmp if possible (it's not with this example).
We have to make sure that if the same variable appears in a subexpression
of the argument, a temporary is generated.
Contrary to the previous case, we have to generate the temporary
even if the variable references are strictly the same.=