From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59925 invoked by alias); 6 Sep 2019 02:25:08 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 59656 invoked by uid 89); 6 Sep 2019 02:25:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=strips, sad, HX-Languages-Length:2302 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Sep 2019 02:24:59 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7A98C3086218; Fri, 6 Sep 2019 02:24:58 +0000 (UTC) Received: from redhat.com (ovpn-126-230.rdu2.redhat.com [10.10.126.230]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AB8F21001947; Fri, 6 Sep 2019 02:24:57 +0000 (UTC) Date: Fri, 06 Sep 2019 02:25:00 -0000 From: Marek Polacek To: GCC Patches , Jason Merrill , David Malcolm , Nathan Sidwell Subject: C++ PATCH for c++/91678 - wrong error with decltype and location wrapper Message-ID: <20190906022455.GC14737@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) X-SW-Source: 2019-09/txt/msg00330.txt.bz2 Compiling this testcase results in a bogus "invalid cast" error; this occurs since the introduction of location wrappers in finish_id_expression. Here we are parsing the decltype expression via cp_parser_decltype_expr which can lead to calling various fold_* and c-family routines. They use non_lvalue_loc, but that won't create a NON_LVALUE_EXPR wrapper around a location wrapper. So before the location wrappers addition cp_parser_decltype_expr would return NON_LVALUE_EXPR . Now it returns VIEW_CONVERT_EXPR(c), but the STRIP_ANY_LOCATION_WRAPPER immediately following it strips the location wrapper, and suddenly we don't know whether we have an lvalue anymore. And that's sad because then decltype produces the wrong type, causing nonsense errors. Bootstrapped/regtested on x86_64-linux, ok for trunk and 9? 2019-09-05 Marek Polacek PR c++/91678 - wrong error with decltype and location wrapper. * parser.c (cp_parser_decltype): Use auto_suppress_location_wrappers sentinel. Don't strip location wrappers. * g++.dg/cpp0x/decltype73.C: New test. diff --git gcc/cp/parser.c gcc/cp/parser.c index baa60b8834e..b3c7bff5988 100644 --- gcc/cp/parser.c +++ gcc/cp/parser.c @@ -14729,8 +14729,13 @@ cp_parser_decltype (cp_parser *parser) /* Do not warn about problems with the expression. */ ++c_inhibit_evaluation_warnings; + /* Don't create wrapper nodes within decltype. non_lvalue_loc won't + create a NON_LVALUE_EXPR wrapper around a location wrapper, and a + subsequent STRIP_ANY_LOCATION_WRAPPER would destroy the information + about lvalueness of the expression. */ + auto_suppress_location_wrappers sentinel; + expr = cp_parser_decltype_expr (parser, id_expression_or_member_access_p); - STRIP_ANY_LOCATION_WRAPPER (expr); /* Go back to evaluating expressions. */ --cp_unevaluated_operand; diff --git gcc/testsuite/g++.dg/cpp0x/decltype73.C gcc/testsuite/g++.dg/cpp0x/decltype73.C new file mode 100644 index 00000000000..cbe94a898e3 --- /dev/null +++ gcc/testsuite/g++.dg/cpp0x/decltype73.C @@ -0,0 +1,4 @@ +// PR c++/91678 - wrong error with decltype and location wrapper. +// { dg-do compile { target c++11 } } + +float* test(float* c) { return (decltype(c + 0))(float*)c; }