[cfe-dev] Predefined stdint macros (i.e. __UINT8_TYPE__, etc.)

Reid Kleckner rnk at google.com
Wed Jun 11 16:26:05 PDT 2014


On Wed, Jun 11, 2014 at 3:29 PM, Alp Toker <alp at nuanti.com> wrote:
>
> The problem with the __EXCEPTIONS macro was that exceptions don't work in
>> the MSVC ABI yet.
>>
>
> If we start defining other macros, especially well-known GNU ones, there's
> a risk that random bits of GCC-specific code will get enabled in portable
> headers..


That's the idea, since I expect they will more or less work out of the box.
 The header checking for __EXCEPTIONS probably would've done the right
thing if our exception support actually worked.


>  Once they do work, I would like to define __EXCEPTIONS so that portable
>> headers that detect the GCC macro will Just Work.
>>
>
> If an in-between mode like that is something you want (and I suspect it
> *isn't* for most of our users), how about holding on a couple of days for
> the prospective -fms-compatibility -fgcc-compatibility?
>
> Adding these unconditionally now just adds more work to make the switch.


I just want the mode that makes the most code compile with the least amount
of user effort.  :)

What kind of stuff would you put under -fgcc-compatibility?  If you put GCC
__builtins under that flag, I suspect that lots of portability headers that
check for __clang__ will stop building.  I don't want to tell users to go
to the trouble of using __has_builtin if the following was already checked
in somewhere:

#if defined(__GNUC__) || defined(__clang__)
#define LIKELY(x) __builtin_expect((x), true)
#define READONLY __attribute__((__pure__))
#else
#define LIKELY(x)
#define READONLY
#endif

There are a bunch of gcc builtins and attributes like this that we've
essentially adopted as the canonical spelling.  If we can draw the line for
-fgcc-compatibility to allow these kinds of things, then I'm on board.
 Sound good?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140611/77b2182c/attachment.html>


More information about the cfe-dev mailing list