<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 12, 2014 at 1:32 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Wed, Jun 11, 2014 at 3:29 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 12/06/2014 01:12, Reid Kleckner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On Wed, Jun 11, 2014 at 2:46 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a> <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
<br>
<br>
    On 12/06/2014 00:33, Ben Smith wrote:<br>
<br>
        On Wed, Jun 11, 2014 at 12:14 PM, Chandler Carruth<br>
        <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a> <mailto:<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>><br></div>
        <mailto:<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a> <mailto:<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>>><u></u>><div>
<br>
        wrote:<br>
<br>
<br>
            On Wed, Jun 11, 2014 at 8:10 PM, Ben Smith<br>
        <<a href="mailto:binji@chromium.org" target="_blank">binji@chromium.org</a> <mailto:<a href="mailto:binji@chromium.org" target="_blank">binji@chromium.org</a>><br></div>
            <mailto:<a href="mailto:binji@chromium.org" target="_blank">binji@chromium.org</a> <mailto:<a href="mailto:binji@chromium.org" target="_blank">binji@chromium.org</a>>>><div><br>
        wrote:<br>
<br>
                Hello cfe-dev,<br>
<br>
                Clang defines a subset of the predefined stdint macros<br>
        that<br>
                GCC does. In particular, GCC defines the following<br>
        macros many<br>
                of which are not defined in Clang:<br>
<br>
                __U?INT{_,_FAST,_LEAST}{8,16,<u></u>32,64}_{MAX,TYPE}__<br>
                __U?INT{PTR,MAX}_{MAX,TYPE}__<br>
<br>
                Some of these macros are used in newlib's stdint.h, if<br>
        they<br>
                exist. It seems that it hasn't been thoroughly tested with<br>
                Clang, however, as some macros are assumed to exist.<br>
<br>
                Is it worth adding these to Clang?<br>
<br>
<br>
            Yes, we should try to be compatible here, and generally it<br>
        seems<br>
            reasonable to define the fully expanded set of these.<br>
<br>
<br>
        Great, I'll make a CL adding these.<br>
<br>
<br>
    Be sure to put them behind !MSVCCompat* as we've been seeing<br>
    problem reports about GCC definitions confusing MSVC code recently.<br>
<br>
<br>
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.<br>
</div></blockquote>
<br>
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..</blockquote><div><br></div></div></div>
<div>Our builtin stdint.h uses these macros; we need to provide them in all modes.</div></div></div></div></blockquote><div><br></div><div>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. =)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The problem with the __EXCEPTIONS macro was that exceptions don't work in the MSVC ABI yet.<br>
</blockquote>
<br></div>
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..<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Once they do work, I would like to define __EXCEPTIONS so that portable headers that detect the GCC macro will Just Work.<br>
</blockquote>
<br></div>
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?<br>
<br>
Adding these unconditionally now just adds more work to make the switch.<span><font color="#888888"><br>
<br>
Alp.</font></span><div><div><br>
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div></div><br></div></div>
</blockquote></div><br></div></div>