VLA type mentioned in diagnostics involve nonsensical bounds. The type should instead be 'char[m][n]' $ cat z.c && gcc -O2 -S -Wall z.c #if 1 void f (void*); void g (int m, int n) { char a[m][n]; a[-1][0] = 0; f (a); } z.c: In function ‘g’: z.c:6:4: warning: array subscript -1 is below array bounds of ‘char[<U1ea0> + 1][<U1cf0> + 1]’ [-Warray-bounds] 6 | a[-1][0] = 0; | ~^~~~ The C++ front end isn't much better: z.c: In function ‘void g(int, int)’: z.c:6:7: warning: array subscript -1 is below array bounds of ‘char [(<anonymous> + 1)][(<anonymous> + 1)]’ [-Warray-bounds] 6 | a[-1][0] = 0; | ~~~~^
I've encountered a similarly nonsensical error on trunk, though not with VLAs, instead with a char array of size 0: #include <stdio.h> int main(){ puts(((char[0]){})); } <source>: In function 'main': <source>:4:9: warning: 'puts' reading 1 or more bytes from a region of size 0 [-Wstringop-overread] 4 | puts(((char[0]){})); | ^~~~~~~~~~~~~~~~~~~ <source>:4:24: note: source object '<U ea0>' of size 0 4 | puts(((char[0]){})); | ^ ASM generation compiler returned: 0 <source>: In function 'main': <source>:4:9: warning: 'puts' reading 1 or more bytes from a region of size 0 [-Wstringop-overread] 4 | puts(((char[0]){})); | ^~~~~~~~~~~~~~~~~~~ <source>:4:24: note: source object '<U ea0>' of size 0 4 | puts(((char[0]){})); | ^
(In reply to Gabriel Ravier from comment #1) > I've encountered a similarly nonsensical error on trunk, though not with > VLAs, instead with a char array of size 0: It is not nonsensical at all. It just has an anonymous name for the object which is different from the original issue of an anonynous name for the bounds.
Well, nonsensical from the point of view of the user - it didn't seem to be particularly different to me for the error to evoke an object as "<U1ea0> + 1" when it just means a VLA and "<U ea0>" when it just means an empty array (both seem incomprehensible or at the very least pretty unexpected to the typical user imo). Though, if you think this is a completely different bug I wouldn't mind opening a different one, this just seemed like it had the same cause on account of the instances of "<U.ea0>" being particularly similar.