llvm dev - May 2017 - problem (and fix) with -fms-extensions

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");
-------------- next part --------------
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");

On 11 May 2017, at 20:04, Marc Espie via llvm-dev <llvm-dev at
lists.llvm.org> 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.
Back in 2014 when we encountered this in FreeBSD, we just renamed our
internal type to ___wchar_t instead:

http://svnweb.freebsd.org/changeset/base/263998

> 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");
Looks fine to me, though you would also have to convince the gcc authors
to do the same.  (That is, if you still want to use recent gcc's... :)

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170512/ba0047ed/attachment.sig>

On Fri, May 12, 2017 at 12:01:35PM +0200, Dimitry Andric
wrote:
> On 11 May 2017, at 20:04, Marc Espie via llvm-dev <llvm-dev at
lists.llvm.org> 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.
> 
> Back in 2014 when we encountered this in FreeBSD, we just renamed our
> internal type to ___wchar_t instead:
> 
> http://svnweb.freebsd.org/changeset/base/263998
> 
> 
> > 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");
> 
> Looks fine to me, though you would also have to convince the gcc authors
> to do the same.  (That is, if you still want to use recent gcc's... :)
Well, the licence means we care a little less about gcc for obvious reasons.
Working with the llvm/clang community makes more sense for us.

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 <
llvm-dev at lists.llvm.org> 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
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170512/48d28c9a/attachment.html>