From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 702AC3858C52; Sat, 13 May 2023 05:08:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 702AC3858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683954480; bh=YcmpQWh6X80EoW5RxQNqVPakIqoulmE4187LYXPTQCM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nTXeRKNd5zPzKTRqrdqIZ3dZCs/wDqZwJK6XpILlidIuJK9odAu+FsFMdfsy3BZ5y UZliJ5bmnZgpwOyDBBFApf+ZiQChayKwNLVBWa6ZadDcQmPQWAXaYhyyvHIyMgao11 REIllPiVep0mdUir+ciBbRz17s5aW+NxuNZYHbjA= From: "mkaracsony81 at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/104069] Wuse-after-free=2 -O0 false positive "may be used" Date: Sat, 13 May 2023 05:07:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: mkaracsony81 at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104069 --- Comment #34 from Miklos Karacsony --- (In reply to Sergei Trofimovich from comment #32) > Created attachment 55068 [details] > gzip.c.c >=20 > > > You should be able to extract preprocessed file using > > > https://gcc.gnu.org/bugs/#need: you will need to find exact `gcc` inv= ocation > > > that causes build failure, add `-save-temps` parameter to it, grab '*= .i' > > > file and attach it along with exact command you used to produce it. > >=20 > > That gcc page does not say how to extract the command from the makefile= that > > triggers the error, so I've tried to reproduce this bug manually and af= ter > > like the 8th attempt when all the header files were finally found by the > > compiler, the linker errored out with some undefined references, so no = luck. > > The good new is that this error is reproducible if the > > cflags/ldflags/configure...etc switches set up like in c#29 >=20 > gcc help can't cover specifics of external build systems. You have to hav= e a > bit of expertise to extract the actual command build system runs. >=20 > As elfutils is an automake-maked '$ make V=3D1' will print you every gcc > command the build system is running. It should be in a form you can copy = and > paste as is (modulo current directory and a few environment variables). >=20 > I think I reproduced it on gcc-12.2.0 and elfutils-0.189. Attached as > gzip.c.c. >=20 > Trigger on gcc-12.2.0: >=20 > $ gcc -std=3Dgnu99 -Wall -Werror -Os -mtune=3Dgeneric -c gzip.c.c > In function 'bigger_buffer', > inlined from '__libdw_gunzip' at gzip.c.c:7751:13: > gzip.c.c:7609:13: error: pointer may be used after 'realloc' > [-Werror=3Duse-after-free] > 7609 | b =3D realloc (state->buffer, more -=3D 1024); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > gzip.c.c:7605:15: note: call to 'realloc' here > 7605 | char *b =3D realloc (state->buffer, more); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > cc1: all warnings being treated as errors >=20 > gcc-master does not seem to reproduce the failure. I did not test gcc-13. Thank you for your last comment, it was really helpful. This bug is still present for me, which makes me think that gcc-master is a different branch than gcc-12. I grabbed the latest gcc tarball to test it u= sing the following commands: git clone --depth 1 git://gcc.gnu.org/git/gcc.git gcc-dir.tmp git --git-dir=3Dgcc-dir.tmp/.git fetch --depth 1 origin 0bfba6442264af83382c26f60286bd33c901178a git --git-dir=3Dgcc-dir.tmp/.git archive --prefix=3Dgcc-12.3.1-20230513/ 0bfba6442264af83382c26f60286bd33c901178a | xz -3 > gcc-12.3.1-20230513.tar.= xz then built gcc (gcc -v): Using built-in specs. COLLECT_GCC=3Dgcc COLLECT_LTO_WRAPPER=3D/usr/lib/gcc/x86_64-pc-linux-gnu/12.3.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /sources/gcc-12.3.1-20230513/configure --prefix=3D/usr --libdir=3D/usr/lib --libexecdir=3D/usr/lib --mandir=3D/usr/share/man --infodir=3D/usr/share/info --enable-bootstrap --enable-languages=3Dc,c++,l= to --enable-multilib --enable-install-libiberty --enable-checking=3Drelease --enable-default-pie --enable-default-ssp --with-abi=3Dm64 --with-arch=3Dx8= 6-64 --with-arch_32=3Dx86-64 --with-build-config=3Dbootstrap-lto --with-multilib-list=3Dm64,m32 --with-fpmath=3Dsse --with-linker-hash-style= =3Dgnu --with-system-zlib --with-tune=3Dgeneric --with-zstd --without-isl --disable-libitm --disable-libquadmath --disable-libsanitizer --disable-lib= vtv --disable-nls --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.3.1 20230513 (Netux R1) (GCC) and finally ran the elfutils build test, using the same environment, parame= ters as before. See attachment for the preprocessed file. The invocation of gcc that triggered the bug was: gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR=3D'"/usr/share/locale"' -I. -= I..=20 -I. -I. -I../lib -I.. -I. -I./../libelf -I./../libebl -I./../libdw -I./../libdwelf -I./../debuginfod -std=3Dgnu99 -Wall -Wshadow -Wformat=3D2 -Wold-style-definition -Wstrict-prototypes -Wtrampolines -Wlogical-op -Wduplicated-cond -Wnull-dereference -Wimplicit-fallthrough=3D5 -Wuse-after-free=3D3 -Werror -Wunused -Wextra -Wstack-usage=3D262144=20=20 -D_FORTIFY_SOURCE=3D3 -Os -mtune=3Dgeneric -MT gzip.o -MD -MP -MF .deps/gzi= p.Tpo -c -o gzip.o gzip.c=