[ET Trac] [Einstein Toolkit] #1379: Rename autoconfigured CCTK_BUILTIN functions to __builtin
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Sun Jun 16 13:19:28 CDT 2013
#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
More information about the Trac
mailing list