https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753
Bug ID: 98753
Summary: -Wfree-nonheap-object on Bison generated code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: foss at grueninger dot de
Target Milestone: ---
Build: 11.0.0 20210114 (experimental) [revision
08a4adcf2b6ded2fea97195c715757df61a23395] (SUSE Linux)
Created attachment 50005
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50005&action=edit
C++ file generated by Bison
While compiling CMake with GCC 11.0, I spot some -Wfree-nonheap-object
warnings. These came from files generated by Bison. I regenerated the C++ files
with the latest GNU Bison release and the problem persisted. So I asked on the
Bison user list and one of the developers claims, that Bison is right.
I don't know whether it is a false positive or whether Bison has a bug.
1.
Attached is the C++ file generated by Bison (cmCommandArgumentParser.cxx).
2.
The warning I get from G++:
[ 54%] Building CXX object
Source/CMakeFiles/CMakeLib.dir/LexerParser/cmCommandArgumentParser.cxx.o
cmCommandArgumentParser.cxx: In function ‘int
cmCommandArgument_yyparse(yyscan_t)’:
cmCommandArgumentParser.cxx:1838:18: warning: ‘void free(void*)’ called on
unallocated object ‘yyssa’ [-Wfree-nonheap-object]
cmCommandArgumentParser.cxx:1203:16: note: declared here
3.
The explanation / reduced code from one of the Bison developers, why the code
is correct:
> GCC 11 is wrong here. The full story (taken from your file) is:
>
>> // Create.
>> yy_state_t yyssa[YYINITDEPTH];
>> yy_state_t *yyss = yyssa;
>> [...]
>> // Grow.
>> yystacksize *= 2;
>> {
>> yy_state_t *yyss1 = yyss;
>> union yyalloc *yyptr =
>> YY_CAST (union yyalloc *,
>> YYSTACK_ALLOC (YY_CAST (YYSIZE_T, YYSTACK_BYTES
>> (yystacksize))));
>> if (! yyptr)
>> goto yyexhaustedlab;
>> YYSTACK_RELOCATE (yyss_alloc, yyss);
>> if (yyss1 != yyssa)
>> YYSTACK_FREE (yyss1);
>> }
>> [...]
>> // Clean up
>> if (yyss != yyssa)
>> YYSTACK_FREE (yyss);
>
> Or, in words, we use a stack-allocated stack until it's too small and
> then we use a heap-allocated stack, and in that case, and that case
> only, we free it at the end. Said another way: we never ever call
> free(yyssa).
>
> So GCC's warning is a false positive.
Source: https://lists.gnu.org/archive/html/help-bison/2021-01/msg00021.html
4.
My GCC version is:
> gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210114 (experimental) [revision
08a4adcf2b6ded2fea97195c715757df61a23395] (SUSE Linux)
