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.133.124]) by sourceware.org (Postfix) with ESMTPS id 8BA5D3858C60 for ; Thu, 3 Feb 2022 21:05:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8BA5D3858C60 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-344-InobCD1wOZauG7-ua2IJVg-1; Thu, 03 Feb 2022 16:05:00 -0500 X-MC-Unique: InobCD1wOZauG7-ua2IJVg-1 Received: by mail-qk1-f197.google.com with SMTP id i26-20020a05620a075a00b0047ec29823c0so2492878qki.6 for ; Thu, 03 Feb 2022 13:05:00 -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=U35KqI53yqLWQx/GoZHW7NbMdPl1W9N47v3syridBjM=; b=boTUpd8BWEK4zFlKi1q9DRNXqR5kaqWCrB5+r01ZO7758MzqsWhv4tC0cNBFH8TbIx KsOmU1jMZItJl5gXPc0wZAUrAuTbdDKhK+PYouAfT+0eeFzuT7a9/goSA0EZ+Gdm5RJw c6r14QAQYj0H+vlF/Pn8tJgseE+l3LrNiSXZMbbN8e60SR87V7SrHGf+ktsavHkYlLv/ PCEcVnHsA/WtdNQCuEux6Fgb/SKzXffHuw6gNFpwRtg8YlH9NKDlq2rol+P9dqb8M9be yGOaSAqvo3TXAraC0zrxAi6RKnWvok8xgYGtvPyurzeL7SqB2meJUTCII9gKEG4Lza2z 60mg== X-Gm-Message-State: AOAM532aZCwSlA8InEsNoqqvaUClZsc7bLaOIoqM4OV7Fc/xqqdpaS0T Qa+h8veJMkHYopIlm6i5rEuVQAS1QszQWMFKKFEzKNYf1s2LyjDgtvZ+1H2U5w/8Q/qHdyprDh1 k8RIhNpmxnnXgLh42Aw== X-Received: by 2002:ad4:4ee9:: with SMTP id dv9mr31923729qvb.47.1643922299694; Thu, 03 Feb 2022 13:04:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJw3gUDZBKarxPBzOqv82f2ILaCrOinbcDRevMRqGaO8NcDAFYgWf9IRRSGuVR3fCe9h35uFog== X-Received: by 2002:ad4:4ee9:: with SMTP id dv9mr31923703qvb.47.1643922299335; Thu, 03 Feb 2022 13:04:59 -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 w22sm14155qtk.7.2022.02.03.13.04.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Feb 2022 13:04:58 -0800 (PST) Message-ID: <14f595e5-6158-6305-ef50-ac8d5f2b3c87@redhat.com> Date: Thu, 3 Feb 2022 16:04:57 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH] c++, v2: Further address_compare fixes [PR89074] To: Jakub Jelinek Cc: Richard Biener , gcc-patches@gcc.gnu.org References: <20220106092416.GX2646553@tucnak> <494ae254-aff9-8be9-1cee-5ee42b6db593@redhat.com> <20220118101741.GW2646553@tucnak> <841aeb56-57a3-07b3-dbc0-a45ef0cca554@redhat.com> <20220118164048.GD2646553@tucnak> <20220203155237.GR2646553@tucnak> <191d40b7-9de1-879b-2a39-8b26c869c955@redhat.com> <20220203203320.GV2646553@tucnak> From: Jason Merrill In-Reply-To: <20220203203320.GV2646553@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=-6.9 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, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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: Thu, 03 Feb 2022 21:05:02 -0000 On 2/3/22 15:33, Jakub Jelinek wrote: > On Thu, Feb 03, 2022 at 03:07:03PM -0500, Jason Merrill wrote: >>> --- gcc/fold-const.h.jj 2022-02-01 20:10:51.235856007 +0100 >>> +++ gcc/fold-const.h 2022-02-03 15:02:02.700228631 +0100 >>> -/* Non-zero if we are folding constants inside an initializer; zero >>> - otherwise. */ >>> +/* Nonzero if we are folding constants inside an initializer or a C++ >>> + manifestly-constant-evaluated context; zero otherwise. >>> + Should be used when folding in initializer enables additional >>> + optimizations. */ >>> extern int folding_initializer; >>> +/* Nonzer of we are folding C++ manifestly-constant-evaluated context; zero >> >> "Nonzero if" > > Oops, thanks for catching it. > >>> + if (!folding_cxx_constexpr >>> + && ((DECL_P (base0) && TREE_CODE (base1) == STRING_CST) >>> + || (TREE_CODE (base0) == STRING_CST && DECL_P (base1)) >>> + || (TREE_CODE (base0) == STRING_CST >>> + && TREE_CODE (base1) == STRING_CST >>> + && ioff0 >= 0 && ioff1 >= 0 >>> + && ioff0 < TREE_STRING_LENGTH (base0) >>> + && ioff1 < TREE_STRING_LENGTH (base1) >>> + /* This is a too conservative test that the STRING_CSTs >>> + will not end up being string-merged. */ >>> + && strncmp (TREE_STRING_POINTER (base0) + ioff0, >>> + TREE_STRING_POINTER (base1) + ioff1, >>> + MIN (TREE_STRING_LENGTH (base0) - ioff0, >>> + TREE_STRING_LENGTH (base1) - ioff1)) != 0))) >>> ; >>> - else if (!DECL_P (base0) || !DECL_P (base1)) >>> + /* Punt on non-zero offsets from functions. */ >>> + else if ((TREE_CODE (base0) == FUNCTION_DECL && ioff0) >>> + || (TREE_CODE (base1) == FUNCTION_DECL && ioff1)) >>> + return 2; >>> + else if ((!DECL_P (base0) >>> + && (!folding_cxx_constexpr || TREE_CODE (base0) != STRING_CST)) >>> + || (!DECL_P (base1) >>> + && (!folding_cxx_constexpr || TREE_CODE (base1) != STRING_CST))) >> >> I think it would be clearer to leave the !DECL_P case alone and add >> >> /* In C++ it is unspecified, and so non-constant, whether two >> equivalent strings have the same address. */ >> else if (folding_cxx_constexpr >> && (TREE_CODE (base0) == STRING_CST >> || TREE_CODE (base1) == STRING_CST) > > The point was to let the first if handle for > !folding_cxx_constexpr the cases with STRING_CST > as one or both operands and if that falls through, return 2. Ah, I see. And then for folding_cxx_constexpr you have your new code toward the bottom of the function that can say they're unequal in some cases. Can you combine the STRING_CST handling for both values of folding_cxx_constexpr instead of having them so far apart? Jason