[llvm-dev] llvm intrinsics/libc/libm question

[Ryan Taylor via llvm-dev]

per 7.1.4p1:

 The use of #undef to remove any macro definition will also ensure that an
actual function is referred to

And then footnote 187:

Because external identifiers and some macro names beginning with an
underscore are reserved, implementations may provide special semantics for
such names. For example, the identifier _BUILTIN_abs could be used to
indicate generation of in-line code for the abs function. Thus, the
appropriate header could specify:

#define abs(x) __builtin_abs(x)

for a compiler whose code generator will accept it.

In this manner, a user desiring to guarantee that a given library function
such as abs will be a genuine function may write

#undef abs

whether the implementation’s header provides a macro implementation of abs
or a built-in implementation. The prototype for the function, which
precedes and is hidden by any macro definition, is thereby revealed also.


On Tue, Jun 7, 2016 at 4:38 PM, Tim Northover <t.p.northover at gmail.com>
wrote:

> On 7 June 2016 at 13:24, Ryan Taylor via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Not sure why it's called TargetLibraryInfo if it's not in target specific
> > code? It seems that ALL targets use this code, making it generic. Am I
> > missing something here?
>
> Some of the names can vary by platform, for example ARM sometimes has
> __aeabi_memcpy instead of memcpy
>
> > ps. The spec also states (albeit unclearly) that you can use "#undef" to
> > omit a library function so that a user defined function of the same name
> can
> > be used but LLVM doesn't seem to support that.
>
> I think it says exactly the opposite: (7.1.2p3):
>
>     "If the program removes (with #undef) any macro definition of an
> identifier in the first group listed above, the behavior is
> undefined."
>
> Incidentally, I don't think anyone's mentioned that "-ffreestanding"
> will probably inhibit the intrinsics substantially if that's what
> you're after (technically, it's probably a compiler extension that it
> gives them back to the user, but everyone does it as far as I know).
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160607/1fde4fbc/attachment.html>