https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124638
Bug ID: 124638
Summary: gcc 11..15.2 gives phoney stringop-overflow warning
for 2d array function parm
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: breiten at lexmark dot com
Target Milestone: ---
I started seeing this with gcc-11.1 for the arm64 targets, and godbolt shows
that this is still the case all the way up to gcc-15.2 and trunk. (as of March
25, 2026) The code included has been reduced from the spandsp project.
typedef struct lpc10_encode_state_s lpc10_encode_state_t;
struct lpc10_encode_state_s
{
int voibuf[4][2];
};
extern void lpc10_placea( int voibuf[4][2]);
void lpc10_analyse(lpc10_encode_state_t *s, int voice[])
{
s->voibuf[0][0] = s->voibuf[1][0];
s->voibuf[0][1] = s->voibuf[1][1];
lpc10_placea(s->voibuf);
}
Here's the warning with -O2 or -O3 (no warning flag is necessary).
xx.c:13:5: warning: 'lpc10_placea' accessing 32 bytes in a region of size 8
[-Wstringop-overflow=]
13 | lpc10_placea(s->voibuf);
| ^~~~~~~~~~~~~~~~~~~~~~~
xx.c:13:5: note: referencing argument 1 of type 'int[4][2]'
xx.c:8:13: note: in a call to function 'lpc10_placea'
8 | extern void lpc10_placea( int voibuf[4][2]);
| ^~~~~~~~~~~~
So the warning is on a call to an external function ... clearly no stringop
here... And the reason I'm reporting this is that the assignments shuffling
two array members is necessary for the warning to be present. Removing either
of them makes this warning disappear. As does moving them to after the call.
Also, changing to target of the assignment to s->voibuf[0][1] to into
s->voibuf[2][0] or s->voibuf[3][0] also makes the warning disappear.
I was able to see that changing the external declaration to take an int[][2]
rather than an int[4][2] makes this code compile without any warning.
