[Bug c/83172] New: -Wstack-size= doesn't detect the correct stack size with VLA or alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83172 Bug ID: 83172 Summary: -Wstack-size= doesn't detect the correct stack size with VLA or alloca Product: gcc Version: 4.8.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hao.hou at utah dot edu Target Milestone: --- Created attachment 42723 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42723&action=edit The preprocessed source code repoduce the bug The -Wstack-usage= doesn't deduce the correct stack size and reports an unbounded stack size in the following case: 1. The function uses a variable length array 2. The function uses alloca Even with alloca(constant) or __builtin_unreachable hints the VLA size, compiler still mark the max stack size unbounded. Another related option -Wvla-larger-than= does inferred the maximum VLA size from the __builtin_unreachable hints. The expected behavior should be -Wstack-usage= also follows the hint, at least, for the alloca(constant) case, it should realize the stack size could not be unbounded. GCC Version: Using built-in specs. COLLECT_GCC=gcc-7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.1.0-10ubuntu1~16.04.york0' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.1.0 (Ubuntu 7.1.0-10ubuntu1~16.04.york0) And the preprocessed file that repo this bug is attached. The command used to repo the bug and it's output: $ gcc-7 -save-temps -Wvla-larger-than=128 -Wstack-usage=102400 -O3 -c t.c t.c: In function ‘stack_usage_only’: t.c:21:5: warning: stack usage might be unbounded [-Wstack-usage=] int stack_usage_only(unsigned x) ^~~~ t.c: In function ‘alloca_fails_even_with_const’: t.c:30:5: warning: stack usage might be unbounded [-Wstack-usage=] int alloca_fails_even_with_const() ^~~~ Expected: Compiles without any warning.
[Bug c/83174] New: -Wvla-larger-than reports wrong VLA size in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83174
Bug ID: 83174
Summary: -Wvla-larger-than reports wrong VLA size in some cases
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hao.hou at utah dot edu
Target Milestone: ---
Created attachment 42725
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42725&action=edit
The preprocessed source code repoduce the bug
There's some cases that -Wvla-lager-than only warns mistakenly only when the
strlen result is used as allocation size when -O2 or higher is turned on
Example code:
extern void f(void* ptr);
extern char* s;
void good(void)
{
unsigned long long l = __builtin_strlen(s);
if(l < 4)
{
char b[l&2];
f(b);
}
}
void bad(void)
{
unsigned long long l = __builtin_strlen(s);
if(l < 4)
{
char b[l&3];
f(b);
}
}
Compiler arguments:
$ gcc-7 -Wvla-larger-than=0x100 -O3 -S -c db.c
db.c: In function ‘bad’:
db.c:18:8: warning: argument to variable-length array may be too large
[-Wvla-larger-than=]
char b[l&3];
^
db.c:18:8: note: limit is 16777216 bytes, but argument may be as large as
9223372036854775806
It only warns the function uses l&3 as the VLA size.
Compiler Version:
Using built-in specs.
COLLECT_GCC=gcc-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.1.0-10ubuntu1~16.04.york0'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.1.0 (Ubuntu 7.1.0-10ubuntu1~16.04.york0)
[Bug c/83172] -Wstack-size= doesn't detect the correct stack size with VLA or alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83172 --- Comment #2 from Hao Hou --- (In reply to Eric Botcazou from comment #1) > What happens for -Wvla-larger-than= if you use -O0 or -O1 instead of -O3? The same result: $ gcc-7 -Wvla-larger-than=128 -Wstack-usage=102400 -O0 -c t.c t.c: In function ‘stack_usage_only’: t.c:23:5: warning: stack usage might be unbounded [-Wstack-usage=] int stack_usage_only(unsigned x) ^~~~ t.c: In function ‘alloca_fails_even_with_const’: t.c:32:5: warning: stack usage might be unbounded [-Wstack-usage=] int alloca_fails_even_with_const() ^~~~ -O1 results the same.
[Bug c/83172] -Wstack-size= doesn't detect the correct stack size with VLA or alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83172
--- Comment #4 from Hao Hou ---
(In reply to Eric Botcazou from comment #3)
> > The same result:
> >
> > $ gcc-7 -Wvla-larger-than=128 -Wstack-usage=102400 -O0 -c t.c
> > t.c: In function ‘stack_usage_only’:
> > t.c:23:5: warning: stack usage might be unbounded [-Wstack-usage=]
> > int stack_usage_only(unsigned x)
> > ^~~~
> > t.c: In function ‘alloca_fails_even_with_const’:
> > t.c:32:5: warning: stack usage might be unbounded [-Wstack-usage=]
> > int alloca_fails_even_with_const()
> > ^~~~
> >
> > -O1 results the same.
>
> Try -Wvla-larger-than=100 though.
>
> In any case, note that for:
>
> int vla_size_only(unsigned x)
> {
> if(x > 128) __builtin_unreachable();
> char buf[x];
> do_something(buf);
> return 0;
> }
>
> the warning is expected since the code may allocate more than 128 bytes.
>
> -Wstack-usage is designed to be *conservatively* correct and to yield the
> same result at all optimization levels, i.e. it will never say that the
> stack usage is bounded if there is a path where it may not be. So it's very
> different from
> -Wvla-larger-than or -Walloca-larger-than which say nothing at -O0 or -O1
> and are not conservatively correct.
Thanks Eric, that's a good point. I understand that eventhough the behavior of
the code when x > 128 is undefined, but it's up to the compiler if take this
case into consideration.
I tried to modify the code a little bit:
int stack_usage_only(unsigned x)
{
if(x <= 128)
{
if(x > 128) __builtin_unreachable();
char buf[x];
do_something(buf);
}
return 0;
}
The warning is stil there. I totally understand that the compiler infers the
size conservatively. But this case makes -Wstack-size= somehow equivalent to
-Wvla.
My idea on this warning is that it actually make much more sense when the VLA
or alloca has been used in the code, since it preventing VLA or alloca
allocating unbounded size of memory. That is why I was expecting it actually
infers the range of the x, thus it's an useful indicator of using VLA
correctly.
