<font size=2 face="sans-serif">Jim and Fred can probably tell you more
than I could, but when I joined the C committee, at that time I recall
hearing about the aversion to attribute syntax and instead the preference
for keywords (noreturn for example). I believe that was intended as the
strategic direction for C.</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
<br>
Rajan Bhakta<br>
z/OS XL C/C++ Compiler Technical Architect<br>
ISO C Standards Representative for Canada<br>
C Compiler Development<br>
Contact: rbhakta@us.ibm.com, Rajan Bhakta/Houston/IBM</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">David Hough CFP <pcfp@oakapple.net></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">cfp-interest@ucbtest.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">07/25/2014 06:20 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[Cfp-interest]
exploring __attribute__</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">cfp-interest-bounces@oakapple.net</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2><br>
I followed up on Ian's suggestion and expanded the syntax discussion to<br>
include __attribute__<br>
<br>
<br>
<br>
<br>
Syntax for Directives in C<br>
<br>
IEEE 754-2008 requests languages to define directives for specifying<br>
mandatory and permissible compilation attributes. An example
of the<br>
difference is a mandatory alternate exception handling <br>
directive to perform abrupt underflow handling, in contrast to<br>
a permissible optimization directive that allows using fast hardware modes
for<br>
handling underflowed results and subnormal operands if they exist.<br>
<br>
We've gotten some feedback that #pragma is not desirable syntax for mandatory<br>
directives, and that try/catch semantics that we need does not match well
enough<br>
to C++ try/catch. So that's an opportunity to step back and
think about<br>
what we really need.<br>
<br>
The basic #pragma conceptual syntax is<br>
<br>
{<br>
#pragma STDC PROPERTY value<br>
<br>
code<br>
}<br>
<br>
and the pragma affects all the code in the compound statement.<br>
There are already three such pragmas in standard C.<br>
<br>
#pragma STDC FP_CONTRACT on-off-switch<br>
#pragma STDC FENV_ACCESS on-off-switch<br>
#pragma STDC CX_LIMITED_RANGE on-off-switch<br>
<br>
Note that these pragmas <br>
<br>
can occur either outside external declarations<br>
or preceding all explicit declarations and statements inside a<br>
compound statement<br>
<br>
The catch/try syntax we considered was really just a syntactic<br>
transformation of a corresponding #pragma approach:<br>
<br>
try { <br>
code0<br>
}<br>
catch (FE_INVALID) {<br>
code1<br>
}<br>
<br>
is conceptually equivalent to<br>
<br>
{<br>
#pragma STDC FENV_EXCEPT FE_INVALID goto L1 <br>
code0<br>
goto L2;<br>
}<br>
L1:<br>
code1<br>
L2:<br>
<br>
The try/catch form is a little less verbose, but has the drawback that<br>
the exception list (FE_INVALID in this case) has to be known in order to<br>
compile code0, even though the exception list appears syntactically after<br>
the code that it modifies.<br>
<br>
The try/catch paradigm happens to correspond rather closely to the <br>
control-transfer variety of alternate exception handling, but not closely
to<br>
the value-substitution variety of alternate exception handling,<br>
nor to other kinds of compiler directives controlling optimizations.<br>
<br>
So perhaps we should consider something more general.<br>
Is there a more natural C-like syntax for specifying how a compound<br>
statement should be compiled?<br>
<br>
Another possible prototype comes from OpenMP 3.0:<br>
<br>
#pragma omp parallel [ clause[ [ , ]clause] ...] new-line<br>
structured-block<br>
<br>
where "structured-block" is defined as<br>
<br>
a single statement or a compound statement with a single entry<br>
at the top and a single exit at the bottom<br>
<br>
It's interesting that OpenMP puts the controlling #pragma before the<br>
compound statement, while FP_CONTRACT etc are within the compound statement.<br>
I'm not aware of a compelling compiler-implementation<br>
reason to do it one way or the other, but it<br>
might make more sense to do it consistently.<br>
<br>
<br>
Abstracting all this, we'd like to have a way of specifying attributes
<br>
for compound statements. Can we really do better than #pragma?<br>
Some attributes are requirements, others just suggestions.<br>
<br>
<br>
How about a general __attribute__ keyword that can attach to most any <br>
syntactic unit?<br>
Ian suggests this approach and lists the positives:<br>
<br>
- It's reasonably understandable.<br>
- It avoids new keywords that conflict with user names.<br>
- It avoids the objections to pragmas.<br>
- It can apply to any compound statement including loops and if statement
then or else clauses.<br>
- It handles substitution etc. not just trapping.<br>
- It can include non-floating-point exception handling.<br>
- It can include errno error handling.<br>
- It can include finally.<br>
- It (all, or the FP exception subset) could easily be added to C++.<br>
- Gcc / g++ users should like it.<br>
- It works with a one pass compiler.<br>
<br>
The main negative is that it lists the exceptional case before the normal
case,<br>
which is backwards for persons reading code,<br>
but it's a positive for one-pass compiler writers.<br>
<br>
I'd interpret it thus:<br>
<br>
__attribute__ (xyz) {<br>
code<br>
}<br>
<br>
as equivalent to what we've been writing as<br>
<br>
{<br>
#pragma STDC xyz<br>
code<br>
}<br>
<br>
where xyz might be very general:<br>
<br>
fe_catch_after(flaglist); code1
# test after execution<br>
fe_catch_asap(exceptionlist); code1
# catch asap<br>
fe_catch(exceptionlist); code1
# asap or after, implementation choice<br>
fe_sub(exceptionlist); code1
# code1 computes the substitute value<br>
fe_abrupt();
#
abrupt underflow<br>
<br>
It looks like a function invocation followed by general code1, but the
<br>
function names are really keywords; the general code1 would most likely
be<br>
pretty simple, typically a goto, for the fe_catch flavors.<br>
<br>
Our existing pragmas and other optimization and expression evaluation<br>
attributes could fit in as well:<br>
<br>
#pragma STDC FP_CONTRACT on-off-switch<br>
#pragma STDC FENV_ACCESS on-off-switch<br>
#pragma STDC CX_LIMITED_RANGE on-off-switch<br>
<br>
become e.g.<br>
<br>
__attribute__ (FP_CONTRACT(on)) {}<br>
or<br>
__attribute__ (FP_CONTRACT on) {}<br>
<br>
multiple attributes could be handled something like<br>
<br>
__attribute__ (attribute1) (attribute2) {<br>
<br>
Note that the GCC feature that inspires this line of thought<br>
has double parentheses around xyz:<br>
<br>
__attribute__ ((xyz)) <br>
<br>
no doubt for good reasons that I don't know about.<br>
And GCC __attribute__ doesn't apply to compound statements as I suggest;<br>
that idea comes from OpenCL.<br>
_______________________________________________<br>
Cfp-interest mailing list<br>
Cfp-interest@oakapple.net<br>
</font></tt><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><tt><font size=2>http://mailman.oakapple.net/mailman/listinfo/cfp-interest</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>