[Bug middle-end/60741] New: [-Wmaybe-uninitialized] false negative and confusing warning message

[Bug middle-end/60741] New: [-Wmaybe-uninitialized] false negative and confusing warning message

[skvadrik at gmail dot com]

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

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

            Bug ID: 60741
           Summary: [-Wmaybe-uninitialized] false negative and confusing
                    warning message
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: skvadrik at gmail dot com

Created attachment 32521
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32521&action=edit
wmaybe_uninitialized_strange_behavior.c

Given this code:

    enum A { A1, A2 };
    enum B { B1 };
    static inline int fa (enum A a) {
        int n;
        switch (a) {
            case A1: n = 1; break;
            case A2: n = 2; break;
        }
        return n;
    }
    static inline int fb (enum B b) {
        int n;
        switch (b) {
            case B1: n = 1; break;
        }
        return n;
    }
    int main (int argc, char **) {
        return fa((A)argc) + fb((B)argc);
    }

$ g++ -O1 -Wall wmaybe_uninitialized_strange_behavior.c
wmaybe_uninitialized_strange_behavior.c: In function ‘int main(int, char**)’:
wmaybe_uninitialized_strange_behavior.c:27:36: warning: ‘n’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
     return fa((A)argc) + fb((B)argc);
                                    ^

1) gcc generates warning for 'fa' function, but not for 'fb' function.
2) The message points to the end of expression, that contains 'fa' call (not to
'fa' declaration, or at least to 'fa' call). The message mentions name of a
variable, that is used in 'fa' declaration. So we're lucky that the same name
doesn't appear in the calling function (main).
3) This all happens with -O1 or higher, with -O0 there's no warnings at all!
>From gcc-bugs-return-448126-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 02 14:49:17 2014
Return-Path: <gcc-bugs-return-448126-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8125 invoked by alias); 2 Apr 2014 14:49:16 -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 8064 invoked by uid 48); 2 Apr 2014 14:49:06 -0000
From: "andrew.n.sutton at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59361] cannot expand parenthesized pack expression
Date: Wed, 02 Apr 2014 14:49: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.2
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: andrew.n.sutton at gmail dot com
X-Bugzilla-Status: NEW
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: cc attachments.created
Message-ID: <bug-59361-4-fFxRI6n6LE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59361-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59361-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: 2014-04/txt/msg00146.txt.bz2
Content-length: 794

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

Andrew Sutton <andrew.n.sutton at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrew.n.sutton at gmail dot com

--- Comment #2 from Andrew Sutton <andrew.n.sutton at gmail dot com> ---
Created attachment 32522
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2522&actioníit
Proposed solution

The problem occurs in cp_parser_cast_expression. A term of having the form
(T())... cannot be parsed as a cast expression since the the expansion is only
applied to a part of the cast expression. If ... follows the closing paren, the
expression must be parsed as unary expression.

[Bug middle-end/60741] [-Wmaybe-uninitialized] false negative and confusing warning message

[manu at gcc dot gnu.org]

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

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

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

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
We don't warn for fb(), because PR18501.

So the only original bug here is the location when warning. The problem is the
locations that are propagated when transforming expressions. We reach:

  # n_4 = PHI <n_5(D)(3), [test.cc : 6:17] 1(6), [test.cc : 7:17] 2(4)>
<L3>:
  [test.cc : 20:32] # RANGE [-2147483648, 2147483647] NONZERO
0x00000000000000007
  _2 = n_4 + 1;

When instead we should have a location for n_4 that is different than the
location for '+'.

In any case, pointing to the closing parenthesis is very confusing. At worst it
should point to the '+'.
>From gcc-bugs-return-448128-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 02 15:56:38 2014
Return-Path: <gcc-bugs-return-448128-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13989 invoked by alias); 2 Apr 2014 15:56: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 13934 invoked by uid 48); 2 Apr 2014 15:56:33 -0000
From: "ian at airs dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
Date: Wed, 02 Apr 2014 15:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: ice-on-invalid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ian at airs dot com
X-Bugzilla-Status: NEW
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-60736-4-DBvPJAWlA9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60736-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60736-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: 2014-04/txt/msg00148.txt.bz2
Content-length: 4850

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`736

--- Comment #5 from Ian Lance Taylor <ian at airs dot com> ---
This is easy enough to recreate--do you really need valgrind output?

In any case, here it is.

> cat foo.c
#include <stdc-predef.h>

> valgrind gcc/cc1 foo.c
=%367== Memcheck, a memory error detector
=%367== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
=%367== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
=%367== Command: gcc/cc1 foo.c
=%367=vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBC 0xC3 0x48 0x98
0x48
=%367== valgrind: Unrecognised instruction at address 0x608f90.
=%367==    at 0x608F90: init_ggc() (hwint.h:260)
=%367==    by 0x99DDEE: toplev_main(int, char**) (toplev.c:1157)
=%367==    by 0x5A3176C: (below main) (libc-start.c:226)
=%367== Your program just tried to execute an instruction that Valgrind
=%367== did not recognise.  There are two possible reasons for this.
=%367== 1. Your program has a bug and erroneously jumped to a non-code
=%367==    location.  If you are running Memcheck and you just saw a
=%367==    warning about a bad jump, it's probably your program's fault.
=%367== 2. The instruction is legitimate but Valgrind doesn't handle it,
=%367==    i.e. it's Valgrind's fault.  If you think this is the case or
=%367==    you are not sure, please let us know and we'll try to fix it.
=%367== Either way, Valgrind will now raise a SIGILL signal which will
=%367== probably kill your program.
=%367== Invalid read of size 4
=%367==    at 0xF1CC8D: linemap_location_from_macro_expansion_p(line_maps*,
unsigned int) (line-map.c:948)
=%367==    by 0xF1CE2E: linemap_lookup(line_maps*, unsigned int)
(line-map.c:642)
=%367==    by 0x9DC257:
virt_loc_aware_diagnostic_finalizer(diagnostic_context*, diagnostic_info*)
(tree-diagnostic.c:111)
=%367==    by 0xF02837: diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) (diagnostic.c:801)
=%367==    by 0xF0357F: internal_error(char const*, ...) (diagnostic.c:1136)
=%367==    by 0x99C70F: crash_signal(int) (toplev.c:337)
=%367==    by 0x5A4649F: ??? (in /lib/x86_64-linux-gnu/libc-2.15.so)
=%367==    by 0x608F8F: init_ggc() (hwint.h:307)
=%367==    by 0x99DDEE: toplev_main(int, char**) (toplev.c:1157)
=%367==    by 0x5A3176C: (below main) (libc-start.c:226)
=%367==  Address 0x24 is not stack'd, malloc'd or (recently) free'd
=%367=cc1: internal compiler error: Illegal instruction
=%367==%367== Process terminating with default action of signal 11 (SIGSEGV)
=%367==  Access not within mapped region at address 0x24
=%367==    at 0xF1CC8D: linemap_location_from_macro_expansion_p(line_maps*,
unsigned int) (line-map.c:948)
=%367==    by 0xF1CE2E: linemap_lookup(line_maps*, unsigned int)
(line-map.c:642)
=%367==    by 0x9DC257:
virt_loc_aware_diagnostic_finalizer(diagnostic_context*, diagnostic_info*)
(tree-diagnostic.c:111)
=%367==    by 0xF02837: diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) (diagnostic.c:801)
=%367==    by 0xF0357F: internal_error(char const*, ...) (diagnostic.c:1136)
=%367==    by 0x99C70F: crash_signal(int) (toplev.c:337)
=%367==    by 0x5A4649F: ??? (in /lib/x86_64-linux-gnu/libc-2.15.so)
=%367==    by 0xF1CC8C: linemap_location_from_macro_expansion_p(line_maps*,
unsigned int) (line-map.c:948)
=%367==    by 0xF1CE2E: linemap_lookup(line_maps*, unsigned int)
(line-map.c:642)
=%367==    by 0x9DC257:
virt_loc_aware_diagnostic_finalizer(diagnostic_context*, diagnostic_info*)
(tree-diagnostic.c:111)
=%367==    by 0xF02837: diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) (diagnostic.c:801)
=%367==    by 0xF0357F: internal_error(char const*, ...) (diagnostic.c:1136)
=%367==  If you believe this happened as a result of a stack
=%367==  overflow in your program's main thread (unlikely but
=%367==  possible), you can try to increase the size of the
=%367==  main thread stack using the --main-stacksize= flag.
=%367==  The main thread stack size used in this run was 67108864.
=%367==%367== HEAP SUMMARY:
=%367==     in use at exit: 22,246 bytes in 10 blocks
=%367==   total heap usage: 266 allocs, 256 frees, 45,231 bytes allocated
=%367==%367== LEAK SUMMARY:
=%367==    definitely lost: 31 bytes in 1 blocks
=%367==    indirectly lost: 0 bytes in 0 blocks
=%367==      possibly lost: 0 bytes in 0 blocks
=%367==    still reachable: 22,215 bytes in 9 blocks
=%367==         suppressed: 0 bytes in 0 blocks
=%367== Rerun with --leak-check=full to see details of leaked memory
=%367==%367== For counts of detected and suppressed errors, rerun with: -v
=%367== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 2 from 2)
Segmentation fault (core dumped)

[Bug middle-end/60741] [-Wmaybe-uninitialized] false negative and confusing warning message

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-04-03
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #1)
> We don't warn for fb(), because PR18501.
> 
> So the only original bug here is the location when warning. The problem is
> the locations that are propagated when transforming expressions. We reach:
> 
>   # n_4 = PHI <n_5(D)(3), [test.cc : 6:17] 1(6), [test.cc : 7:17] 2(4)>
> <L3>:
>   [test.cc : 20:32] # RANGE [-2147483648, 2147483647] NONZERO
> 0x00000000000000007
>   _2 = n_4 + 1;
> 
> When instead we should have a location for n_4 that is different than the
> location for '+'.

The location of n_4 depends on the edge you are coming from (thus n_4
itself doesn't have a location). The warning code picks the location of an
actual
use of n_4 in that case, here that of

  _2 = n_4 + 1;

this points to the plus in main, but appearantly slightly wrong.  At the
point where we emit the warning we can't really do better, but we could at
least also hint where 'n' was declared and/or inlined from.

> In any case, pointing to the closing parenthesis is very confusing. At worst
> it should point to the '+'.
>From gcc-bugs-return-448178-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 03 10:18:53 2014
Return-Path: <gcc-bugs-return-448178-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23254 invoked by alias); 3 Apr 2014 10:18:52 -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 23199 invoked by uid 48); 3 Apr 2014 10:18:48 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/60706] FAIL: gfortran.dg/size_kind_2.f90  -O   scan-tree-dump original "var2 = 42949673 00;"
Date: Thu, 03 Apr 2014 10:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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-60706-4-qHbPkk3uRF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60706-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60706-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: 2014-04/txt/msg00198.txt.bz2
Content-length: 1184

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`706

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Bah.  Then we need to use the preprocessor to avoid the warning:

Index: gcc/tree-pretty-print.c
==================================================================--- gcc/tree-pretty-print.c     (revision 209018)
+++ gcc/tree-pretty-print.c     (working copy)
@@ -3467,6 +3469,14 @@ pp_double_int (pretty_printer *pp, doubl
     pp_unsigned_wide_integer (pp, d.low);
   else
     {
+#if HOST_BITS_PER_DOUBLE_INT == HOST_BITS_PER_WIDEST_INT
+      pp_scalar (pp,
+                uns
+                ? HOST_WIDEST_INT_PRINT_UNSIGNED : HOST_WIDEST_INT_PRINT_DEC,
+                (HOST_WIDEST_INT)
+                (((unsigned HOST_WIDEST_INT) d.high << HOST_BITS_PER_WIDE_INT)
+                 | d.low));
+#else
       unsigned HOST_WIDE_INT low = d.low;
       HOST_WIDE_INT high = d.high;
       if (!uns && d.is_negative ())
@@ -3481,5 +3491,6 @@ pp_double_int (pretty_printer *pp, doubl
               HOST_WIDE_INT_PRINT_DOUBLE_HEX,
               (unsigned HOST_WIDE_INT) high, low);
       pp_string (pp, pp_buffer (pp)->digit_buffer);
+#endif
     }
 }

[Bug middle-end/60741] -Wmaybe-uninitialized wrong location

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60741

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
The poor location in C++ is also tracked in pr81714.  Let me keep that bug open
since it has a simpler test case and resolve this one as its dupe.

(The C front end does point to the + expression.)

*** This bug has been marked as a duplicate of bug 81714 ***