https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106757

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #3)
> Is this the same bug, so just a simpler test case?
> 
> bergner@fowler:LTC193379$ cat bug.c
> int len = 16;
> extern char *src;
> char dst[16];
> 
> void
> foo (void)
> {
> #ifdef OK
>   for (int i = 0; i < 16; i++)
> #else
>   for (int i = 0; i < len; i++)
> #endif
>     dst[i] = src[i];
> }
> 
> bergner@fowler:LTC193379$
> /home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc/xgcc
> -B/home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc -S -O3 -DOK
> -ftree-vectorize bug.c
> 
> bergner@fowler:LTC193379$
> /home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc/xgcc
> -B/home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc -S -O3 -UOK
> -fno-tree-vectorize bug.c
> 
> bergner@fowler:LTC193379$
> /home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc/xgcc
> -B/home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc -S -O3 -UOK
> -ftree-vectorize bug.c
> bug.c: In function ‘foo’:
> bug.c:13:12: warning: writing 1 byte into a region of size 0
> [-Wstringop-overflow=]
>    13 |     dst[i] = src[i];
>       |     ~~~~~~~^~~~~~~~
> bug.c:3:6: note: at offset 16 into destination object ‘dst’ of size 16
>     3 | char dst[16];
>       |      ^~~
> bug.c:13:12: warning: writing 1 byte into a region of size 0
> [-Wstringop-overflow=]
>    13 |     dst[i] = src[i];
>       |     ~~~~~~~^~~~~~~~
> bug.c:3:6: note: at offset 17 into destination object ‘dst’ of size 16
>     3 | char dst[16];
>       |      ^~~
> 
> I'll note that -fno-unroll-loops doesn't affect anything.

It looks similar.  Note the code we warn is isolated by DOM threading
after loop opts here.  The unrolling done is also a bit excessive but
that's because we estimate an upper bound on the epilogue based on
the array size accessed.

The IL we diagnose is definitely bogus but unreachable at runtime which
we don't see so it's also a code size issue.

Reply via email to