[RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Daniel Santos]

I would like to make some changes in GCC 8, so I thought that formal 
proposal and RFC would be the best path. I'm still relatively new to the 
GCC project.

I began experimenting with C metaprogramming techniques back in 2012, in 
order to implement more efficient generic libraries in C. The code is 
ANSI C compliant and can build anywhere, but exploits GCC attributes, 
checks and optimizations (when available) to assure optimal efficiency. 
The underlying mechanisms involve the exploitation of constant 
propagation and -findirect-inline to cause an inline function to behave 
similar to a C++ templatized function that is instantiated at the call 
site. 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.

Here is a brief example of a simplified qsort algo:

/* A header file for a generic qsort library.  */

struct qsort_def {
     size_t size;
     size_t align;
     int (*less_r)(const void *a, const void *b, void *context);
};

inline __attribute__((always_inline, flatten)) void
qsort_template(const struct qsort_def *def, void *const pbase, size_t n,
	       void *context)
{
   /* details omitted... */
}

/* An implementation file using qsort.  */

static inline my_less_r (const void *a, const void *b, void *context)
{
   const struct my_struct *_a = a;
   const struct my_struct *_b = b;

   return _a->somefield < _b->somefield;
}

static const struct qsort_def my_qsort_def = {
     .size   = sizeof (struct my_struct),
     .align  = 16,
     .less_r = my_less_r,
};

void __attribute__((flatten)) my_sort (struct my_struct *o, size_t n)
{
   qsort_template (&my_qsort_def, o, n);
}


The purpose of the "my_sort" wrapper function is to contain the template 
expansion. Beginning with GCC 4.4, when qsort_template inline expansion 
occurs, the entire struct qsort_def is compiled away. The "my_less_r" 
function is inlined, and by using __builtin_assume_aligned(), all 
manipulation of data is performed with the best available instructions 
and unneeded memcpy alignment pro/epilogues are omitted. This results in 
code that's both faster and smaller and is analogous in form and 
performance to C++'s std::sort, except that we are using the first 
parameter (const struct qsort_def *def) in lieu of formalized template 
parameters.

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 will enable the use of pseudo-templates and:

1.) Eliminate the need for __attribute__((always_inline, flatten)) and 
complicated ASSERT_CONST() macros,
2.) Eliminate the need for an __attribute__((flatten) wrapper function,
3.) Reduce the need for the programmer to think about what the compiler 
is doing, and
4.) Allow gcc to decide rather inlining or cloning is better.

While not as powerful as C++ template metapgramming (type programming), 
there are certainly many more possibilities that haven't yet been 
discovered. I would like to be able to put something in GCC 8. Below is 
my current progress.

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index f2a88e147ba..5ec7b615e24 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -139,6 +139,7 @@ static tree handle_bnd_variable_size_attribute (tree *, tree, tree, int, bool *)
  static tree handle_bnd_legacy (tree *, tree, tree, int, bool *);
  static tree handle_bnd_instrument (tree *, tree, tree, int, bool *);
  static tree handle_fallthrough_attribute (tree *, tree, tree, int, bool *);
+static tree handle_constprop_attribute (tree *, tree , tree , int , bool *);
  
  /* Table of machine-independent attributes common to all C-like languages.
  
@@ -345,6 +346,8 @@ const struct attribute_spec c_common_attribute_table[] =
  			      handle_bnd_instrument, false },
    { "fallthrough",	      0, 0, false, false, false,
  			      handle_fallthrough_attribute, false },
+  { "constprop",                 0, 0, false, false, false,
+			      handle_constprop_attribute, false },
    { NULL,                     0, 0, false, false, false, NULL, false }
  };
  
@@ -3173,3 +3176,15 @@ handle_fallthrough_attribute (tree *, tree name, tree, int,
    *no_add_attrs = true;
    return NULL_TREE;
  }
+
+static tree
+handle_constprop_attribute (tree *node, tree name, tree ARG_UNUSED (args),
+			    int flags, bool *no_add_attrs)
+{
+  if (!DECL_P (*node) || !(VAR_P (*node) || TREE_CODE (*node) == PARM_DECL))
+    {
+      warning (OPT_Wattributes, "%qE attribute ignored", name);
+      *no_add_attrs = true;
+    }
+  return NULL_TREE;
+}
diff --git a/gcc/common.opt b/gcc/common.opt
index 4021622cf5c..93dd10e0771 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -557,6 +557,10 @@ Wcast-align
  Common Var(warn_cast_align) Warning
  Warn about pointer casts which increase alignment.
  
+Wconstprop
+Common Var(warn_constprop) Warning
+Warn when an __attribute__((constprop)) fails to constant-propagate away.
+
  Wcpp
  Common Var(warn_cpp) Init(1) Warning
  Warn when a #warning directive is encountered.
diff --git a/gcc/expr.c b/gcc/expr.c
index 29ebad3a061..c8aba05a76e 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -9717,6 +9717,16 @@ expand_expr_real_1 (tree exp, rtx target, machine_mode tmode,
        }
  
      case SSA_NAME:
+      {
+	tree var = SSA_NAME_VAR (exp);
+	/* TODO: Don't repeat warning for same declaration.  */
+	if (var && lookup_attribute ("constprop", DECL_ATTRIBUTES (var)))
+	  {
+	    warning (OPT_Wconstprop, "Expression %q+D is not constant in this context", var);
+	    /* TODO: Set something so we don't repeat this warning.  */
+	  }
+      }
+
        /* ??? ivopts calls expander, without any preparation from
           out-of-ssa.  So fake instructions as if this was an access to the
  	 base variable.  This unnecessarily allocates a pseudo, see how we can


Comments, objections, suggestions?

Thanks,
Daniel

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Florian Weimer]

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

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Daniel Santos]

Thanks for your feedback!

On 05/09/2017 04:36 AM, Florian Weimer wrote:
> 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.

What optimizations are enabled also effects it.  In 2012, I made a test 
program and scripted it to run on GCC versions 3.4.6 to 4.7.0 to map out 
what __builtin_constant_p() was able to resolve and put it all in a 
database.  Most of them started working between 4.2 and 4.4.  I put it 
into a spreadsheet for better analysis.

Anyway, I wasn't aware that it could vary across architectures. What I'm 
doing so far is only in the tree and I'm doing the checks as we're 
emitting RTL.

> There are also thorny specification issues, like is an array whose 
> length is a constprop value a VLA or not?

This is probably a worthwhile thought.  I wasn't actually thinking of 
specification-breaking changes, so it would be a VLA and value declared 
with __attribute__((constprop)) would just be like an optimization hint 
(like __builtin_expect) that could also notify you when you're request 
couldn't be fulfilled.

In the past, I have considered the merits of some type of 
__builtin_constexpr() to do just that, returning a value that can be 
treated as a C "constant expression" (as per the language spec.), to be 
used as a static initializer or fixed-size array length specifier.  The 
lack of such a mechanism is why the Linux kernel still resorts to 
compile-time checks using a negative-sized bitfields to signal failure 
(http://elixir.free-electrons.com/linux/latest/source/include/linux/bug.h#L37). 
I would have to do a lot more research to fully understand the issues 
and implications of that.

> If you are interested in metaprogramming techniques, you are probably 
> better off writing code generators or using a C++ subset.
>
> Thanks,
> Florian

Yeah, somehow I got myself interested in this unexploited avenue. It 
seems that more progressive programmers are of the mindset to just use 
C++, but system-level programmers tend to be wary of such magicks and 
often shun "dead-code trickery".

Thanks,
Daniel

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Allan Sandfeld Jensen]

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

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Daniel Santos]

Thanks for your feedback!

On 05/09/2017 08:29 AM, Allan Sandfeld Jensen wrote:
> 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.

Put simply, there are many projects who will not likely be converting to 
C++ in the in our lifetimes.  As far as abstractions, I meant the 
abstraction penalty of static types which doesn't exist when using C++ 
templates (not at run-time anyway).  In C, generic libraries typically 
resolve abstract behavior with a callback function pointer.  This costs 
a function call in addition to the optimization barrier of the function 
call (which is the worst part of it).

>> 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

Maybe "constexpr" would be a better name, as it mirrors the C++11 
keyword.  When I first read about C++ getting constexpr, my first 
thought was, "Yeah, as if they needed yet another way to do 
metaprogramming!" :)  However, I hadn't gone so far as to investigate 
using this new attribute on functions since we already have 
__attribute__((const)).  I haven't used this before so maybe I'm not 
aware of something that makes it unusable for such cases? Which of 
course raises the question if __attribute__((const)) would work out 
since it's only currently used on function declarations (and pointers to 
function declarations, but I don't fully understand what that is doing 
in handle_const_attribute).

Thanks,
Daniel

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Jonathan Wakely]

On 10 May 2017 at 10:17, Daniel Santos wrote:
> Maybe "constexpr" would be a better name, as it mirrors the C++11 keyword.
> When I first read about C++ getting constexpr, my first thought was, "Yeah,
> as if they needed yet another way to do metaprogramming!" :)  However, I

Because writing functions in normal C++ is much simpler and more
expressive than writing class templates and recursive partial
specializations.

Just because there's already one way to do something doesn't mean
better ways to do it are bad.


> hadn't gone so far as to investigate using this new attribute on functions
> since we already have __attribute__((const)).  I haven't used this before so
> maybe I'm not aware of something that makes it unusable for such cases?
> Which of course raises the question if __attribute__((const)) would work out
> since it's only currently used on function declarations (and pointers to
> function declarations, but I don't fully understand what that is doing in
> handle_const_attribute).

__attribute__((const)) is not a substitute for constexpr, it's not
even in the same ballpark. It says the function doesn't touch global
memory, it doesn't mean its return value is a constant expression, so
you can't do:

int f() __attribute__((const));
int f() { return 1; }
int i[f()];

I don't think __attribute__((const)) is useful for your goal.

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Daniel Santos]

On 05/10/2017 04:24 AM, Jonathan Wakely wrote:
> Just because there's already one way to do something doesn't mean
> better ways to do it are bad.

I'm only speaking out of jealousy being that most of my recent work has 
been in C.

>> hadn't gone so far as to investigate using this new attribute on functions
>> since we already have __attribute__((const)).  I haven't used this before so
>> maybe I'm not aware of something that makes it unusable for such cases?
>> Which of course raises the question if __attribute__((const)) would work out
>> since it's only currently used on function declarations (and pointers to
>> function declarations, but I don't fully understand what that is doing in
>> handle_const_attribute).
> __attribute__((const)) is not a substitute for constexpr, it's not
> even in the same ballpark. It says the function doesn't touch global
> memory, it doesn't mean its return value is a constant expression, so
> you can't do:
>
> int f() __attribute__((const));
> int f() { return 1; }
> int i[f()];
>
> I don't think __attribute__((const)) is useful for your goal.

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)).

Perhaps I can separate this project into two stages: a const/constprop 
and a constexpr.  The first stage behaves as little more than a 
collection of optimizer hints, extra warnings/errors and fixes to some 
missed optimization opportunities, while the second implements a 
constexpr for C.  The first stage should lay a lot of the framework for 
the second, but the second probably deserves a formal specification (and 
I will certainly have to read up on changes in C++14 and 17 that I'm 
behind on).  I can state the rationale for the "const" or "constprop" 
portion of this, but before adding a constexpr to C, I think a good 
rationale should be written up and examined as well.  I am in support of 
this as I've encountered many areas where I saw it could be useful -- 
use in combination with GCC ({ statement expressions }) particularly 
comes to mind.

I still have a lot to learn about the cgraph and I know next to nothing 
about how profile guided optimization works, but an ideal implementation 
of a const/constprop attribute should include a mechanism (perhaps via 
-fopt-info?) to inform the programmer when it turns out that their 
optimization hint don't look like such a good idea. :)

I appreciate everybody's feedback!  Thoughts?

Also, still a bit new to GCC, am I missing any formal steps that should 
be taken prior to pursuing such changes?

Thanks,
Daniel

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Jonathan Wakely]

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.

There are enhancement requests for this in Bugzilla, because some
compilers are already more catholic in what they accept in constant
expressions (notably, Clang).

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Marek Polacek]

On Thu, May 11, 2017 at 11:12:24AM +0100, 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.
> 
> There are enhancement requests for this in Bugzilla, because some
> compilers are already more catholic in what they accept in constant
> expressions (notably, Clang).

Right, at least:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618

	Marek

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Joseph Myers]

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.

Note that while "other forms" might be accepted in initializers, they 
would still not be integer constant expressions (see DR#312).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Daniel Santos]

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

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Joseph Myers]

On Fri, 12 May 2017, Daniel Santos wrote:

> > 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?

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_312.htm

(but cf the older 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_032.html against C90).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Vincent Lefevre]

On 2017-05-12 15:59:44 -0500, Daniel Santos wrote:
> [...] 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.

GCC already regards some function calls are acceptable in
constant expressions, when builtins are used, e.g. fabs (2.0),
contrary to Clang. The builtin is even used when <math.h> is
not included (note that Clang has the same behavior here). So,
there may be several issues. I've reported:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80756

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Martin Sebor]

On 05/10/2017 04:14 PM, Daniel Santos wrote:
> On 05/10/2017 04:24 AM, Jonathan Wakely wrote:
>> Just because there's already one way to do something doesn't mean
>> better ways to do it are bad.
>
> I'm only speaking out of jealousy being that most of my recent work has
> been in C.
>
>>> hadn't gone so far as to investigate using this new attribute on
>>> functions
>>> since we already have __attribute__((const)).  I haven't used this
>>> before so
>>> maybe I'm not aware of something that makes it unusable for such cases?
>>> Which of course raises the question if __attribute__((const)) would
>>> work out
>>> since it's only currently used on function declarations (and pointers to
>>> function declarations, but I don't fully understand what that is
>>> doing in
>>> handle_const_attribute).
>> __attribute__((const)) is not a substitute for constexpr, it's not
>> even in the same ballpark. It says the function doesn't touch global
>> memory, it doesn't mean its return value is a constant expression, so
>> you can't do:
>>
>> int f() __attribute__((const));
>> int f() { return 1; }
>> int i[f()];
>>
>> I don't think __attribute__((const)) is useful for your goal.
>
> 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 committee has discussed extending the set of expressions
that are considered constant in C2X.  A proposal was submitted
last year that, at least in spirit, gained pretty broad support
(the finer details, including the syntax, especially the reuse
of the register keyword, are likely to evolve):

   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2067.pdf

The C committee's charter for C2X is to increase compatibility
with C++, so new language features with that effect have a good
chance of being considered.

I don't expect C2X to go as far as to add something as complex
as templates but some on the committee are working on enhancing
support for generic programming (via _Generic).  Interestingly,
C11 (by accident) introduced a requirement for implementations
to support true type genericity in the form of the C11 atomic
APIs.  It may not be too far out there to propose to generalize
the underlying machinery and make it available to programs (as
opposed to just the standard library alone).

Martin

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Daniel Santos]

On 05/12/2017 10:49 AM, Martin Sebor wrote:
> On 05/10/2017 04:14 PM, 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 committee has discussed extending the set of expressions
> that are considered constant in C2X.  A proposal was submitted
> last year that, at least in spirit, gained pretty broad support
> (the finer details, including the syntax, especially the reuse
> of the register keyword, are likely to evolve):
>
>   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2067.pdf
>
> The C committee's charter for C2X is to increase compatibility
> with C++, so new language features with that effect have a good
> chance of being considered.
>
> I don't expect C2X to go as far as to add something as complex
> as templates but some on the committee are working on enhancing
> support for generic programming (via _Generic).  Interestingly,
> C11 (by accident) introduced a requirement for implementations
> to support true type genericity in the form of the C11 atomic
> APIs.  It may not be too far out there to propose to generalize
> the underlying machinery and make it available to programs (as
> opposed to just the standard library alone).
>
> Martin

Thank you for this!  It sounds like I need to read up on what is in the 
works with the C committee and maybe prepare my own proposal and become 
involved.  I see the monetary cost of not having generic support as very 
high -- you end up with more boiler-plate code that has to be 
maintained, thus increasing development time and the chance for bugs.  
It also takes more time to analyze the code, diagnose problems and get 
new programmers up to speed.

Thanks,
Daniel