Predefined stdint macros (i.e. __UINT8_TYPE__, etc.)

Great, I'll make a CL adding these.

        Hello cfe-dev,

        Clang defines a subset of the predefined stdint macros that
        GCC does. In particular, GCC defines the following macros many
        of which are not defined in Clang:

        __U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}__
        __U?INT{PTR,MAX}_{MAX,TYPE}__

        Some of these macros are used in newlib's stdint.h, if they
        exist. It seems that it hasn't been thoroughly tested with
        Clang, however, as some macros are assumed to exist.

        Is it worth adding these to Clang?

    Yes, we should try to be compatible here, and generally it seems
    reasonable to define the fully expanded set of these.

Great, I'll make a CL adding these.

Be sure to put them behind !MSVCCompat* as we've been seeing problem reports about GCC definitions confusing MSVC code recently.

* I'm going to propose a GCCCompat LangOpt in the next few days but your patch will likely be ready before then.

Alp.

I don't agree with this necessarily. If the macros don't actively conflict
with MSVC, I would add them to the set of integer types that we currently
define.

The problem with the __EXCEPTIONS macro was that exceptions don't work in
the MSVC ABI yet. Once they do work, I would like to define __EXCEPTIONS
so that portable headers that detect the GCC macro will Just Work.

                Hello cfe-dev,

                Clang defines a subset of the predefined stdint macros
        that
                GCC does. In particular, GCC defines the following
        macros many
                of which are not defined in Clang:

                __U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}__
                __U?INT{PTR,MAX}_{MAX,TYPE}__

                Some of these macros are used in newlib's stdint.h, if
        they
                exist. It seems that it hasn't been thoroughly tested with
                Clang, however, as some macros are assumed to exist.

                Is it worth adding these to Clang?

            Yes, we should try to be compatible here, and generally it
        seems
            reasonable to define the fully expanded set of these.

        Great, I'll make a CL adding these.

    Be sure to put them behind !MSVCCompat* as we've been seeing
    problem reports about GCC definitions confusing MSVC code recently.

I don't agree with this necessarily. If the macros don't actively conflict with MSVC, I would add them to the set of integer types that we currently define.

How so? I'm pretty sure we want to keep the predefined macros aligned with MSVC when in full compatibility mode for now. We're not always consistent but that was the idea..

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..

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.

Alp.

                Hello cfe-dev,

                Clang defines a subset of the predefined stdint macros
        that
                GCC does. In particular, GCC defines the following
        macros many
                of which are not defined in Clang:

                __U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}__
                __U?INT{PTR,MAX}_{MAX,TYPE}__

                Some of these macros are used in newlib's stdint.h, if
        they
                exist. It seems that it hasn't been thoroughly tested with
                Clang, however, as some macros are assumed to exist.

                Is it worth adding these to Clang?

            Yes, we should try to be compatible here, and generally it
        seems
            reasonable to define the fully expanded set of these.

        Great, I'll make a CL adding these.

    Be sure to put them behind !MSVCCompat* as we've been seeing
    problem reports about GCC definitions confusing MSVC code recently.

I don't agree with this necessarily. If the macros don't actively
conflict with MSVC, I would add them to the set of integer types that we
currently define.

How so? I'm pretty sure we want to keep the predefined macros aligned with
MSVC when in full compatibility mode for now. We're not always consistent
but that was the idea..

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..

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.

Well, this is my first LLVM change, so it probably will take a little time
anyway. :slight_smile:

Question about FAST/LEAST types: how should I determine these for the
target? I couldn't find anything appropriate in TargetInfo.

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. :slight_smile:

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?

                Hello cfe-dev,

                Clang defines a subset of the predefined stdint macros
        that
                GCC does. In particular, GCC defines the following
        macros many
                of which are not defined in Clang:

                __U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}__
                __U?INT{PTR,MAX}_{MAX,TYPE}__

                Some of these macros are used in newlib's stdint.h, if
        they
                exist. It seems that it hasn't been thoroughly tested with
                Clang, however, as some macros are assumed to exist.

                Is it worth adding these to Clang?

            Yes, we should try to be compatible here, and generally it
        seems
            reasonable to define the fully expanded set of these.

        Great, I'll make a CL adding these.

    Be sure to put them behind !MSVCCompat* as we've been seeing
    problem reports about GCC definitions confusing MSVC code recently.

I don't agree with this necessarily. If the macros don't actively
conflict with MSVC, I would add them to the set of integer types that we
currently define.

How so? I'm pretty sure we want to keep the predefined macros aligned with
MSVC when in full compatibility mode for now. We're not always consistent
but that was the idea..

Our builtin stdint.h uses these macros; we need to provide them in all
modes.

                Hello cfe-dev,

                Clang defines a subset of the predefined stdint macros
        that
                GCC does. In particular, GCC defines the following
        macros many
                of which are not defined in Clang:

                __U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}__
                __U?INT{PTR,MAX}_{MAX,TYPE}__

                Some of these macros are used in newlib's stdint.h, if
        they
                exist. It seems that it hasn't been thoroughly tested
with
                Clang, however, as some macros are assumed to exist.

                Is it worth adding these to Clang?

            Yes, we should try to be compatible here, and generally it
        seems
            reasonable to define the fully expanded set of these.

        Great, I'll make a CL adding these.

    Be sure to put them behind !MSVCCompat* as we've been seeing
    problem reports about GCC definitions confusing MSVC code recently.

I don't agree with this necessarily. If the macros don't actively
conflict with MSVC, I would add them to the set of integer types that we
currently define.

How so? I'm pretty sure we want to keep the predefined macros aligned
with MSVC when in full compatibility mode for now. We're not always
consistent but that was the idea..

Our builtin stdint.h uses these macros; we need to provide them in all
modes.

Hmm, maybe we could keep the current set of __INT*_TYPE__ (that we use in
stdint.h) visible in all modes, but make the additional macros be GCC-only.
Or perhaps we should tell the newlib folks that they shouldn't be relying
on compiler implementation details, and should just include stdint.h. =)

The problem with the __EXCEPTIONS macro was that exceptions don't work in

                    On Wed, Jun 11, 2014 at 12:14 PM, Chandler Carruth
                    <chandlerc@google.com
            <mailto:chandlerc@google.com> <mailto:chandlerc@google.com
            <mailto:chandlerc@google.com>>
                    <mailto:chandlerc@google.com
            <mailto:chandlerc@google.com> <mailto:chandlerc@google.com
            <mailto:chandlerc@google.com>>>>

                    wrote:

                        On Wed, Jun 11, 2014 at 8:10 PM, Ben Smith
                    <binji@chromium.org <mailto:binji@chromium.org>
            <mailto:binji@chromium.org>
                        <mailto:binji@chromium.org
            <mailto:binji@chromium.org> <mailto:binji@chromium.org
            <mailto:binji@chromium.org>>>>

                    wrote:

                            Hello cfe-dev,

                            Clang defines a subset of the predefined
            stdint macros
                    that
                            GCC does. In particular, GCC defines the
            following
                    macros many
                            of which are not defined in Clang:

            __U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}__
            __U?INT{PTR,MAX}_{MAX,TYPE}__

                            Some of these macros are used in newlib's
            stdint.h, if
                    they
                            exist. It seems that it hasn't been
            thoroughly tested with
                            Clang, however, as some macros are assumed
            to exist.

                            Is it worth adding these to Clang?

                        Yes, we should try to be compatible here, and
            generally it
                    seems
                        reasonable to define the fully expanded set of
            these.

                    Great, I'll make a CL adding these.

                Be sure to put them behind !MSVCCompat* as we've been
            seeing
                problem reports about GCC definitions confusing MSVC
            code recently.

            I don't agree with this necessarily. If the macros don't
            actively conflict with MSVC, I would add them to the set
            of integer types that we currently define.

        How so? I'm pretty sure we want to keep the predefined macros
        aligned with MSVC when in full compatibility mode for now.
        We're not always consistent but that was the idea..

    Our builtin stdint.h uses these macros; we need to provide them in
    all modes.

Hmm, maybe we could keep the current set of __INT*_TYPE__ (that we use in stdint.h) visible in all modes, but make the additional macros be GCC-only. Or perhaps we should tell the newlib folks that they shouldn't be relying on compiler implementation details, and should just include stdint.h. =)

That was my line of thinking :wink:

I'm more interested in tucking away the GXX and __GNUC__ macros to be honest, and getting __VERSION__ to not lie unless in GCCCompat mode but these would be nice-to-haves.

Alp.

                Hello cfe-dev,

                Clang defines a subset of the predefined stdint macros
        that
                GCC does. In particular, GCC defines the following
        macros many
                of which are not defined in Clang:

                __U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}__
                __U?INT{PTR,MAX}_{MAX,TYPE}__

                Some of these macros are used in newlib's stdint.h, if
        they
                exist. It seems that it hasn't been thoroughly tested
with
                Clang, however, as some macros are assumed to exist.

                Is it worth adding these to Clang?

            Yes, we should try to be compatible here, and generally it
        seems
            reasonable to define the fully expanded set of these.

        Great, I'll make a CL adding these.

    Be sure to put them behind !MSVCCompat* as we've been seeing
    problem reports about GCC definitions confusing MSVC code recently.

I don't agree with this necessarily. If the macros don't actively
conflict with MSVC, I would add them to the set of integer types that we
currently define.

How so? I'm pretty sure we want to keep the predefined macros aligned
with MSVC when in full compatibility mode for now. We're not always
consistent but that was the idea..

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..

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.

Well, this is my first LLVM change, so it probably will take a little time
anyway. :slight_smile:

Question about FAST/LEAST types: how should I determine these for the
target? I couldn't find anything appropriate in TargetInfo.

I've uploaded a patch for this here: http://reviews.llvm.org/D4141

I duplicated the assumption from stdint.h that the FAST types match the
LEAST types, and gated all of these new macros on !MSVCCompat.

-Ben