From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85757 invoked by alias); 12 May 2017 20:54:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 85748 invoked by uid 89); 12 May 2017 20:54:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=throwing, H*f:sk:nYnWTw@, Hx-languages-length:3061, H*f:sk:02f991c X-HELO: sasl.smtp.pobox.com Received: from pb-smtp1.pobox.com (HELO sasl.smtp.pobox.com) (64.147.108.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 May 2017 20:54:52 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 2B8DD6D0DE; Fri, 12 May 2017 16:54:52 -0400 (EDT) Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 23CF16D0DD; Fri, 12 May 2017 16:54:52 -0400 (EDT) Received: from [192.168.1.4] (unknown [76.215.41.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 3AE9B6D0DC; Fri, 12 May 2017 16:54:51 -0400 (EDT) Subject: Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates To: Joseph Myers , Jonathan Wakely References: <02f991c6-7679-9f9b-aa57-35a25e37acd9@pobox.com> <201705091529.53074.linux@carewolf.com> <58e1ace4-2285-3177-8939-2785c920b888@pobox.com> <96a739b4-3a74-3474-f501-1106b36d6543@pobox.com> Cc: Allan Sandfeld Jensen , "gcc@gcc.gnu.org" , Richard Henderson , Florian Weimer From: Daniel Santos Message-ID: <57c2e272-dc55-62a5-5984-382867468723@pobox.com> Date: Fri, 12 May 2017 20:54:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 3E62AB52-3755-11E7-A65A-EFB41968708C-06139138!pb-smtp1.pobox.com X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00119.txt.bz2 Sorry for my delayed response. On 05/11/2017 09:35 AM, Joseph Myers wrote: > On Thu, 11 May 2017, Jonathan Wakely wrote: > >> On 10 May 2017 at 23:14, Daniel Santos wrote: >>> Well my primary goal is programming with values that are constant in the >>> compiler. There is no language in any C specification (that I'm aware of) >>> for a "compile-time constant", but the concept is very important. So just >>> because some expression is a compile-time constant doesn't mean we morph >>> into a "constant expression" (as per the spec), even with >>> __attribute__((const)). >> The C standard says "An implementation may accept other forms of >> constant expressions." That means rather than inventing some >> "constprop" you could just extend GCC to treat more expressions >> involving constants as constant-expressions. I would rather not invent terms either. In regards to the proposed attribute name, I'm leaning towards re-using "const" instead of adding "constprop" because it seems to fall in line with the original purpose of the attribute while and there doesn't appear to be any overlap between what it currently applies to and what I would like to add the attribute to. But from a conceptual standpoint, I believe the term "constant-expression" would be incorrect because the C standard defines this constraint: (6.6.3 of C11) "Constant expressions shall not contain assignment, increment, decrement, function-call, or comma operators, except when they are contained within a subexpression that is not evaluated." I definitely do need to study the C specs more carefully to make sure I fully understand how this is used and how it's changed over different revisions of the spec. But from what I've done so far, I can tell that around 80-90% of what I hope to achieve will be through simply improving GCC's ability to to constant propagate (I'm focusing on one issue right now where it appears that early SRA might be throwing off later constant propagation). > Note that while "other forms" might be accepted in initializers, they > would still not be integer constant expressions (see DR#312). What is DR#312? I should probably be more careful and explicit in my language. I was thinking particularly of integer constant expressions that are required for the size of non-variable length arrays, bitfields, and such. If only for the sake of entertainment, there *is* actually a legitimate way to transform an expression into an integer constant expression and even an integer constant, but is only practical when the range of possible values is limited. #define foo (i) /* Do something here. */ #define bar (expr) \ do { \ ASSERT_CONST (expr); \ switch (expr) { \ case 1: foo(1); break; \ case 2: foo(2); break; \ case 4: foo(4); break; \ case 8: foo(8); break; \ case 16: foo(16); break; \ case 32: foo(32); break; \ case 64: foo(64); break; \ case 128: foo(128); break; \ case 256: foo(256); break; \ default: \ ASSERT (0); \ } \ } while (0) Daniel