On 1/30/25 1:44 PM, Harald Anlauf wrote:
Dear all,
analyzing the the PR (by Gerhard) turned out to two slightly related
issues. The first one, where a variable in a COMMON block is falsely
resolved to a derived type declared in the host, leads to a false
freeing of the symbol, resulting in memory corruption and ICE.
If we already know that the symbol is in a common block, we may
just skip that interface search.
The other issue is a resolution issue, where the derived type
declared in the host is used in a variable declaration in the
procedure (as type or class), and a variable of the same name
as the derived type is used in a common block but later resolves
to a basic type, without a proper detection of the conflict.
But as this issue is found to be independent of the presence of
a COMMON block, I have opened a separate issue (pr118709) for it.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Looks good to go Harald.
As always, thanks for the fix.
Jerry
