From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14975 invoked by alias); 7 Jun 2016 19:35:34 -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 14965 invoked by uid 89); 7 Jun 2016 19:35:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=prompted X-HELO: mail-qt0-f169.google.com Received: from mail-qt0-f169.google.com (HELO mail-qt0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 07 Jun 2016 19:35:32 +0000 Received: by mail-qt0-f169.google.com with SMTP id 23so24553384qtq.0 for ; Tue, 07 Jun 2016 12:35:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KWm3Q2mDWt40UklQYy47WeCB3Jux0G0vAfDFjZEVLmQ=; b=EvmZpb3CnLpU4/ETj2C9+wYJ36rAPj4cR9q5pN3XGKqqMymOncDVH7vosBSz3gG97s BU3CJsxvuCCOfaVoBmUHO4bwp7sJ3e+rN4+oE1XpdAkTR1Ii8hHLUJUW6bbvhrIap8Ex 1GhTkLJnrziXkurVpaqHu7E91+DAROy3ntRLWObu054B3v6JjTYCoYnEgGz+vS5IS6Jp Qtbo2lfPR2WNyfB2hQ6YQ5X09MZ0awhw7UTxlzAZY1pfLWNHnWDyk6vIUreo5WNph9PM df3ns0BfFYhdxHSOQdgpSZwD0c4cEtmKQ2/a37d21qqNPv37NqtzUONK8rxgrI94Jg1T Zr0Q== X-Gm-Message-State: ALyK8tIg8Oin0Bz7WyYm607RH4uncmpxFFofB2aPOqEX1MxqtPlus3Ci6g9mrJm5Bg+2I+9F X-Received: by 10.237.49.66 with SMTP id 60mr1169939qtg.103.1465328130604; Tue, 07 Jun 2016 12:35:30 -0700 (PDT) Received: from [192.168.1.50] (209-6-90-240.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com. [209.6.90.240]) by smtp.gmail.com with ESMTPSA id y186sm7486412qha.20.2016.06.07.12.35.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2016 12:35:29 -0700 (PDT) Subject: Re: [PATCH] integer overflow checking builtins in constant expressions To: Jakub Jelinek , Martin Sebor References: <20160602072316.GY28550@tucnak.redhat.com> <5750BF82.5030203@gmail.com> <5750CF25.1080801@gmail.com> <20160603070637.GA7387@tucnak.redhat.com> <5751A26C.1060201@gmail.com> <20160603153235.GK7387@tucnak.redhat.com> <5751E408.1010707@gmail.com> <20160606123617.GW7387@tucnak.redhat.com> <18c82043-baa5-8ae1-e551-70b3b8241056@redhat.com> <5756ED69.1030608@gmail.com> <20160607163414.GU7387@tucnak.redhat.com> Cc: Gcc Patch List , "Joseph S. Myers" From: Jason Merrill Message-ID: <4132a3c5-a210-7cf2-e9dd-8c645a71f23a@redhat.com> Date: Tue, 07 Jun 2016 19:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160607163414.GU7387@tucnak.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00514.txt.bz2 On 06/07/2016 12:34 PM, Jakub Jelinek wrote: > On Tue, Jun 07, 2016 at 09:51:05AM -0600, Martin Sebor wrote: >> On 06/07/2016 08:32 AM, Jason Merrill wrote: >>> On 06/06/2016 08:36 AM, Jakub Jelinek wrote: >>>> @@ -352,6 +352,35 @@ builtin_valid_in_constant_expr_p (const_ >>>> case BUILT_IN_FUNCTION: >>>> case BUILT_IN_LINE: >>>> >>>> + /* The following built-ins are valid in constant expressions >>>> + when their arguments are. */ >>>> + case BUILT_IN_ADD_OVERFLOW: >>>> + case BUILT_IN_ADD_OVERFLOW_P: >>> .... >>> >>> Why is this necessary? builtin_valid_in_constant_expr_p is only needed >>> for builtins that can have constant values even if their operands are >>> non-constant, which doesn't apply here. >>> >>> For that matter, I don't see why we needed to add _FUNCTION et al, either. >> >> I don't remember what prompted me to change the function in either >> patch. Perhaps it was the comment above the function that says >> this: >> >> /* Test whether DECL is a builtin that may appear in a >> constant-expression. */ >> >> But removing the change doesn't seem to affect the C++ test results >> for the two features so it looks like the change may not be needed. > > Indeed, confirming removal of the cp/tree.c hunk doesn't affect anything in > the testsuite, nor e.g. > enum A { > B = 1, > C = 2, > D = __builtin_add_overflow_p (B, C, C) > }; > int e[__builtin_add_overflow_p (B, C, C) + 1]; > template int foo (int); > void > bar () > { > foo <__builtin_add_overflow_p (B, C, C) + 1> (0); > } > That said, builtin_valid_in_constant_expr_p is used in lots of spots, and in > various of them I see that without the change it actually sets > *non_integral_constant_expression_p = true; > or something similar, but I have no idea why it still works despite of that. Ah, that's the C++98 constant expression handling, which is a lot more restricted. C++11 and up don't care about that flag. > Is the patch ok for trunk without the cp/tree.c hunk? Yes. Jason