[Cfp-interest] exploring __attribute__

[Jim Thomas]

Rajan is right. Here are the draft minutes from the WG 14 meeting of Oct 2009:

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

See item 4.12.

-Jim

On Jul 28, 2014, at 5:36 AM, Rajan Bhakta <rbhakta at us.ibm.com> wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20140728/00add733/attachment-0001.html