Quantcast

Re: [llvm-dev] problem (and fix) with -fms-extensions

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
Moving to cfe-dev to discuss clang things.

I think we already have _WCHAR_T_DEFINED for this:
  if (LangOpts.MicrosoftExt) {
    if (LangOpts.WChar) {
      // wchar_t supported as a keyword.
      Builder.defineMacro("_WCHAR_T_DEFINED");
      Builder.defineMacro("_NATIVE_WCHAR_T_DEFINED");
    }
  }

On Thu, May 11, 2017 at 11:04 AM, Marc Espie via llvm-dev <[hidden email]> wrote:
I've tried to build something that wanted ms-extensions on OpenBSD.
Long story short, didn't work so well, because all system includes
lead to

<machine/_types.h>
#ifndef __cplusplus
typedef int                     __wchar_t;
#endif

and since ms-extensions includes __char_t as a built-in, this did fail
abysmally.

It would be simple to fix in OpenBSD, assuming clang did tell us it
was using ms-extensions.

Would something like this be appropriate ? macro name subject to approval
of course.


Index: lib/Frontend/InitPreprocessor.cpp
===================================================================
RCS file: /build/data/openbsd/cvs/src/gnu/llvm/tools/clang/lib/Frontend/InitPreprocessor.cpp,v
retrieving revision 1.1.1.4
diff -u -p -r1.1.1.4 InitPreprocessor.cpp
--- lib/Frontend/InitPreprocessor.cpp   14 Mar 2017 08:07:56 -0000      1.1.1.4
+++ lib/Frontend/InitPreprocessor.cpp   11 May 2017 17:54:41 -0000
@@ -366,6 +366,8 @@ static void InitializeStandardPredefined
   else
     Builder.defineMacro("__STDC_HOSTED__");

+  if (LangOpts.MicrosoftMode)
+    Builder.defineMacro("__ms_extensions__", 1);
   if (!LangOpts.CPlusPlus) {
     if (LangOpts.C11)
       Builder.defineMacro("__STDC_VERSION__", "201112L");

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
On Fri, May 12, 2017 at 08:53:53AM -0700, Reid Kleckner wrote:

>
>    Moving to cfe-dev to discuss clang things.
>    I think we already have _WCHAR_T_DEFINED for this:
>    Â  if (LangOpts.MicrosoftExt) {
>    Â  Â  if (LangOpts.WChar) {
>    Â  Â  Â  // wchar_t supported as a keyword.
>    Â  Â  Â  Builder.defineMacro("_WCHAR_T_DEFINED");
>    Â  Â  Â  Builder.defineMacro("_NATIVE_WCHAR_T_DEFINED");
>    Â  Â  }
>    Â  }

Nope. I'm talking about the __wchar_t type.
In my case, even a C language "hello world" won't compile:

nausicaa$ clang -fms-extensions a.c
In file included from a.c:1:
In file included from /usr/include/stdio.h:43:
In file included from /usr/include/sys/_types.h:37:
/usr/include/machine/_types.h:132:15: error: cannot combine with previous 'int'
      declaration specifier
typedef int                     __wchar_t;
                                ^
1 error generated.

but actually based on the existing code, I would suggest following
the pattern.

my main concern would be: are names with ___ readable, or is there
a suggestion for better names ?

Index: InitPreprocessor.cpp
===================================================================
RCS file: /cvs/src/gnu/llvm/tools/clang/lib/Frontend/InitPreprocessor.cpp,v
retrieving revision 1.1.1.4
diff -u -p -r1.1.1.4 InitPreprocessor.cpp
--- InitPreprocessor.cpp 14 Mar 2017 08:07:56 -0000 1.1.1.4
+++ InitPreprocessor.cpp 13 May 2017 15:59:14 -0000
@@ -666,6 +668,10 @@ static void InitializePredefinedMacros(c
       // wchar_t supported as a keyword.
       Builder.defineMacro("_WCHAR_T_DEFINED");
       Builder.defineMacro("_NATIVE_WCHAR_T_DEFINED");
+    } else {
+      // __wchar_t supported as a keyword
+      Builder.defineMacro("___WCHAR_T_DEFINED");
+      Builder.defineMacro("_NATIVE___WCHAR_T_DEFINED");
     }
   }
 
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
I'd rather not add new pre-defined macros if we can avoid it. There are already too many. You can probably detect this situation with:
#if defined(_MSC_EXTENSIONS) && !defined(_WCHAR_T_DEFINED)

On Sat, May 13, 2017 at 9:02 AM, Marc Espie <[hidden email]> wrote:
On Fri, May 12, 2017 at 08:53:53AM -0700, Reid Kleckner wrote:
>
>    Moving to cfe-dev to discuss clang things.
>    I think we already have _WCHAR_T_DEFINED for this:
>      if (LangOpts.MicrosoftExt) {
>        if (LangOpts.WChar) {
>          // wchar_t supported as a keyword.
>          Builder.defineMacro("_WCHAR_T_DEFINED");
>          Builder.defineMacro("_NATIVE_WCHAR_T_DEFINED");
>        }
>      }

Nope. I'm talking about the __wchar_t type.
In my case, even a C language "hello world" won't compile:

nausicaa$ clang -fms-extensions a.c
In file included from a.c:1:
In file included from /usr/include/stdio.h:43:
In file included from /usr/include/sys/_types.h:37:
/usr/include/machine/_types.h:132:15: error: cannot combine with previous 'int'
      declaration specifier
typedef int                     __wchar_t;
                                ^
1 error generated.

but actually based on the existing code, I would suggest following
the pattern.

my main concern would be: are names with ___ readable, or is there
a suggestion for better names ?

Index: InitPreprocessor.cpp
===================================================================
RCS file: /cvs/src/gnu/llvm/tools/clang/lib/Frontend/InitPreprocessor.cpp,v
retrieving revision 1.1.1.4
diff -u -p -r1.1.1.4 InitPreprocessor.cpp
--- InitPreprocessor.cpp        14 Mar 2017 08:07:56 -0000      1.1.1.4
+++ InitPreprocessor.cpp        13 May 2017 15:59:14 -0000
@@ -666,6 +668,10 @@ static void InitializePredefinedMacros(c
       // wchar_t supported as a keyword.
       Builder.defineMacro("_WCHAR_T_DEFINED");
       Builder.defineMacro("_NATIVE_WCHAR_T_DEFINED");
+    } else {
+      // __wchar_t supported as a keyword
+      Builder.defineMacro("___WCHAR_T_DEFINED");
+      Builder.defineMacro("_NATIVE___WCHAR_T_DEFINED");
     }
   }



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
On Wed, May 17, 2017 at 01:01:07PM -0700, Reid Kleckner wrote:
>
>    I'd rather not add new pre-defined macros if we can avoid it. There are
>    already too many. You can probably detect this situation with:
>    #if defined(_MSC_EXTENSIONS) && !defined(_WCHAR_T_DEFINED)
>
Was this added recently ?

There is no _MSC_EXTENSIONS in the clang I'm using...
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
On Wed, May 17, 2017 at 3:22 PM, Marc Espie <[hidden email]> wrote:
On Wed, May 17, 2017 at 01:01:07PM -0700, Reid Kleckner wrote:
>
>    I'd rather not add new pre-defined macros if we can avoid it. There are
>    already too many. You can probably detect this situation with:
>    #if defined(_MSC_EXTENSIONS) && !defined(_WCHAR_T_DEFINED)
>
Was this added recently ?

There is no _MSC_EXTENSIONS in the clang I'm using...

Looks like we only define it for Windows targets.

How about __is_identifier?

$ cat t.cpp
#if !__is_identifier(__wchar_t)
#error "have __wchar_t"
#else
#error "no __wchar_t"
#endif

$ clang --target=x86_64-linux -c t.cpp
t.cpp:4:2: error: "no __wchar_t"
#error "no __wchar_t"
 ^
1 error generated.

$ clang --target=x86_64-linux -c t.cpp  -fms-extensions
t.cpp:2:2: error: "have __wchar_t"
#error "have __wchar_t"
 ^
1 error generated.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
On Wed, May 17, 2017 at 03:55:06PM -0700, Reid Kleckner wrote:

>
>    On Wed, May 17, 2017 at 3:22 PM, Marc Espie <[1][hidden email]> wrote:
>
>      On Wed, May 17, 2017 at 01:01:07PM -0700, Reid Kleckner wrote:
>      >
>      >Â  Â  I'd rather not add new pre-defined macros if we can avoid it.
>      There are
>      >Â  Â  already too many. You can probably detect this situation
>      with:
>      >Â  Â  #if defined(_MSC_EXTENSIONS) && !defined(_WCHAR_T_DEFINED)
>      >
>      Was this added recently ?
>      There is no _MSC_EXTENSIONS in the clang I'm using...
>
>    Looks like we only define it for Windows targets.
>    How about __is_identifier?
>    $ cat t.cpp
>    #if !__is_identifier(__wchar_t)
>    #error "have __wchar_t"
>    #else
>    #error "no __wchar_t"
>    #endif

Nope, that will trigger errors on non clang compilers.

Why do you fight so hard against a simple solution ?
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
In reply to this post by Martin J. O'Riordan via cfe-dev
On Wed, May 17, 2017 at 03:55:06PM -0700, Reid Kleckner wrote:

>
>    On Wed, May 17, 2017 at 3:22 PM, Marc Espie <[1][hidden email]> wrote:
>
>      On Wed, May 17, 2017 at 01:01:07PM -0700, Reid Kleckner wrote:
>      >
>      >Â  Â  I'd rather not add new pre-defined macros if we can avoid it.
>      There are
>      >Â  Â  already too many. You can probably detect this situation
>      with:
>      >Â  Â  #if defined(_MSC_EXTENSIONS) && !defined(_WCHAR_T_DEFINED)
>      >
>      Was this added recently ?
>      There is no _MSC_EXTENSIONS in the clang I'm using...
>
>    Looks like we only define it for Windows targets.
>    How about __is_identifier?

Or, what's the problem with moving _MSC_EXTENSIONS to be for all targets.


Look, this stuff is highly specific, I doubt many people are going to
use -fms-extensions who don't know what they're doing.
E.g., the exposure to _MSC_EXTENSIONS will be minimal.

Having a single define will mean replacing (for us)
#ifndef __cplusplus
typedef int                     __wchar_t;
#endif

with
#if !defined(__cplusplus) && !defined(_MSC_EXTENSIONS)
typedef int                     __wchar_t;
#endif

which is fairly acceptable.

Playing with __is_identifier is rather more awful, because there is no
simple construct, we can't simply write:
#if !defined(__cplusplus) || __is_identifier(__wchar_t)
because  this *also* has to work with other compilers, some of which
do not understand __is_identifier at all, so it can't be a single test
then.

It would become some atrocity like

#if !defined(__cplusplus)
# if defined(__is_identifier)
#  if __is_identifier(__wchar_t)
#  else
typedef int __wchar_t;
#  endif
# else
typedef int __wchar_t;
# endif
#endif

And that has about zero chance to ever be committed in our tree,
especially since this is in a md _types.h file, so this construct x10 times
in the tree.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
In reply to this post by Martin J. O'Riordan via cfe-dev
On 17 May 2017 at 16:24, Marc Espie via cfe-dev <[hidden email]> wrote:
On Wed, May 17, 2017 at 03:55:06PM -0700, Reid Kleckner wrote:
>
>    On Wed, May 17, 2017 at 3:22 PM, Marc Espie <[1][hidden email]> wrote:
>
>      On Wed, May 17, 2017 at 01:01:07PM -0700, Reid Kleckner wrote:
>      >
>      >    I'd rather not add new pre-defined macros if we can avoid it.
>      There are
>      >    already too many. You can probably detect this situation
>      with:
>      >    #if defined(_MSC_EXTENSIONS) && !defined(_WCHAR_T_DEFINED)
>      >
>      Was this added recently ?
>      There is no _MSC_EXTENSIONS in the clang I'm using...
>
>    Looks like we only define it for Windows targets.
>    How about __is_identifier?
>    $ cat t.cpp
>    #if !__is_identifier(__wchar_t)
>    #error "have __wchar_t"
>    #else
>    #error "no __wchar_t"
>    #endif

Nope, that will trigger errors on non clang compilers.

You can wrap it in #ifdef __clang__ to fix that.
 
Why do you fight so hard against a simple solution ?
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
On Wed, May 17, 2017 at 05:31:45PM -0700, Richard Smith wrote:

>
>    On 17 May 2017 at 16:24, Marc Espie via cfe-dev
>    <[1][hidden email]> wrote:
>
>      On Wed, May 17, 2017 at 03:55:06PM -0700, Reid Kleckner wrote:
>      >
>      >Â  Â  On Wed, May 17, 2017 at 3:22 PM, Marc Espie
>      <[1][2][hidden email]> wrote:
>      >
>      >Â  Â  Â  On Wed, May 17, 2017 at 01:01:07PM -0700, Reid Kleckner
>      wrote:
>      >Â  Â  Â  >
>      >Â  Â  Â  >ÃÂ  ÃÂ  I'd rather not add new pre-defined macros if we
>      can avoid it.
>      >Â  Â  Â  There are
>      >Â  Â  Â  >ÃÂ  ÃÂ  already too many. You can probably detect this
>      situation
>      >Â  Â  Â  with:
>      >Â  Â  Â  >ÃÂ  ÃÂ  #if defined(_MSC_EXTENSIONS) &&
>      !defined(_WCHAR_T_DEFINED)
>      >Â  Â  Â  >
>      >Â  Â  Â  Was this added recently ?
>      >Â  Â  Â  There is no _MSC_EXTENSIONS in the clang I'm using...
>      >
>      >Â  Â  Looks like we only define it for Windows targets.
>      >Â  Â  How about __is_identifier?
>      >Â  Â  $ cat t.cpp
>      >Â  Â  #if !__is_identifier(__wchar_t)
>      >Â  Â  #error "have __wchar_t"
>      >Â  Â  #else
>      >Â  Â  #error "no __wchar_t"
>      >Â  Â  #endif
>      Nope, that will trigger errors on non clang compilers.
>
>    You can wrap it in #ifdef __clang__ to fix that.
>    Â

And that leads to more or less the same shitty set of conditionals I already
posted about... as opposed to using _MSC_EXTENSIONS, which by the way is
already defined on windows, is unlikely to ever collide with anything, and
would only be on with -fms-extensions, which is not the most common option
ever...

In every single case, __is_identifier will replace a one-liner
with several lines of nested conditionals...  not a good thing.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
In reply to this post by Martin J. O'Riordan via cfe-dev
> Date: Fri, 12 May 2017 08:53:53 -0700
> From: Reid Kleckner via llvm-dev <[hidden email]>
>
> Moving to cfe-dev to discuss clang things.
>
> I think we already have _WCHAR_T_DEFINED for this:
>   if (LangOpts.MicrosoftExt) {
>     if (LangOpts.WChar) {
>       // wchar_t supported as a keyword.
>       Builder.defineMacro("_WCHAR_T_DEFINED");
>       Builder.defineMacro("_NATIVE_WCHAR_T_DEFINED");
>     }
>   }

Unfortunately those aren't defined if you use -fms-extensions in C
mode as LangOpts.WChar is false in that case.

> On Thu, May 11, 2017 at 11:04 AM, Marc Espie via llvm-dev <
> [hidden email]> wrote:
>
> > I've tried to build something that wanted ms-extensions on OpenBSD.
> > Long story short, didn't work so well, because all system includes
> > lead to
> >
> > <machine/_types.h>
> > #ifndef __cplusplus
> > typedef int                     __wchar_t;
> > #endif
> >
> > and since ms-extensions includes __char_t as a built-in, this did fail
> > abysmally.
> >
> > It would be simple to fix in OpenBSD, assuming clang did tell us it
> > was using ms-extensions.
> >
> > Would something like this be appropriate ? macro name subject to approval
> > of course.
> >
> >
> > Index: lib/Frontend/InitPreprocessor.cpp
> > ===================================================================
> > RCS file: /build/data/openbsd/cvs/src/gnu/llvm/tools/clang/lib/
> > Frontend/InitPreprocessor.cpp,v
> > retrieving revision 1.1.1.4
> > diff -u -p -r1.1.1.4 InitPreprocessor.cpp
> > --- lib/Frontend/InitPreprocessor.cpp   14 Mar 2017 08:07:56 -0000
> > 1.1.1.4
> > +++ lib/Frontend/InitPreprocessor.cpp   11 May 2017 17:54:41 -0000
> > @@ -366,6 +366,8 @@ static void InitializeStandardPredefined
> >    else
> >      Builder.defineMacro("__STDC_HOSTED__");
> >
> > +  if (LangOpts.MicrosoftMode)
> > +    Builder.defineMacro("__ms_extensions__", 1);
> >    if (!LangOpts.CPlusPlus) {
> >      if (LangOpts.C11)
> >        Builder.defineMacro("__STDC_VERSION__", "201112L");
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
>
> --001a114190de613d6d054f55b675
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr"><div>Moving to cfe-dev to discuss clang things.<br></div><=
> div><br></div><div>I think we already have=C2=A0_WCHAR_T_DEFINED for this:<=
> /div><div><div>=C2=A0 if (LangOpts.MicrosoftExt) {</div><div>=C2=A0 =C2=A0 =
> if (LangOpts.WChar) {</div><div>=C2=A0 =C2=A0 =C2=A0 // wchar_t supported a=
> s a keyword.</div><div>=C2=A0 =C2=A0 =C2=A0 Builder.defineMacro(&quot;_WCHA=
> R_T_DEFINED&quot;);</div><div>=C2=A0 =C2=A0 =C2=A0 Builder.defineMacro(&quo=
> t;_NATIVE_WCHAR_T_DEFINED&quot;);</div><div>=C2=A0 =C2=A0 }</div><div>=C2=
> =A0 }</div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
> uote">On Thu, May 11, 2017 at 11:04 AM, Marc Espie via llvm-dev <span dir=
> =3D"ltr">&lt;<a href=3D"mailto:[hidden email]" target=3D"_blank">l=
> [hidden email]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
> quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
> ex">I&#39;ve tried to build something that wanted ms-extensions on OpenBSD.=
> <br>
> Long story short, didn&#39;t work so well, because all system includes<br>
> lead to<br>
> <br>
> &lt;machine/_types.h&gt;<br>
> #ifndef __cplusplus<br>
> typedef int=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
> =C2=A0 =C2=A0__wchar_t;<br>
> #endif<br>
> <br>
> and since ms-extensions includes __char_t as a built-in, this did fail<br>
> abysmally.<br>
> <br>
> It would be simple to fix in OpenBSD, assuming clang did tell us it<br>
> was using ms-extensions.<br>
> <br>
> Would something like this be appropriate ? macro name subject to approval<b=
> r>
> of course.<br>
> <br>
> <br>
> Index: lib/Frontend/InitPreprocessor.<wbr>cpp<br>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D<wbr>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<wbr>=3D=3D=3D=3D=3D=3D=3D<br>
> RCS file: /build/data/openbsd/cvs/src/<wbr>gnu/llvm/tools/clang/lib/<wbr>Fr=
> ontend/InitPreprocessor.cpp,<wbr>v<br>
> retrieving revision 1.1.1.4<br>
> diff -u -p -r1.1.1.4 InitPreprocessor.cpp<br>
> --- lib/Frontend/InitPreprocessor.<wbr>cpp=C2=A0 =C2=A014 Mar 2017 08:07:56=
>  -0000=C2=A0 =C2=A0 =C2=A0 1.1.1.4<br>
> +++ lib/Frontend/InitPreprocessor.<wbr>cpp=C2=A0 =C2=A011 May 2017 17:54:41=
>  -0000<br>
> @@ -366,6 +366,8 @@ static void InitializeStandardPredefined<br>
> =C2=A0 =C2=A0else<br>
> =C2=A0 =C2=A0 =C2=A0Builder.defineMacro(&quot;__STDC_<wbr>HOSTED__&quot;);<=
> br>
> <br>
> +=C2=A0 if (LangOpts.MicrosoftMode)<br>
> +=C2=A0 =C2=A0 Builder.defineMacro(&quot;__ms_<wbr>extensions__&quot;, 1);<=
> br>
> =C2=A0 =C2=A0if (!LangOpts.CPlusPlus) {<br>
> =C2=A0 =C2=A0 =C2=A0if (LangOpts.C11)<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Builder.defineMacro(&quot;__STDC_<wbr>VERSION__&=
> quot;, &quot;201112L&quot;);<br>
> <br>______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href=3D"mailto:[hidden email]">[hidden email]</a><br>
> <a href=3D"http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel=3D"=
> noreferrer" target=3D"_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/li=
> stinfo/llvm-dev</a><br>
> <br></blockquote></div><br></div>
>
> --001a114190de613d6d054f55b675--
>
> --===============0097119953384729711==
> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: base64
> Content-Disposition: inline
>
> X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTExWTSBEZXZl
> bG9wZXJzIG1haWxpbmcgbGlzdApsbHZtLWRldkBsaXN0cy5sbHZtLm9yZwpodHRwOi8vbGlzdHMu
> bGx2bS5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL2xsdm0tZGV2Cg==
>
> --===============0097119953384729711==--
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
In reply to this post by Martin J. O'Riordan via cfe-dev
On Wed, May 17, 2017 at 4:35 PM, Marc Espie <[hidden email]> wrote:
On Wed, May 17, 2017 at 03:55:06PM -0700, Reid Kleckner wrote:
>
>    On Wed, May 17, 2017 at 3:22 PM, Marc Espie <[1][hidden email]> wrote:
>
>      On Wed, May 17, 2017 at 01:01:07PM -0700, Reid Kleckner wrote:
>      >
>      >    I'd rather not add new pre-defined macros if we can avoid it.
>      There are
>      >    already too many. You can probably detect this situation
>      with:
>      >    #if defined(_MSC_EXTENSIONS) && !defined(_WCHAR_T_DEFINED)
>      >
>      Was this added recently ?
>      There is no _MSC_EXTENSIONS in the clang I'm using...
>
>    Looks like we only define it for Windows targets.
>    How about __is_identifier?

Or, what's the problem with moving _MSC_EXTENSIONS to be for all targets.


Look, this stuff is highly specific, I doubt many people are going to
use -fms-extensions who don't know what they're doing.
E.g., the exposure to _MSC_EXTENSIONS will be minimal.

Having a single define will mean replacing (for us)
#ifndef __cplusplus
typedef int                     __wchar_t;
#endif

with
#if !defined(__cplusplus) && !defined(_MSC_EXTENSIONS)
typedef int                     __wchar_t;
#endif

which is fairly acceptable.

Playing with __is_identifier is rather more awful, because there is no
simple construct, we can't simply write:
#if !defined(__cplusplus) || __is_identifier(__wchar_t)
because  this *also* has to work with other compilers, some of which
do not understand __is_identifier at all, so it can't be a single test
then.

It would become some atrocity like

#if !defined(__cplusplus)
# if defined(__is_identifier)
#  if __is_identifier(__wchar_t)
#  else
typedef int     __wchar_t;
#  endif
# else
typedef int     __wchar_t;
# endif
#endif

And that has about zero chance to ever be committed in our tree,
especially since this is in a md _types.h file, so this construct x10 times
in the tree.

So, we actually have documentation on this, and __wchar_t is the example use case:

Please just use it, it works.

I do not want to define _MSC_EXTENSIONS more than we already do, and I don't think we should add more pre-defined macros when we already have these nicely factored feature test macros that don't pollute the global namespace. The "simple solution" is not a good solution.

I believe our use of _MSC_EXTENSIONS is wrong anyway. It is controlled by MSVC's /Ze and /Za flags, which do not relate to our -fms-extensions flag.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
On Thu, May 18, 2017 at 09:49:17AM -0700, Reid Kleckner wrote:

>    So, we actually have documentation on this, and __wchar_t is the
>    example use case:
>    [3]https://clang.llvm.org/docs/LanguageExtensions.html#is-identifier
>    Please just use it, it works.
>    I do not want to define _MSC_EXTENSIONS more than we already do, and I
>    don't think we should add more pre-defined macros when we already have
>    these nicely factored feature test macros that don't pollute the global
>    namespace. The "simple solution" is not a good solution.
>    I believe our use of _MSC_EXTENSIONS is wrong anyway. It is controlled
>    by MSVC's /Ze and /Za flags, which do not relate to our -fms-extensions
>    flag.
>
How about you actually read my problem ?

this is not what I'm trying to solve.

The error I get is:
/usr/include/machine/_types.h:132:15: error: cannot combine with previous 'int'
declaration specifier
      typedef int                     __wchar_t;


and it's *because* -fms-extensions does define __wchar_t.

A solution is nowhere as short as the fragment you quote from the documentation.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] problem (and fix) with -fms-extensions

Martin J. O'Riordan via cfe-dev
On 18 May 2017 9:59 am, "Marc Espie via cfe-dev" <[hidden email]> wrote:
On Thu, May 18, 2017 at 09:49:17AM -0700, Reid Kleckner wrote:
>    So, we actually have documentation on this, and __wchar_t is the
>    example use case:
>    [3]https://clang.llvm.org/docs/LanguageExtensions.html#is-identifier
>    Please just use it, it works.
>    I do not want to define _MSC_EXTENSIONS more than we already do, and I
>    don't think we should add more pre-defined macros when we already have
>    these nicely factored feature test macros that don't pollute the global
>    namespace. The "simple solution" is not a good solution.
>    I believe our use of _MSC_EXTENSIONS is wrong anyway. It is controlled
>    by MSVC's /Ze and /Za flags, which do not relate to our -fms-extensions
>    flag.
>
How about you actually read my problem ?

this is not what I'm trying to solve.

The error I get is:
/usr/include/machine/_types.h:132:15: error: cannot combine with previous 'int'
declaration specifier
      typedef int                     __wchar_t;


and it's *because* -fms-extensions does define __wchar_t.

A solution is nowhere as short as the fragment you quote from the documentation.

We reserve the right to provide __wchar_t in modes other than -fms-extensions in future, or to sometimes not provide it in that mode, so using _MSC_EXTENSIONS for this is simply a mistake.

If you want to detect whether we provide a builtin __wchar_t, __is_identifier is the mechanism we provide for that. It doesn't make sense for us to add another.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...