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

[Daniel Santos <daniel.santos@pobox.com>]

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