From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51464 invoked by alias); 9 May 2017 09:36:34 -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 51435 invoked by uid 89); 9 May 2017 09:36:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=thorny 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; Tue, 09 May 2017 09:36:32 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E9C43C059730; Tue, 9 May 2017 09:36:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E9C43C059730 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E9C43C059730 Received: from oldenburg.str.redhat.com (ovpn-117-246.ams2.redhat.com [10.36.117.246]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E04BD17538; Tue, 9 May 2017 09:36:32 +0000 (UTC) Subject: Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates To: Daniel Santos , gcc , Joseph Myers , Richard Henderson References: <02f991c6-7679-9f9b-aa57-35a25e37acd9@pobox.com> From: Florian Weimer Message-ID: <838134a2-15f4-cd12-f098-378dbbeae75b@redhat.com> Date: Tue, 09 May 2017 09:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <02f991c6-7679-9f9b-aa57-35a25e37acd9@pobox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00084.txt.bz2 On 05/09/2017 01:36 AM, Daniel Santos wrote: > To further the usefulness of such techniques, I propose the addition of > a c-family attribute to declare a parameter, variable (and possibly > other declarations) as "constprop" or some similar word. The purpose of > the attribute is to: > > 1.) Emit a warning or error when the value is not optimized away, and > 2.) Direct various optimization passes to prefer (or force) either > cloning or inlining of a function with such a parameter. I think GCC used to treat C and C++ constant expressions this way in the old days. That is, what was a constant expression depended to some degree on the capabilities of the folder at least (and maybe the optimizers). This wasn't such a great idea because it made behavior inconsistent across architectures and GCC versions. There are also thorny specification issues, like is an array whose length is a constprop value a VLA or not? If you are interested in metaprogramming techniques, you are probably better off writing code generators or using a C++ subset. Thanks, Florian