From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id BB645385781F for ; Mon, 29 Nov 2021 22:45:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BB645385781F Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-597-JvHVzAAcNqmRKBDy4fk70w-1; Mon, 29 Nov 2021 17:45:14 -0500 X-MC-Unique: JvHVzAAcNqmRKBDy4fk70w-1 Received: by mail-qv1-f72.google.com with SMTP id n4-20020a0ce944000000b003bdcabf4cdfso26920588qvo.16 for ; Mon, 29 Nov 2021 14:45:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=SkhdkWKh2C7V4E7rM7+9AKJqsC+H9r5tCntzB/tadAE=; b=r7C3Pyx7Ol11TQVB/tiwhHME97NwXd1ed2+AVhjRBAXfPmgphVi1CEIvCYL5gGb0A/ kSSqXysuOjZFttPv/vy3GhM/AIreirVfiRJNKpu1NzyX5aASc5F64gNhEDbYw09olQGI 75Iv2fjL8Q8eaQaTgOz7Bcxk/uY5GmVQwWDFlv/E7P2CWSub36I+rRDokajwOstvmOoc L8QhyeQMJkAKdd8wRyb0KJTibNNQ31/UWeS/y8m4zCSt1wFzLNPQOzthcYiH3pIFwZKp 2LGjTnnDPwDCzyOV3gWxsttyNMb+yzq3rc4RI6ivp8hLdmR650eKgIH9YNVcxZx1pkMy ME0Q== X-Gm-Message-State: AOAM533Vig6v/lcQvTFau31lRIUWiuZDoCZYNwO67KOCkYwm8YV0zFcz 46BeidpzJHghnz8eA0gVtivRkH4JpUSlsdFAn17erqPD6bnJ2JdTfBUtxF0PpX7WToJ830hzUIt 8vPjQKl/2OzVVvK3kQw== X-Received: by 2002:ac8:674a:: with SMTP id n10mr46267279qtp.145.1638225913217; Mon, 29 Nov 2021 14:45:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJwKcR75tuNtKHmlvy21FlJ3ThZ++2pZxlB8XXYwYx2hQRJK4H5AbwFWVEwBoTlmTuyiLHQ+vw== X-Received: by 2002:ac8:674a:: with SMTP id n10mr46267265qtp.145.1638225912978; Mon, 29 Nov 2021 14:45:12 -0800 (PST) Received: from [192.168.1.149] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id w13sm9461383qko.20.2021.11.29.14.45.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Nov 2021 14:45:12 -0800 (PST) Message-ID: <4777e810-57f1-ac81-6c08-a496a4cc015a@redhat.com> Date: Mon, 29 Nov 2021 17:45:11 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [PATCH] c++: Small incremental tweak to source_location::current() folding To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org References: <20211019120021.GL304296@tucnak> <20211021111742.GG304296@tucnak> <20211029152444.GB304296@tucnak> <1f3b346d-2d4e-a4f1-15ef-b536a162a7e6@redhat.com> <20211124160203.GO2646553@tucnak> <20211124180257.GP2646553@tucnak> <6b01cee0-91b2-7292-c95e-c774fc426eb4@redhat.com> <20211124224228.GV2646553@tucnak> <20211127085212.GT2646553@tucnak> From: Jason Merrill In-Reply-To: <20211127085212.GT2646553@tucnak> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2021 22:45:17 -0000 On 11/27/21 03:52, Jakub Jelinek wrote: > On Wed, Nov 24, 2021 at 11:42:28PM +0100, Jakub Jelinek via Gcc-patches wrote: >>> I'm surprised the source_location::current handling would be needed; why do >>> calls to that function live long enough for us to walk into the ADDR_EXPR >>> here? Maybe we should fold it in cp_fold instead of cp_genericize_r. > > I've already committed the patch, but perhaps we shouldn't do it in cp_fold > where it will be folded even for warnings etc. and the locations might not > be the final yet. This patch moves it to cp_fold_r so that it is done just > once for each function and just once for each static initializer. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. > 2021-11-27 Jakub Jelinek > > * cp-gimplify.c (cp_fold_r): Perform folding of > std::source_location::current() calls here... > (cp_fold): ... rather than here. > > --- gcc/cp/cp-gimplify.c.jj 2021-11-26 10:10:53.227121384 +0100 > +++ gcc/cp/cp-gimplify.c 2021-11-26 11:51:50.945204127 +0100 > @@ -930,6 +930,13 @@ cp_fold_r (tree *stmt_p, int *walk_subtr > } > break; > > + case CALL_EXPR: > + if (tree fndecl = cp_get_callee_fndecl_nofold (stmt)) > + if (DECL_IMMEDIATE_FUNCTION_P (fndecl) > + && source_location_current_p (fndecl)) > + *stmt_p = stmt = cxx_constant_value (stmt); > + break; > + > default: > break; > } > @@ -2672,14 +2679,6 @@ cp_fold (tree x) > int sv = optimize, nw = sv; > tree callee = get_callee_fndecl (x); > > - if (tree fndecl = cp_get_callee_fndecl_nofold (x)) > - if (DECL_IMMEDIATE_FUNCTION_P (fndecl) > - && source_location_current_p (fndecl)) > - { > - x = cxx_constant_value (x); > - break; > - } > - > /* Some built-in function calls will be evaluated at compile-time in > fold (). Set optimize to 1 when folding __builtin_constant_p inside > a constexpr function so that fold_builtin_1 doesn't fold it to 0. */ > > > Jakub >