From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89398 invoked by alias); 9 May 2017 13:29:58 -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 88792 invoked by uid 89); 9 May 2017 13:29:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_PASS autolearn=ham version=3.3.2 spammy=excuse, H*f:sk:02f991c X-HELO: mail-lf0-f68.google.com Received: from mail-lf0-f68.google.com (HELO mail-lf0-f68.google.com) (209.85.215.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 May 2017 13:29:55 +0000 Received: by mail-lf0-f68.google.com with SMTP id h4so3798999lfj.3 for ; Tue, 09 May 2017 06:29:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-transfer-encoding :message-id; bh=iR4eIFqSyhR7mvjRdZCOHgIWeFk/wXMOB7y4f8SZcu0=; b=RqFidiNJC0wJzQcfy9H8TzBOTjvdeaCYUsnRDNShMUv1w2ww1x4BnFnSjFbO2FiIwL 5Wvq6hEMFhg920DnW+xPVV6UzPjsLj1aDczLAQJI5+EaLKLPumotRb6IeKw9Bf6zxcoy kRkTJC4ozRjPMgAYA61wulFX+DlXzyzVaGY1mwaaTxpCujEgdIkL1tsklJD7Yj69HqDg m7TaUmMjC5ra5smH5k3DsKRmX+QYj0tLCuIVrAo1Fqss12SYj1pEer6n3lHUdmPX51KA EFLh9Kwy6nTG7gSnsPlyP3V5tXrJsgh8feKjEo+bwvSp8Xyo9A9Vm0LH6ZwejwFQg3wu BoLQ== X-Gm-Message-State: AODbwcCK3f21XaCVzvLgVjXw5KoDoGGxHAy7JcaarkD7NoE8xSX1DG3l WyCftdWEMywklybZ X-Received: by 10.25.162.211 with SMTP id l202mr12820lfe.147.1494336595625; Tue, 09 May 2017 06:29:55 -0700 (PDT) Received: from princessluna.localnet ([62.220.2.194]) by smtp.gmail.com with ESMTPSA id h74sm1021742ljh.21.2017.05.09.06.29.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 May 2017 06:29:54 -0700 (PDT) From: Allan Sandfeld Jensen To: gcc@gcc.gnu.org Subject: Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates Date: Tue, 09 May 2017 13:29:00 -0000 User-Agent: KMail/1.13.7 (Linux/4.10.0-14.1-liquorix-amd64; KDE/4.14.27; x86_64; ; ) Cc: Daniel Santos , Joseph Myers , Richard Henderson References: <02f991c6-7679-9f9b-aa57-35a25e37acd9@pobox.com> In-Reply-To: <02f991c6-7679-9f9b-aa57-35a25e37acd9@pobox.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201705091529.53074.linux@carewolf.com> X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00085.txt.bz2 On Tuesday 09 May 2017, Daniel Santos wrote: > The primary aim is to facilitate high-performance generic C > libraries for software where C++ is not suitable, but the cost of > run-time abstraction is unacceptable. A good example is the Linux > kernel, where the source tree is littered with more than 100 hand-coded > or boiler-plate (copy, paste and edit) search cores required to use the > red-black tree library. That is not a good excuse, they can just use a defined subset of C++. The cost of C++ abstractions is zero if you don't use them. > > 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. > This I can get more behind, I have wanted a constexpr attribute for C for some time. If not for anything else to be able to use it in shared/system headers that can be used by both C and C++ and in C++ would be useful in constexpr expressions. If you can find a use for it in pure C as well, so much the better. `Allan