Hi Paul,
the patch looks reasonable to me. Ok for mainline.
Just a side-thought: Could it be possible, that the for-loop in trans-decl does
not find the result? Would an assert after the loop at least give a hint, where
something went wrong? That's just from reading the code, so if you think that
Hi All,
This patch fixes a double ICE arising from confusion between the dummy
symbol arising from a module function/subroutine interface and the module
procedure itself. In both cases, use of the name is unambiguous, as
explained in the ChangeLog. The testcase contains both the original and the
v
Dear all,
while looking at details of a related but slightly different PR, I found
that we did evaluate the arguments to MINLOC/MAXLOC too often in the
inlined version.
The attached patch creates temporaries for array elements where needed,
and ensures that each array element is only touched onc
The first error message in my previous email led me to the following
constraint:
“*C1130* A *variable-name *that appears in a LOCAL or LOCAL_INIT
*locality-spec *shall not have the ALLOCATABLE, INTENT (IN), or OPTIONAL
attribute, shall not be of finalizable type, shall not have an allocatable
ult
I recently built the master branch of Iain's fork of gcc in order to test
the support for locality specifiers. I have verified that the branch I
built contains the commit mentioned in this email thread
20b8500cfa522ebe0fcf756d5b32816da7f904dd. The code below isn't designed to
do anything useful
Hi Damian,
looking into the code I neither find the keyword LOCAL nor REDUCE. The match
routine also does not give any hint that those keywords are supported in a do
concurrent loop.
And here is the existing bug
ticket: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101602
But I don't see a ticket
