[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):

 The recent update to hwloc fails to build on Datura, and Erik says that
 this patch is required to fix this.

 My thoughts on this are the following, but I don't have a well-informed
 opinion at the moment; please correct me if I make any mistakes!

 Is the use of {{{__builtin_expect}}} (for example) the recommended way to
 annotate the code?  Should we be using compiler-specific features like
 this? Does this make the code gcc-specific?  I'm tempted to disagree with
 Cactus providing functions which are usually provided by GCC on principle.
 Was there a specific incident that prompted this, e.g. hwloc expecting
 that this was available?  Does this mean that hwloc is compatible only
 with GCC and not the Intel compiler, where this is not provided?  I wonder
 if it would be better not to interfere with compiler-provided names, and
 instead stick with the CCTK_ prefix for features that we are providing in
 the "Cactus platform".  So code written "for" Cactus will use the CCTK_
 version (and will be guaranteed to work wherever Cactus is supported),
 rather than something which is associated with GCC, and code which is
 imported in bulk from somewhere else is buggy if it only works with GCC,
 and needs a specific workaround (e.g. we can define the GCC
 {{{__builtin_expect}}} as the CCTK_ version for that library, which limits
 the scope of the change to the code which is not portable, rather than
 modifying what might be expected behaviour globally).

 This is in principle the same as the M_PI issue, but there we can make the
 case that M_PI is pervasively expected in numerical code, and argue from
 practicality that defining it ourselves is OK, whereas the GCC
 {{{__builtin_*}}} functions are not so widely used, and there it might
 cause confusion and/or problems to define them in Cactus.

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