[cfe-dev] Clang on Windows targeting gcc requirements

mfaithfull@btopenworld.com mfaithfull at btopenworld.com
Fri Jun 26 01:40:19 PDT 2015

Interesting note on Boost PP. I'm not sure why VC++ is still broken given that they have been using EDG front end since 2013?
I have a Boost PP port which seems happy under MinGW GCC, Clang and VC++ on Windows though I don't have anything like a full test suite to prove correctness.
The only issue I know of is Boost PP disables variadic macros on the assumption that being MSVC they're not available but actually __EDG__ is defined and they should be enabled. The definition ordering is tricky and I haven't worked out a fix yet.

All information at least 6 months old so apologies if I'm out of date.  I've been out the game for months. Haven't touched any code. Don't even have fixed line internet till tomorrow.

----- Reply message -----
From: "Edward Diener" <eldlistmailingz at tropicsoft.com>
To: <cfe-dev at cs.uiuc.edu>
Subject: [cfe-dev] Clang on Windows targeting gcc requirements
Date: Fri, Jun 26, 2015 08:53

On 6/25/2015 11:34 PM, Nikola Smiljanic wrote:
>     Does it normally take 9 months or more to review a fix ?
> Normally no, but not many people are interested in mingw which is why we
> don't have proper driver support in the first place.

It does not sound like clang on Windows targeting gcc is very important to clang. That's a shame because clang on Windows targeting VC++ has no priority on Boost and only clang on Windows targeting gcc gets Boost testing. The main reason for that, as I have pointed out in the past, is that Boost PP library can't be bothered trying to emulate clang's version of VC++'s broken preprocessor, whereas clang on Windows targeting gcc provides a C++ standard conforming preprocessor.

> People who review
> are pretty busy so it's patch authors responsibility to remind them,
> it's unfortunate but we've had many patches lost this way. I send pings
> every week or so for my patches that go unreviewed.
>     The hardcoded paths clang currently uses all appear to be off of
>     c:\mingw.
>     It does not appear to be the case that version numbers are
>     hardcoded. I can test the clang binaries for clang-3.4.1,
>     clang-3.5.2, clang-3.6.1, and the latest clang-3.7 built from source
>     all against the latest mingw distribution, which uses gcc-4.8.1, and
>     is linked to from c:\mingw without any problems. If each clang
>     release hardcoded the mingw version, by which I am guessing you mean
>     of course the gcc version, it is doubtful that all the different
>     clang releases I mentioned would work with the gcc-4.8.1 release.
> Have a look at InitHeaderSearch.cpp, it has a list of mingw versions,
> and as you point out paths start with c:/mingw

I will look at it.

>     If this fix removes the hardcoded c:\mingw path when searching for a
>     gcc distro to use, how does the end-user tell clang where the gcc
>     distro he wants to use with clang resides ?
> I can't answer this one.

Perhaps the patch is only for support of mingw-64 as the gcc target but the reliance on c:\mingw remains. Support for mingw-64 is nevertheless a large step in the right direction since mingw-64 is the the mingw distro of choice for many Windows programmers using gcc. Linking c:\mingw to a mingw-64 distro is easy but it would really be better if there were some way to point to the mingw-64 distro you want to have clang use when invoking clang rather than relying on a hardcoded path.

>     I gather then that the patch file is a subversion patch file. From
>     where in the llvm tree do I apply the patch ? How do I know that the
>     patch will work with the latest llvm/clang source I have updated
>     from the llvm/clang sunversion repositories ? Or is the patch only
>     valid for a particular version of clang and not the latest version
>     from source ?
> It's either svn or git patch, you're supposed to apply it to clang
> checkout/clone.

Does llvm/clang have a git interface ? I assumed that subversion is still being used. I have found that git is a more flexible SCCS than subversion but the latter is still quite usable.

> That would be llvm/tools/clang for a usual in-tree
> setup. As with any other patch, it was generated from specific source
> version, but since this code doesn't change too much you should be able
> to apply it cleanly to trunk with a little bit of luck.

I will checkout a separate version of the latest llvm/clang to try it out. I don't like messing up my normal clang source build on Windows by applying patches and then worrying that each new update to llvm/clang is going to conflict with a patch.

> If you'd like to get this checked in, email patch authors, give hand
> testing/reviewing the patch and try to get things rolling, it's been a
> while since last comment in the review.

I will do my best but I am really surprised that the clang/Windows/gcc version of clang doesn't get much attention among clang development.

cfe-dev mailing list
cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150626/95f43506/attachment.html>

More information about the cfe-dev mailing list