https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #10 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #9)
> > OK, sounds like it might be an unrelated issue to the one I'm seeing. The
> > following variant of that test crashes for me as well, even though there
> > aren't
> > any allocatable character strings in it. There's still no allocation code
> > generated.
>
> I got a segfault with this test since at least 4.8.5 up to trunk (9.0).
From F2018:11.1.3.3
"Within an ASSOCIATE, CHANGE TEAM, or SELECT TYPE construct, each associating
entity has the same rank as its associated selector. The lower bound of each
dimension is the result of the intrinsic function LBOUND (16.9.109) applied to
the corresponding dimension of selector. The upper bound of each dimension is
one less than the sum of the lower bound and the extent. The associating entity
does not have the ALLOCATABLE or POINTER attributes; it has the TARGET
attribute if and only if the selector is a variable and has either the TARGET
or POINTER attribute."
As I read that, or its equivalent in earlier standards, reallocation on
assignment cannot occur for the likes of the testcase in comments #5 and #8. I
guess that we have to think of a suitable runtime check to flag this up. How do
the other brands behave?
However, I think that the original testcase is valid and that the allocation on
assignment should occur. I will take this but it joins an ever increasing
number of bugs that I have on my TODO list.
Paul
