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

[Marc Espie via llvm-dev]

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 ...