[Bug c/58488] New: -Wuninitialized is useless for a variable whose address is later taken

[Bug c/58488] New: -Wuninitialized is useless for a variable whose address is later taken

[eblake at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58488

            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 default
optimization:

$ cat foo.c
#include <stdlib.h>

int main(void) {
    char *oops;
    free(oops);
    void *other =
#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 ‘main’:
foo.c:5:9: error: ‘oops’ is used uninitialized in this function
[-Werror=uninitialized]
     free(oops);
         ^
cc1: all warnings being treated as errors
$ gcc -Werror -Wall -Wuninitialized -o foo -c foo.c -O2
foo.c: In function ‘main’:
foo.c:5:9: error: ‘oops’ is used uninitialized in this function
[-Werror=uninitialized]
     free(oops);
         ^
cc1: all warnings being treated as errors
$ gcc -Werror -Wall -Wuninitialized -o foo -c foo.c -DRELIABLE -O2
foo.c: In function ‘main’:
foo.c:5:9: error: ‘oops’ is used uninitialized in this function
[-Werror=uninitialized]
     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 variable
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 = &(x); free(*_x); *_x = NULL; }

for safety, but that macro kills -Wuninit checking by virtue of the fact that
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: <gcc-bugs-return-430330-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
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" <gcc-bugzilla@gcc.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: <bug-56791-4-RGGoxbFAnn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56791-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56791-4@http.gcc.gnu.org/bugzilla/>
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?idV791

--- Comment #4 from John David Anglin <danglin at gcc dot gnu.org> ---
Author: danglin
Date: Fri Sep 20 23:58:43 2013
New Revision: 202807

URL: http://gcc.gnu.org/viewcvs?rev 2807&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

[Bug c/58488] -Wuninitialized is useless for a variable whose address is later taken

[manu at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5183 bytes --]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58488

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org
             Blocks|                            |24639

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
So you want the warning even with -O0?

I am not sure that, without optimization, the internal representation can
detect this case.
>From gcc-bugs-return-430368-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Sep 22 15:04:11 2013
Return-Path: <gcc-bugs-return-430368-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7664 invoked by alias); 22 Sep 2013 15:04:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7639 invoked by uid 48); 22 Sep 2013 15:04:08 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/58488] -Wuninitialized is useless for a variable whose address is later taken
Date: Sun, 22 Sep 2013 15:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
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: manu 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: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58488-4-s9Et14iTtS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58488-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58488-4@http.gcc.gnu.org/bugzilla/>
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/msg01608.txt.bz2
Content-length: 337

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58488

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Note that this has nothing to do with the fact that the uninitialized var is a
pointer:

void test(char);

int main(void) {
  char oops;
  test(oops);
  char *other = &oops;
  return !other;
}
>From gcc-bugs-return-430369-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Sep 22 16:57:39 2013
Return-Path: <gcc-bugs-return-430369-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10715 invoked by alias); 22 Sep 2013 16:57:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10676 invoked by uid 48); 22 Sep 2013 16:57:35 -0000
From: "borucki.andrzej at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58499] New: Option -fleading-underscore not works
Date: Sun, 22 Sep 2013 16:57: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.7.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: borucki.andrzej at gmail 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 attachments.created
Message-ID: <bug-58499-4@http.gcc.gnu.org/bugzilla/>
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/msg01609.txt.bz2
Content-length: 697

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX499

            Bug ID: 58499
           Summary: Option -fleading-underscore not works
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: borucki.andrzej at gmail dot com

Created attachment 30881
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id0881&actioníit
Project of DLL

I use gcc with code:block. when I compile DLL, exportet functions are without
undersocre despite of -fleading-underscore option.
Function in DLL is Java_net_sf_junace_UnACE_nativeACEList@20

[Bug c/58488] -Wuninitialized is useless for a variable whose address is later taken

[eblake at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58488

--- Comment #3 from Eric Blake <eblake at redhat dot com> ---
Since the engine is able to warn at -O0 when I _don't_ take the address, I
don't see why the warning is lost by the mere action of taking the address.

[Bug c/58488] -Wuninitialized is useless for a variable whose address is later taken

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58488

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The warning machinery is only able to warn about vars in SSA form, vars which
must live in memory can't be warned on easily.  So, for such variables you only
get warnings if the compiler is able as part of some optimization make the var
non-addressable (e.g. inlining and propagation can help that, etc.), or scalar
replacement of aggregates is able to break appart larger aggregates and use SSA
form for those.  Thus, you get better warnings with optimizations.

[Bug c/58488] -Wuninitialized is useless for a variable whose address is later taken

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58488

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |law at redhat dot com
         Resolution|---                         |WONTFIX

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
Jakub's comments in c#4 are 100% accurate.  This isn't something we're going to
change/fix.  Sorry.