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