Marc Espie via llvm-dev
2017-May-12 10:28 UTC
[llvm-dev] problem (and fix) with -fms-extensions
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.
Dimitry Andric via llvm-dev
2017-May-12 12:35 UTC
[llvm-dev] problem (and fix) with -fms-extensions
On 12 May 2017, at 12:28, Marc Espie <espie at nerim.net> wrote:> > 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:...>>> + 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.Another option, which works right away, without having to modify any compiler, is to just define it on the command line, e.g. use: -fms-extensions -D__ms_extensions__ -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/4c8bce0b/attachment.sig>
Marc Espie via llvm-dev
2017-May-12 12:58 UTC
[llvm-dev] problem (and fix) with -fms-extensions
On Fri, May 12, 2017 at 02:35:21PM +0200, Dimitry Andric wrote:> On 12 May 2017, at 12:28, Marc Espie <espie at nerim.net> wrote: > > > > 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: > ... > >>> + 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. > > Another option, which works right away, without having to modify any > compiler, is to just define it on the command line, e.g. use: > -fms-extensions -D__ms_extensions__Let's make it clear, I'm not looking for a work-around, I'm looking for a way to fix things out-of-the-box. Having a "by default" define means we can fix the includes once and for all, and have clang -fms-extensions work out-of-the-box without any configure magic. People who deal with portable code know the pain of having some code that doesn't work on YOUR system because it requires one extra step that the people upstream don't know about, so you have to make a patch, pass it upstream... and often have things fail again down the line because upstream dropped your change because no-one there knew what it was for. Or try to figure out where you can inject the patch in some crazy build system you have never worked with, and that actively fights you all the way... Just to make it clear where I'm coming from, over the past few weeks, I've fixed about 200 stupid configury bugs for clang, between the stuff that put int main(int argc, char *argv[]) in configure.ac, the stuff that asserts that $(CC) -Wwhatever works since the compiler didn't error out, the crazy mingw build shell script that won't insert -fgnu89-inline just for the gcc3.4 bootstrap stage, or python2.7 that by default disables multibyte functions required for __bsd_locale_fallbacks.h ...