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

Marc Espie via llvm-dev llvm-dev at lists.llvm.org
Fri May 12 03:28:50 PDT 2017


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.


More information about the llvm-dev mailing list