[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

["glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #4)
> At some moment (in dcce1), gcc decides that x = 4 is not needed. For the
> same reason, it could realize that MEM[(struct foo *)&D.2281] = &x must
> produce a dangling reference, no?

A clobber implies that the content is lost, so it is useless to store something
there right before the clobber (I assume that's why the store is removed, I
didn't check), but I don't believe it implies that the memory location is
reclaimed (does it?), so it would be fine to store a pointer in some struct,
kill what that pointer points to, re-create something there, use that, etc.
Without the return statement, it is normal to remove x=4 (because of the
clobber), but I don't see anything to warn about, while we could warn with a
return statement and no clobber, so the 2 things seem quite different.

Of course I may be looking at this the wrong way.
>From gcc-bugs-return-463178-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 12:28:49 2014
Return-Path: <gcc-bugs-return-463178-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23047 invoked by alias); 3 Oct 2014 12:28:48 -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 22991 invoked by uid 48); 3 Oct 2014 12:28:41 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63445] request: make -Wstrict-overflow avoid a class of false positives
Date: Fri, 03 Oct 2014 12:28: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
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: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-63445-4-AFzRvOLTHT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63445-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63445-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: 2014-10/txt/msg00199.txt.bz2
Content-length: 1208

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-03
                 CC|                            |manu at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
I'm going to confirm this even if it is not clear it is possible to fix this.

Also, I think it is a bug that the loop condition has the location of the "for"
keyword and not of the "<" expression when lowering to gimple. That is,

 [test.c : 8:7] if (iD.1622 < nD.1621) goto <D.1623>; else goto <D.1625>; 

should be

 [test.c : 8:33] if (iD.1622 < nD.1621) goto <D.1623>; else goto <D.1625>; 

It gets even more confusing if the "i < n" is in the next line:

test.c:8:7: warning: assuming signed overflow does not occur when simplifying
conditional [-Wstrict-overflow]
       for (unsigned int i = 0;
       ^
>From gcc-bugs-return-463179-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 12:39:27 2014
Return-Path: <gcc-bugs-return-463179-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28971 invoked by alias); 3 Oct 2014 12:39:27 -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 28945 invoked by uid 48); 3 Oct 2014 12:39:23 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
Date: Fri, 03 Oct 2014 12:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.6.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
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-63446-4-ILsL62HwN3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63446-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63446-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: 2014-10/txt/msg00200.txt.bz2
Content-length: 1500

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

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #5)
> A clobber implies that the content is lost, so it is useless to store
> something there right before the clobber (I assume that's why the store is
> removed, I didn't check), but I don't believe it implies that the memory
> location is reclaimed (does it?), so it would be fine to store a pointer in
> some struct, kill what that pointer points to, re-create something there,
> use that, etc. Without the return statement, it is normal to remove x=4
> (because of the clobber), but I don't see anything to warn about, while we
> could warn with a return statement and no clobber, so the 2 things seem
> quite different.

OK, that makes sense. Thanks for the explanation. 

What about checking that the return value, if it is a VUSE, is not assigned to
a local? That is, this would be valid, assuming y is not local,

  MEM[(struct foo *)&D.2281] = &x;
  MEM[(struct foo *)&D.2281] = &y;
  return D.2281;

 but this would not be:

  MEM[(struct foo *)&D.2281] = &x;
  return D.2281;

It doesn't matter, whether x is clobbered or has a value and also it doesn't
matter what is executed between the assignment and the return as long as it
doesn't change the value of MEM[(struct foo *)&D.2281]. It could be a matter of
following the chain of VUSE->VDEF, which I think we already do for
Wuninitialized.
>From gcc-bugs-return-463180-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 12:40:01 2014
Return-Path: <gcc-bugs-return-463180-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29726 invoked by alias); 3 Oct 2014 12:40:01 -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 29693 invoked by uid 48); 3 Oct 2014 12:39:57 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/63449] documentation of vector space overhead management
Date: Fri, 03 Oct 2014 12:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: documentation
X-Bugzilla-Severity: trivial
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords bug_status cf_reconfirmed_on assigned_to everconfirmed
Message-ID: <bug-63449-4-rK9bSzleux@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63449-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63449-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-10/txt/msg00201.txt.bz2
Content-length: 920

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc449

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |documentation
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-10-03
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
("documentation" is a keyword, the component should be "libstdc++" so that the
relevant maintainers deal with it.)

I don't know/remember anything about that new implementation, but it never
happened so I think we can just remove the section.

The list::size() documentation above needs updating though.