From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15230 invoked by alias); 20 Sep 2013 23:55:44 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 15194 invoked by uid 48); 20 Sep 2013 23:55:41 -0000 From: "eblake at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/58488] New: -Wuninitialized is useless for a variable whose address is later taken Date: Fri, 20 Sep 2013 23:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: eblake at redhat dot com X-Bugzilla-Status: UNCONFIRMED 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: 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 X-SW-Source: 2013-09/txt/msg01569.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D58488 Bug ID: 58488 Summary: -Wuninitialized is useless for a variable whose address is later taken Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: eblake at redhat dot com Here's a simple example of where -Wuninitialized is rather useless at defau= lt optimization: $ cat foo.c #include int main(void) { char *oops; free(oops); void *other =3D #ifdef RELIABLE NULL #else &oops #endif ; return !other; } $ gcc -Werror -Wall -Wuninitialized -o foo -c foo.c $ gcc -Werror -Wall -Wuninitialized -o foo -c foo.c -DRELIABLE foo.c: In function =E2=80=98main=E2=80=99: foo.c:5:9: error: =E2=80=98oops=E2=80=99 is used uninitialized in this func= tion [-Werror=3Duninitialized] free(oops); ^ cc1: all warnings being treated as errors $ gcc -Werror -Wall -Wuninitialized -o foo -c foo.c -O2 foo.c: In function =E2=80=98main=E2=80=99: foo.c:5:9: error: =E2=80=98oops=E2=80=99 is used uninitialized in this func= tion [-Werror=3Duninitialized] free(oops); ^ cc1: all warnings being treated as errors $ gcc -Werror -Wall -Wuninitialized -o foo -c foo.c -DRELIABLE -O2 foo.c: In function =E2=80=98main=E2=80=99: foo.c:5:9: error: =E2=80=98oops=E2=80=99 is used uninitialized in this func= tion [-Werror=3Duninitialized] free(oops); ^ cc1: all warnings being treated as errors I understand that -O2 enables better uninitialization checks, but I find it quite awkward that even without -O2, the mere taking an address of a variab= le hides it from the uninit checker. My end goal is to have a macro that does= a one-shot evaluation of its argument: #define FREE(x) { typeof(x) *_x =3D &(x); free(*_x); *_x =3D NULL; } for safety, but that macro kills -Wuninit checking by virtue of the fact th= at it takes the address of the pointer. Even if I limit myself to a macro that evaluates its argument more than once (and forcing me to audit code to avoid FREE(side-effects) - if only there were a way to make the compiler automatically barf if it encounters side effects in a macro argument), I am unable to come up with a way to get the uninit checking that gcc provides regardless of optimization without also having the safety of ensuring the pointer isn't abused after the fact. >>From gcc-bugs-return-430330-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Sep 20 23:58:50 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 17795 invoked by alias); 20 Sep 2013 23:58:50 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 17759 invoked by uid 55); 20 Sep 2013 23:58:47 -0000 From: "danglin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload Date: Fri, 20 Sep 2013 23:58:00 -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: 4.8.0 X-Bugzilla-Keywords: build, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: danglin at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-09/txt/msg01570.txt.bz2 Content-length: 471 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791 --- Comment #4 from John David Anglin --- Author: danglin Date: Fri Sep 20 23:58:43 2013 New Revision: 202807 URL: http://gcc.gnu.org/viewcvs?rev=202807&root=gcc&view=rev Log: PR middle-end/56791 * config/pa/pa.c (pa_option_override): Disable auto increment and decrement instructions until reload is completed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c