[ET Trac] [Einstein Toolkit] #1379: Rename autoconfigured CCTK_BUILTIN functions to __builtin

[Einstein Toolkit]

#1379: Rename autoconfigured CCTK_BUILTIN functions to __builtin
--------------------------+-------------------------------------------------
  Reporter:  eschnett     |       Owner:                     
      Type:  enhancement  |      Status:  review             
  Priority:  major        |   Milestone:                     
 Component:  Cactus       |     Version:  development version
Resolution:               |    Keywords:                     
--------------------------+-------------------------------------------------

Comment (by hinder):

 Erik and I just discussed this, but didn't come to a conclusion.
 {{{__builtin_expect}}} is a gcc extension which is supported by some other
 compilers.  As such, it is probably safe in practice for us to do as Erik
 suggests, and define it if it doesn't exist.  However, I think we would be
 technically breaching the standards by doing this, as we are not a
 compiler implementation, so should not be defining things with double-
 underscore prefixes (according to the ANSI C standard). Erik also points
 out that we breach the standards in many other ways as well.  Apart from
 this specific case, I think we should decide on a policy for this sort of
 thing.  I am leaning towards the opinion that Cactus should only define
 things in its own namespace, rather than providing features from some
 compilers on others that users might expect.  This touches on features
 such as "inline", "restrict" and "M_PI"; all of these are things that
 Cactus tries to define according to common usage or another standard, when
 the currently-compiled standard doesn't provide them.  Issues of
 compatibility and portability seem to be complicated enough without Cactus
 defining symbols like this.  The logical conclusion of this would be that
 Cactus defines CCTK_EXPECT, CCTK_INLINE, CCTK_RESTRICT and CCTK_PI as part
 of the "Cactus platform", and we guarantee that this will work everywhere
 Cactus is supported.  It is then clear to the reader of the code that they
 are using a feature provided on some level by Cactus, rather than
 something which looks like a compiler-specific feature but is actually
 provided by Cactus.  The resulting code looks more ugly (in the case of
 inline, restrict and M_PI, though arguably not in the case of
 {{{__builtin_expect}}}, but we have to deal with CCTK_ARGUMENTS, CCTK_REAL
 etc anyway, and at least it is clear when Cactus is involved.

 Since the ET currently doesn't build on Datura, Erik and I agreed that he
 would just use the CCTK_ prefix for now, and defer the decision on policy
 until more people have weighed in.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1379#comment:4>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit