From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20852 invoked by alias); 15 Jan 2014 16:16:58 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 20819 invoked by uid 48); 15 Jan 2014 16:16:52 -0000 From: "joerg.richter@pdv-fs.de" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/59739] missed optimization: attribute ((pure)) could be honored more often Date: Wed, 15 Jan 2014 16:16: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: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: joerg.richter@pdv-fs.de 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: In-Reply-To: References: 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-01/txt/msg01603.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59739 --- Comment #1 from J=C3=B6rg Richter --- 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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?id=59821 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org, | |jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- 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?