Workaround for compiler bug: don't pass local_tag if not allocated. #217
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The change is a workaround for an apparent compiler bug.
Unallocated actual arguments passed to
optionaldummy arguments count as not present, according to the Standard. The code should behave the same way as if the argument was not passed at all. There was a transient runtime issue with one compiler, whereby such an argument was sometimes handled correctly and sometimes not. Crucially, it happens in the specific case where the actual argument is itself local to a subroutine (and does not have thesaveattribute).The change in this PR makes the argument actually not present if unallocated, without relying on the compiler to treat it as such.
Linked issues
Closes #216
Type of change
Change should be transparent.
How has this been tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Tag / no tag cases are already covered by the testing framework. Tested with the following skeleton program. With the issue being transient, ran the test many times. The output file produced was
vernier-output-0each time, with no strange characters. [Also tested with a tag, to check that functionality wasn't broken.]The GCC-13 + MPI tests failed the first time around. The address sanitizer reported memory leaks. Succeeded on rerun. Not clear that the failure was connected to the changes in this PR.
Checklist: