Branch: refs/heads/main
Revision: 02e0fe066c793d881a2386e379d97034dfa87607
Author: bradcray
Link: Squash gcc 13.1 `stringop-overflow` warning by bradcray · Pull Request #22353 · chapel-lang/chapel · GitHub
Log Message:
Squash gcc 13.1 stringop-overflow warning (#22353)
[reviewed by @DanilaFe]
The GASNet team pointed out that GCC 13.1 complains about a memmove()
reached from chpl_comm_get...() calls that it believes will read from
a region of size 0 (#22337). I spent some time looking through stack
traces to see whether I believed that the memmove() was inherently
problematic and was unable to convince myself that it was. Moreover, I
was unable to come up with any explanation for how GCC was able to think
that it could be problematic—the expressions computing the addresses
passed in are sufficiently gnarly that it seemed unlikely to me that it
could be an actual problem, particularly given that we run asan testing
with GASNet, which would presumably catch the issue if there was one. My
best guesses as to why it's complaining are:
- maybe the memmove() path would be problematic if we took it for a
remote case, but since we only take it on a local get() case it's not?
(yet if that's the case, shouldn't GASNet be conservative and assume
we're not taking that branch?) - maybe GCC 13.1 has a bug or is being overly aggressive
Then, researching the issue more, I realized that this warning is very
similar to the no-stringop-overflow and no-array-bounds warnings
that we already squash. So I took the approach of squashing it as well
in GCC 13.x and above.
Resolves #22337.
Diff:
M make/compiler/Makefile.gnu
https://github.com/chapel-lang/chapel/pull/22353.diff