[Bug c++/59739] missed optimization: attribute ((pure)) could be honored more often

["joerg.richter@pdv-fs.de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #1 from Jörg Richter <joerg.richter@pdv-fs.de> ---
clang seems to optimize all cases.
>From gcc-bugs-return-440462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 15 16:33:39 2014
Return-Path: <gcc-bugs-return-440462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1932 invoked by alias); 15 Jan 2014 16:33: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 1509 invoked by uid 48); 15 Jan 2014 16:33:33 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59821] __builtin_LINE and __builtin_FILE for new'd objects is wrong
Date: Wed, 15 Jan 2014 16:33: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: wrong-debug
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: cc
Message-ID: <bug-59821-4-pdEM1k1buy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59821-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59821-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-01/txt/msg01604.txt.bz2
Content-length: 2287

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

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

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For the calls this just happens to work completely by accident, nothing else.
I mean, the default argument expression obviously has location_t from where it
has been defined, i.e. the function/method/ctor definition.  The reason why in
the first case you get the locus of the call is that gimplify_arg sets the
location_t of the arguments to that, but only on the toplevel expression.
Now, in the new case the C++ FE adds an TARGET_EXPR around the default argument
and so during the gimplification it is no longer toplevel expression in the
argument, so gimplify_arg doesn't adjust it.

If you write:
struct Foo
{
  int line;
  Foo (int line = __builtin_LINE () + 1) : line (line) {}
};
int
main ()
{
  if (Foo().line != (new Foo)->line)
    __builtin_abort ();
}

then it will be in both cases the location of the Foo ctor, because the
argument will not be __builtin_LINE() CALL_EXPR as toplevel.

So, IMHO if you want a different behavior, you shouldn't leave this to the
gimplifier, but explicitly change it in the FE.  Say in convert_default_arg or
functions it calls change EXPR_LOCATION of all CALL_EXPRs to the 3 problematic
builtins (I'd argue that only those and nothing else, the expressions really
have locus of where the default argument has been defined and it is desirable
to use that for diagnostic purposes etc.).  convert_default_arg already walks
the expression several times through break_out_target_exprs, so if we e.g.
wanted to
avoid the cost of walking it once again, break_out_target_exprs could have a
flag to tweak location_t of __builtin_{LINE,FILE,FUNCTION}.  Jason, thoughts on
this?  In any case this needs to be documented.  What about other default
locations?  Say if e.g. NSDMI contains __builtin_LINE () call, do we want to
get a value of where the NSDMI is defined, or where the object is constructed?