[Bug tree-optimization/64322] More optimize opportunity for constant folding

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

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

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> For VRP I'm thinking of (completely untested):
> --- gcc/tree-vrp.c.jj	2014-12-01 14:57:30.000000000 +0100
> +++ gcc/tree-vrp.c	2014-12-16 10:17:27.543111649 +0100
> @@ -2434,6 +2434,7 @@ extract_range_from_binary_expr_1 (value_
>        && code != MAX_EXPR
>        && code != PLUS_EXPR
>        && code != MINUS_EXPR
> +      && code != RSHIFT_EXPR
>        && (vr0.type == VR_VARYING
>  	  || vr1.type == VR_VARYING
>  	  || vr0.type != vr1.type
> @@ -2948,6 +2949,15 @@ extract_range_from_binary_expr_1 (value_
>  	{
>  	  if (code == RSHIFT_EXPR)
>  	    {
> +	      /* Even if vr0 is VARYING or otherwise not usable, we can derive
> +		 useful ranges just from the shift count.  E.g.
> +		 x >> 63 for signed 64-bit x is always [-1, 0].  */
> +	      if (vr0.type != VR_RANGE || symbolic_range_p (&vr0))
> +		{
> +		  vr0.type = type = VR_RANGE;
> +		  vr0.min = vrp_val_min (expr_type);
> +		  vr0.max = vrp_val_max (expr_type);
> +		}

Yeah, that should work.  We should probably simply handle all operation
codes that do not explicitely handle non-simple VR_RANGEs by promoting
all operands that way (also handle the single-VR_UNDEFINED op case and
VR_VARYING generally that way).  The DIV and MOD_EXPR cases look like
they would benefit from that.

>  	      extract_range_from_multiplicative_op_1 (vr, code, &vr0, &vr1);
>  	      return;
>  	    }
>From gcc-bugs-return-470857-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 16 11:58:46 2014
Return-Path: <gcc-bugs-return-470857-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19962 invoked by alias); 16 Dec 2014 11:58:46 -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 19911 invoked by uid 48); 16 Dec 2014 11:58:42 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/64322] More optimize opportunity for constant folding
Date: Tue, 16 Dec 2014 11:58: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: 5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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-64322-4-pWR8dwcmwz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64322-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64322-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-12/txt/msg01864.txt.bz2
Content-length: 1896

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > For VRP I'm thinking of (completely untested):
> > --- gcc/tree-vrp.c.jj	2014-12-01 14:57:30.000000000 +0100
> > +++ gcc/tree-vrp.c	2014-12-16 10:17:27.543111649 +0100
> > @@ -2434,6 +2434,7 @@ extract_range_from_binary_expr_1 (value_
> >        && code != MAX_EXPR
> >        && code != PLUS_EXPR
> >        && code != MINUS_EXPR
> > +      && code != RSHIFT_EXPR
> >        && (vr0.type == VR_VARYING
> >  	  || vr1.type == VR_VARYING
> >  	  || vr0.type != vr1.type
> > @@ -2948,6 +2949,15 @@ extract_range_from_binary_expr_1 (value_
> >  	{
> >  	  if (code == RSHIFT_EXPR)
> >  	    {
> > +	      /* Even if vr0 is VARYING or otherwise not usable, we can derive
> > +		 useful ranges just from the shift count.  E.g.
> > +		 x >> 63 for signed 64-bit x is always [-1, 0].  */
> > +	      if (vr0.type != VR_RANGE || symbolic_range_p (&vr0))
> > +		{
> > +		  vr0.type = type = VR_RANGE;
> > +		  vr0.min = vrp_val_min (expr_type);
> > +		  vr0.max = vrp_val_max (expr_type);
> > +		}
> 
> Yeah, that should work.  We should probably simply handle all operation
> codes that do not explicitely handle non-simple VR_RANGEs by promoting
> all operands that way (also handle the single-VR_UNDEFINED op case and
> VR_VARYING generally that way).  The DIV and MOD_EXPR cases look like
> they would benefit from that

DIV and MOD already handle it (DIV quite similarly to this).  And from the list
of codes that extract_range_from_binary_expr_1 handles, I think RSHIFT_EXPR is
the only one that (for certain VR_RANGEs of one argument) can decrease a
VR_VARYING into something narrower and didn't handle arbitrary ranges of the
other operand yet.
>From gcc-bugs-return-470858-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 16 12:03:44 2014
Return-Path: <gcc-bugs-return-470858-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22332 invoked by alias); 16 Dec 2014 12:03:44 -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 22311 invoked by uid 48); 16 Dec 2014 12:03:40 -0000
From: "will at benfold dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/64329] New: Crash when returning reference from lambda with deduced type
Date: Tue, 16 Dec 2014 12:03: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.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: will at benfold 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-64329-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-12/txt/msg01865.txt.bz2
Content-length: 2669

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

            Bug ID: 64329
           Summary: Crash when returning reference from lambda with
                    deduced type
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: will at benfold dot com

Created attachment 34289
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id4289&actioníit
Preprocessed source

I believe the program below is valid and correct, but I see heap corruption at
the end of main() (in  std::map::~map) when I allow the compiler to deduce
return type of the lambda.

Both the parameters to apply() are still alive when the returned lambda is
invoked, so fn(arg) should safely return a valid const ref to a tuple.  If the
return type for the lambda is given explicitly (see comments in code) then
everything is fine, whether it's returning by value or by const ref.

Compiling with "-Wall --std=c++11 -O0 -g3"; optimisation level seems to make no
difference.

----------------------------------------------------------------

#include <functional>
#include <map>
#include <string>
#include <tuple>

typedef std::tuple<std::string, std::string, double> Result;
typedef std::map<int, Result> Argument;
typedef std::function<const Result & (const Argument &)> Function;

std::function<Result ()> apply (const Argument &arg, const Function &fn)
{
  //  No trouble with any of these...
  //  return [&fn, &arg]() -> Result          { return fn(arg); };
  //  return [&fn, &arg]() -> const Result &  { return fn(arg); };
  //  return [&fn, &arg]()                    { Result r = fn(arg); return r;
};

  //  But this causes heap corruption
      return [&fn, &arg]()                    { return fn(arg); };
}

const Result &func (const Argument &arg)
{
  //  std::map::at returns a const ref
  return arg.at(0);
}

int main (int argc, char *argv[])
{
  Argument arg;
  arg[0] = Result("", "a", 0);

  Function f = &func;
  auto g = apply(arg, f);
  g();
  return 0;
}

----------------------------------------------------------------

Using built-in specs.
COLLECT_GCC=/software/thirdparty/gcc/4.9.1-0.el6_64/bin/g++
COLLECT_LTO_WRAPPER=/software/thirdparty/gcc/4.9.1-0.el6_64/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/software/thirdparty/gcc/4.9.1-0.el6_64
--with-system-zlib --enable-shared --enable-threads=posix --enable-laguages=all
--with-ppl --with-cloog --disable-multilib
Thread model: posix
gcc version 4.9.1 (GCC)