From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3EE9E385414D; Fri, 12 May 2023 20:36:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3EE9E385414D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683923800; bh=uj6bKEkC56GbsmtnFlGpCUbUiV++ROg+lcJIff50Tbk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UVnH7E3tVZqcwcfGorVYBJ4ZvSMFQ8ncH0hXwyyWEOPlSwjHOy2yKJHI9Osa1t9vx iFxHkZnyIDAVWEkMLVHCew7Zfk4xK8EyhW4doPLfP3R4qNfYHAvTrBShCWD25QjS/c e+9L4oiPGqY01fgsB7fwY5R9xBEesw4B2cujRa8s= From: "slyfox at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/104069] Wuse-after-free=2 -O0 false positive "may be used" Date: Fri, 12 May 2023 20:36:39 +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: slyfox at gcc dot gnu.org 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: attachments.created 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 #32 from Sergei Trofimovich --- Created attachment 55068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D55068&action=3Dedit gzip.c.c > > You should be able to extract preprocessed file using > > https://gcc.gnu.org/bugs/#need: you will need to find exact `gcc` invoc= ation > > 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 t= hat > triggers the error, so I've tried to reproduce this bug manually and after > 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 lu= ck. > The good new is that this error is reproducible if the > cflags/ldflags/configure...etc switches set up like in c#29 gcc help can't cover specifics of external build systems. You have to have a bit of expertise to extract the actual command build system runs. As elfutils is an automake-maked '$ make V=3D1' will print you every gcc co= mmand 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). I think I reproduced it on gcc-12.2.0 and elfutils-0.189. Attached as gzip.= c.c. Trigger on gcc-12.2.0: $ 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 gcc-master does not seem to reproduce the failure. I did not test gcc-13.=