Clang on Windows targeting gcc requirements

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Clang on Windows targeting gcc requirements

Edward Diener
For either the latest clang built from souce on Windows or a binary
distribution of clang on Windows it appears that clang expects the
supporting gcc include files and lib files to be in the hardcoded directory:

c:\mingw

and follow the mingw directory structure.

1) Can this please be changed in the future so that some environment
variable ( maybe CLANG_GCC ) can be set to the gcc installation rather
than use a hardcoded path ?

2) Can clang be updated to support the mingw-64 directory structure and
not just the mingw directory structure ? The mingw-64 distros seem now
to be the preferred gcc distributions on Windows and support the latest
versions of gcc.

Do I need to make these suggestions on the clang bug tracker for the
suggestions to be seriously considered ?u

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Yaron Keren

2015-06-25 10:46 GMT+03:00 Edward Diener <[hidden email]>:
For either the latest clang built from souce on Windows or a binary distribution of clang on Windows it appears that clang expects the supporting gcc include files and lib files to be in the hardcoded directory:

c:\mingw

and follow the mingw directory structure.

1) Can this please be changed in the future so that some environment variable ( maybe CLANG_GCC ) can be set to the gcc installation rather than use a hardcoded path ?

2) Can clang be updated to support the mingw-64 directory structure and not just the mingw directory structure ? The mingw-64 distros seem now to be the preferred gcc distributions on Windows and support the latest versions of gcc.

Do I need to make these suggestions on the clang bug tracker for the suggestions to be seriously considered ?u

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Edward Diener
On 6/25/2015 2:13 PM, Yaron Keren wrote:
> See http://reviews.llvm.org/D5268
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=YgSrUuiAhPt76cF_h_LXb8Mg84W8p9nMvUiL3koHKP4&s=aW_6t6KDGfo5hO6NiTn5Hy9afNhzwfkX-BZHT9PtXmk&e=>

I don't understand what the above link means, or how it is connected to
my suggestions below.

>
>
>
> 2015-06-25 10:46 GMT+03:00 Edward Diener
> <[hidden email]
> <mailto:[hidden email]>>:
>
>     For either the latest clang built from souce on Windows or a binary
>     distribution of clang on Windows it appears that clang expects the
>     supporting gcc include files and lib files to be in the hardcoded
>     directory:
>
>     c:\mingw
>
>     and follow the mingw directory structure.
>
>     1) Can this please be changed in the future so that some environment
>     variable ( maybe CLANG_GCC ) can be set to the gcc installation
>     rather than use a hardcoded path ?
>
>     2) Can clang be updated to support the mingw-64 directory structure
>     and not just the mingw directory structure ? The mingw-64 distros
>     seem now to be the preferred gcc distributions on Windows and
>     support the latest versions of gcc.
>
>     Do I need to make these suggestions on the clang bug tracker for the
>     suggestions to be seriously considered ?

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Yaron Keren
It's an uncommitted patch teaching clang to support the mingw-64 directory structure instead of the hardcoded c:\mingw. 


2015-06-26 0:13 GMT+03:00 Edward Diener <[hidden email]>:
On 6/25/2015 2:13 PM, Yaron Keren wrote:
See http://reviews.llvm.org/D5268
<https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=YgSrUuiAhPt76cF_h_LXb8Mg84W8p9nMvUiL3koHKP4&s=aW_6t6KDGfo5hO6NiTn5Hy9afNhzwfkX-BZHT9PtXmk&e=>

I don't understand what the above link means, or how it is connected to my suggestions below.




2015-06-25 10:46 GMT+03:00 Edward Diener
<[hidden email]
<mailto:[hidden email]>>:

    For either the latest clang built from souce on Windows or a binary
    distribution of clang on Windows it appears that clang expects the
    supporting gcc include files and lib files to be in the hardcoded
    directory:

    c:\mingw

    and follow the mingw directory structure.

    1) Can this please be changed in the future so that some environment
    variable ( maybe CLANG_GCC ) can be set to the gcc installation
    rather than use a hardcoded path ?

    2) Can clang be updated to support the mingw-64 directory structure
    and not just the mingw directory structure ? The mingw-64 distros
    seem now to be the preferred gcc distributions on Windows and
    support the latest versions of gcc.

    Do I need to make these suggestions on the clang bug tracker for the
    suggestions to be seriously considered ?

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Edward Diener
On 6/25/2015 5:53 PM, Yaron Keren wrote:
> It's an uncommitted patch teaching clang to support the mingw-64
> directory structure instead of the hardcoded c:\mingw.

Why is it "uncommitted" and not a part of clang source ?

What does supporting mingw-64 have to do with the hardcoded path c:\mingw ?

I do not understand how one obtains a patch from the link given, how one
applies the patch, and to what the patch is supposed to be applied ( but
I assume the patch is applied to the clang source somewhere ).

>
>
> 2015-06-26 0:13 GMT+03:00 Edward Diener
> <[hidden email]
> <mailto:[hidden email]>>:
>
>     On 6/25/2015 2:13 PM, Yaron Keren wrote:
>
>         See http://reviews.llvm.org/D5268
>         <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=-ZW8tznEmhb5NHese2XpJkBMuo2l_Omp4pNY90r31gU&s=H5rNcz_aIhE0PghyOY7-YGlv69ay3I3K9Ce6FABMqLI&e=>
>         <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=YgSrUuiAhPt76cF_h_LXb8Mg84W8p9nMvUiL3koHKP4&s=aW_6t6KDGfo5hO6NiTn5Hy9afNhzwfkX-BZHT9PtXmk&e=>
>
>
>     I don't understand what the above link means, or how it is connected
>     to my suggestions below.
>
>
>
>
>         2015-06-25 10:46 GMT+03:00 Edward Diener
>         <[hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>>:
>
>              For either the latest clang built from souce on Windows or
>         a binary
>              distribution of clang on Windows it appears that clang
>         expects the
>              supporting gcc include files and lib files to be in the
>         hardcoded
>              directory:
>
>              c:\mingw
>
>              and follow the mingw directory structure.
>
>              1) Can this please be changed in the future so that some
>         environment
>              variable ( maybe CLANG_GCC ) can be set to the gcc installation
>              rather than use a hardcoded path ?
>
>              2) Can clang be updated to support the mingw-64 directory
>         structure
>              and not just the mingw directory structure ? The mingw-64
>         distros
>              seem now to be the preferred gcc distributions on Windows and
>              support the latest versions of gcc.
>
>              Do I need to make these suggestions on the clang bug
>         tracker for the
>              suggestions to be seriously considered ?
>
>
>     _______________________________________________
>     cfe-dev mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Nikola Smiljanic

Why is it "uncommitted" and not a part of clang source ?


Because it hasn't been reviewed.
 
What does supporting mingw-64 have to do with the hardcoded path c:\mingw ?


Clang driver has no official support for mingw. Just a bunch of hardcoded paths in the current driver. They break whenever new version of mingw is released as version numbers are hardcoded as well. They also don't work for mingw-w64 which as far as I know is more active than the original mingw project.
 
I do not understand how one obtains a patch from the link given, how one applies the patch, and to what the patch is supposed to be applied ( but I assume the patch is applied to the clang source somewhere ).


Download raw diff will give you a patch file. You apply it to your local clang directory.

 


2015-06-26 0:13 GMT+03:00 Edward Diener
<[hidden email]
<mailto:[hidden email]>>:

    On 6/25/2015 2:13 PM, Yaron Keren wrote:

        See http://reviews.llvm.org/D5268
        <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=-ZW8tznEmhb5NHese2XpJkBMuo2l_Omp4pNY90r31gU&s=H5rNcz_aIhE0PghyOY7-YGlv69ay3I3K9Ce6FABMqLI&e=>
        <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=YgSrUuiAhPt76cF_h_LXb8Mg84W8p9nMvUiL3koHKP4&s=aW_6t6KDGfo5hO6NiTn5Hy9afNhzwfkX-BZHT9PtXmk&e=>


    I don't understand what the above link means, or how it is connected
    to my suggestions below.




        2015-06-25 10:46 GMT+03:00 Edward Diener
        <[hidden email]
        <mailto:[hidden email]>
        <mailto:[hidden email]

        <mailto:[hidden email]>>>:

             For either the latest clang built from souce on Windows or
        a binary
             distribution of clang on Windows it appears that clang
        expects the
             supporting gcc include files and lib files to be in the
        hardcoded
             directory:

             c:\mingw

             and follow the mingw directory structure.

             1) Can this please be changed in the future so that some
        environment
             variable ( maybe CLANG_GCC ) can be set to the gcc installation
             rather than use a hardcoded path ?

             2) Can clang be updated to support the mingw-64 directory
        structure
             and not just the mingw directory structure ? The mingw-64
        distros
             seem now to be the preferred gcc distributions on Windows and
             support the latest versions of gcc.

             Do I need to make these suggestions on the clang bug
        tracker for the
             suggestions to be seriously considered ?


    _______________________________________________
    cfe-dev mailing list
    [hidden email]
    <mailto:[hidden email]>
    http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Edward Diener
On 6/25/2015 8:38 PM, Nikola Smiljanic wrote:
>
>     Why is it "uncommitted" and not a part of clang source ?
>
>
> Because it hasn't been reviewed.

Does it normally take 9 months or more to review a fix ?

>
>     What does supporting mingw-64 have to do with the hardcoded path
>     c:\mingw ?
>
>
> Clang driver has no official support for mingw. Just a bunch of
> hardcoded paths in the current driver. They break whenever new version
> of mingw is released as version numbers are hardcoded as well.

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.

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 ?

> They also
> don't work for mingw-w64 which as far as I know is more active than the
> original mingw project.

I would be glad if this patch fixes that problem, since the latest
mingw-64 gcc release is gcc-5.1.

>
>     I do not understand how one obtains a patch from the link given, how
>     one applies the patch, and to what the patch is supposed to be
>     applied ( but I assume the patch is applied to the clang source
>     somewhere ).
>
>
> Download raw diff will give you a patch file. You apply it to your local
> clang directory.

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 ?

>
>
>
>         2015-06-26 0:13 GMT+03:00 Edward Diener
>         <[hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>>:
>
>              On 6/25/2015 2:13 PM, Yaron Keren wrote:
>
>                  See http://reviews.llvm.org/D5268
>         <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=dNG3HyoQulGecFyfZq24HIDVGy-_A5H4qJp4V__relo&s=3WB_bki2U9CTir99F85AJMt8_X9chUNsZXHHTVETX7Y&e=>
>
>         <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=-ZW8tznEmhb5NHese2XpJkBMuo2l_Omp4pNY90r31gU&s=H5rNcz_aIhE0PghyOY7-YGlv69ay3I3K9Ce6FABMqLI&e=>
>
>         <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=YgSrUuiAhPt76cF_h_LXb8Mg84W8p9nMvUiL3koHKP4&s=aW_6t6KDGfo5hO6NiTn5Hy9afNhzwfkX-BZHT9PtXmk&e=>
>
>
>              I don't understand what the above link means, or how it is
>         connected
>              to my suggestions below.
>
>
>
>
>                  2015-06-25 10:46 GMT+03:00 Edward Diener
>
>         <[hidden email]
>         <mailto:[hidden email]>
>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>
>
>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>>>:
>
>                       For either the latest clang built from souce on
>         Windows or
>                  a binary
>                       distribution of clang on Windows it appears that clang
>                  expects the
>                       supporting gcc include files and lib files to be
>         in the
>                  hardcoded
>                       directory:
>
>                       c:\mingw
>
>                       and follow the mingw directory structure.
>
>                       1) Can this please be changed in the future so
>         that some
>                  environment
>                       variable ( maybe CLANG_GCC ) can be set to the gcc
>         installation
>                       rather than use a hardcoded path ?
>
>                       2) Can clang be updated to support the mingw-64
>         directory
>                  structure
>                       and not just the mingw directory structure ? The
>         mingw-64
>                  distros
>                       seem now to be the preferred gcc distributions on
>         Windows and
>                       support the latest versions of gcc.
>
>                       Do I need to make these suggestions on the clang bug
>                  tracker for the
>                       suggestions to be seriously considered ?
>
>
>              _______________________________________________
>              cfe-dev mailing list
>         [hidden email]
>         <mailto:[hidden email]>
>              <mailto:[hidden email]
>         <mailto:[hidden email]>>
>         http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
>
>         _______________________________________________
>         cfe-dev mailing list
>         [hidden email]
>         <mailto:[hidden email]>
>         http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
>     _______________________________________________
>     cfe-dev mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Nikola Smiljanic

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

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

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.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Edward Diener
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
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Matthew Faithfull
In reply to this post by Edward Diener
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" <[hidden email]>
To: <[hidden email]>
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
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Sebastian Redl
In reply to this post by Edward Diener


On 26.06.2015 10:40, [hidden email] wrote:
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?
AFAIK they're not, only the IntelliSense system is. Where did you hear this?

Sebastian

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Matthew Faithfull
In reply to this post by Edward Diener
I looked into this ~18 months ago when I discovered that BoostPP disables variadic macros under the VS 2013 preprocessor even though compiler v120 officially supports them.
The combination of having both MSC_VER and __EDG__ defined was not correctly handled.
Given that __EDG__ is an automatic predefine on this compiler I guessed Microsoft had switched to EDG. They won't confirm it of course. The closest I could get was confirmation from MS that this compiler does have a new preprocessor front end and from EDG that they are supplying CPP front ends to Microsoft.
The end result is the same. I'm not sure that the VS CPP is as broken as it appears. Other than this bug I've had no trouble with BoostPP under MinGW clang or Visual Studio.


----- Reply message -----
From: "Sebastian Redl" <[hidden email]>
To: <[hidden email]>
Subject: [cfe-dev] Clang on Windows targeting gcc requirements
Date: Fri, Jun 26, 2015 10:32



On 26.06.2015 10:40, [hidden email] wrote:
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?
AFAIK they're not, only the IntelliSense system is. Where did you hear this?

Sebastian

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Nikola Smiljanic
In reply to this post by Nikola Smiljanic
Adding back cfe-dev

On Fri, Jun 26, 2015 at 6:57 PM, Paul A. Bristow <[hidden email]> wrote:

I think that you are very mistaken here – there are *lots* of Boost developers and users who wish to confirm that their Boost libraries and other programs work wishing to compile with Clang under Windows. This means using mingw – or very much preferably mingw-w64.

 

It is absurd to have to install *both* at present to get the Windows builds of Clang (and GCC).  And there is the pit of making sure that mingw is called *first* in one’s PATH – a pit into which I have painfully fallen.

 

Meanwhile all testing using Clang is being done using a separate *nix machine, an unnecessary complication.

 

*Please* can we have this sorted out asap!

 

Thanks

 

Paul



It's unlikely to happen without people who want it stepping up to get things rolling. 

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Nikola Smiljanic
In reply to this post by Edward Diener
I'm pretty sure they only use EDG for IntelliSense, I'm still seeing code that compiles fine with VC++ and shows errors from IntelliSense. 

Once they decide to get a new frontend I'm sure they'll choose Clang :P

On Fri, Jun 26, 2015 at 8:46 PM, [hidden email] <[hidden email]> wrote:
I looked into this ~18 months ago when I discovered that BoostPP disables variadic macros under the VS 2013 preprocessor even though compiler v120 officially supports them.
The combination of having both MSC_VER and __EDG__ defined was not correctly handled.
Given that __EDG__ is an automatic predefine on this compiler I guessed Microsoft had switched to EDG. They won't confirm it of course. The closest I could get was confirmation from MS that this compiler does have a new preprocessor front end and from EDG that they are supplying CPP front ends to Microsoft.
The end result is the same. I'm not sure that the VS CPP is as broken as it appears. Other than this bug I've had no trouble with BoostPP under MinGW clang or Visual Studio.


----- Reply message -----
From: "Sebastian Redl" <[hidden email]>
To: <[hidden email]>
Subject: [cfe-dev] Clang on Windows targeting gcc requirements
Date: Fri, Jun 26, 2015 10:32



On 26.06.2015 10:40, [hidden email] wrote:
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?
AFAIK they're not, only the IntelliSense system is. Where did you hear this?

Sebastian

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Matthew Faithfull
In reply to this post by Edward Diener
It's quite possible that it's a bug on the MS side, although a strange one to have __EDG__ predefined in the main preprocessor if it's not the same as the intellisense one. 
It would be useful to know if the definition is still there in the VS2015 toolchain.
It has been too long since I dug into this and I have other things cooking at the moment so probably best if I leave it in Edward's capable hands.


----- Reply message -----
From: "Nikola Smiljanic" <[hidden email]>
To: "[hidden email]" <[hidden email]>
Cc: "Sebastian Redl" <[hidden email]>, "cfe-dev Developers" <[hidden email]>
Subject: [cfe-dev] Clang on Windows targeting gcc requirements
Date: Fri, Jun 26, 2015 12:00

I'm pretty sure they only use EDG for IntelliSense, I'm still seeing code that compiles fine with VC++ and shows errors from IntelliSense. 

Once they decide to get a new frontend I'm sure they'll choose Clang :P

On Fri, Jun 26, 2015 at 8:46 PM, [hidden email] <[hidden email]> wrote:
I looked into this ~18 months ago when I discovered that BoostPP disables variadic macros under the VS 2013 preprocessor even though compiler v120 officially supports them.
The combination of having both MSC_VER and __EDG__ defined was not correctly handled.
Given that __EDG__ is an automatic predefine on this compiler I guessed Microsoft had switched to EDG. They won't confirm it of course. The closest I could get was confirmation from MS that this compiler does have a new preprocessor front end and from EDG that they are supplying CPP front ends to Microsoft.
The end result is the same. I'm not sure that the VS CPP is as broken as it appears. Other than this bug I've had no trouble with BoostPP under MinGW clang or Visual Studio.


----- Reply message -----
From: "Sebastian Redl" <[hidden email]>
To: <[hidden email]>
Subject: [cfe-dev] Clang on Windows targeting gcc requirements
Date: Fri, Jun 26, 2015 10:32



On 26.06.2015 10:40, [hidden email] wrote:
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?
AFAIK they're not, only the IntelliSense system is. Where did you hear this?

Sebastian

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Nikola Smiljanic
In reply to this post by Edward Diener
http://webcompiler.cloudapp.net/ is down atm but vc++ at http://rextester.com/runcode (it should be 2013) doesn't define __EDG__.

On Fri, Jun 26, 2015 at 10:02 PM, [hidden email] <[hidden email]> wrote:
It's quite possible that it's a bug on the MS side, although a strange one to have __EDG__ predefined in the main preprocessor if it's not the same as the intellisense one. 
It would be useful to know if the definition is still there in the VS2015 toolchain.
It has been too long since I dug into this and I have other things cooking at the moment so probably best if I leave it in Edward's capable hands.


----- Reply message -----
From: "Nikola Smiljanic" <[hidden email]>
To: "[hidden email]" <[hidden email]>
Cc: "Sebastian Redl" <[hidden email]>, "cfe-dev Developers" <[hidden email]>
Subject: [cfe-dev] Clang on Windows targeting gcc requirements
Date: Fri, Jun 26, 2015 12:00

I'm pretty sure they only use EDG for IntelliSense, I'm still seeing code that compiles fine with VC++ and shows errors from IntelliSense. 

Once they decide to get a new frontend I'm sure they'll choose Clang :P

On Fri, Jun 26, 2015 at 8:46 PM, [hidden email] <[hidden email]> wrote:
I looked into this ~18 months ago when I discovered that BoostPP disables variadic macros under the VS 2013 preprocessor even though compiler v120 officially supports them.
The combination of having both MSC_VER and __EDG__ defined was not correctly handled.
Given that __EDG__ is an automatic predefine on this compiler I guessed Microsoft had switched to EDG. They won't confirm it of course. The closest I could get was confirmation from MS that this compiler does have a new preprocessor front end and from EDG that they are supplying CPP front ends to Microsoft.
The end result is the same. I'm not sure that the VS CPP is as broken as it appears. Other than this bug I've had no trouble with BoostPP under MinGW clang or Visual Studio.


----- Reply message -----
From: "Sebastian Redl" <[hidden email]>
To: <[hidden email]>
Subject: [cfe-dev] Clang on Windows targeting gcc requirements
Date: Fri, Jun 26, 2015 10:32



On 26.06.2015 10:40, [hidden email] wrote:
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?
AFAIK they're not, only the IntelliSense system is. Where did you hear this?

Sebastian

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Matthew Faithfull
In reply to this post by Edward Diener
The appearance is that you are correct. Leaves me with no explanation at all for why variadics are disabled in my port of BoostPP but for now feel free to ignore me. 
I may yet find out what it is that is still broken in the VS CPP. I'll keep listening.
:-¿

----- Reply message -----
From: "Nikola Smiljanic" <[hidden email]>
To: "[hidden email]" <[hidden email]>
Cc: "Sebastian Redl" <[hidden email]>, "cfe-dev Developers" <[hidden email]>
Subject: [cfe-dev] Clang on Windows targeting gcc requirements
Date: Fri, Jun 26, 2015 13:18

http://webcompiler.cloudapp.net/ is down atm but vc++ at http://rextester.com/runcode (it should be 2013) doesn't define __EDG__.

On Fri, Jun 26, 2015 at 10:02 PM, [hidden email] <[hidden email]> wrote:
It's quite possible that it's a bug on the MS side, although a strange one to have __EDG__ predefined in the main preprocessor if it's not the same as the intellisense one. 
It would be useful to know if the definition is still there in the VS2015 toolchain.
It has been too long since I dug into this and I have other things cooking at the moment so probably best if I leave it in Edward's capable hands.


----- Reply message -----
From: "Nikola Smiljanic" <[hidden email]>
To: "[hidden email]" <[hidden email]>
Cc: "Sebastian Redl" <[hidden email]>, "cfe-dev Developers" <[hidden email]>
Subject: [cfe-dev] Clang on Windows targeting gcc requirements
Date: Fri, Jun 26, 2015 12:00

I'm pretty sure they only use EDG for IntelliSense, I'm still seeing code that compiles fine with VC++ and shows errors from IntelliSense. 

Once they decide to get a new frontend I'm sure they'll choose Clang :P

On Fri, Jun 26, 2015 at 8:46 PM, [hidden email] <[hidden email]> wrote:
I looked into this ~18 months ago when I discovered that BoostPP disables variadic macros under the VS 2013 preprocessor even though compiler v120 officially supports them.
The combination of having both MSC_VER and __EDG__ defined was not correctly handled.
Given that __EDG__ is an automatic predefine on this compiler I guessed Microsoft had switched to EDG. They won't confirm it of course. The closest I could get was confirmation from MS that this compiler does have a new preprocessor front end and from EDG that they are supplying CPP front ends to Microsoft.
The end result is the same. I'm not sure that the VS CPP is as broken as it appears. Other than this bug I've had no trouble with BoostPP under MinGW clang or Visual Studio.


----- Reply message -----
From: "Sebastian Redl" <[hidden email]>
To: <[hidden email]>
Subject: [cfe-dev] Clang on Windows targeting gcc requirements
Date: Fri, Jun 26, 2015 10:32



On 26.06.2015 10:40, [hidden email] wrote:
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?
AFAIK they're not, only the IntelliSense system is. Where did you hear this?

Sebastian

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Edward Diener
In reply to this post by Nikola Smiljanic
On 6/26/2015 6:58 AM, Nikola Smiljanic wrote:

> Adding back cfe-dev
>
> On Fri, Jun 26, 2015 at 6:57 PM, Paul A. Bristow
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I think that you are very mistaken here – there are **lots** of
>     Boost developers and users who wish to confirm that their Boost
>     libraries and other programs work wishing to compile with Clang
>     under Windows. This means using mingw – or very much preferably
>     mingw-w64. ____
>
>     __ __
>
>     It is absurd to have to install **both** at present to get the
>     Windows builds of Clang (and GCC).  And there is the pit of making
>     sure that mingw is called **first** in one’s PATH – a pit into which
>     I have painfully fallen.____
>
>     __ __
>
>     Meanwhile all testing using Clang is being done using a separate
>     *nix machine, an unnecessary complication.____
>
>     __ __
>
>     **Please** can we have this sorted out asap!____
>
>     __ __
>
>     Thanks____
>
>     __ __
>
>     Paul____
>
>
>
> It's unlikely to happen without people who want it stepping up to get
> things rolling.

I don't know where Paul Bristow's comments are coming from ( I don't see
them in this mailing list recently anywhere ) but he has recently
attempted to get clang on Windows targeting gcc working and has gotten
help for it on the Boost developers mailing list.

I just want to concur with his assertion that having the ability to use
a mingw-64 distro, rather than just a mingw distro, is important for
Boost testing using clang on Windows. Also the issue of hardcoded
locations for clang on Windows targeting gcc, while not as important,
seems like an issue that clang developers could solve either through
some command-line parameter or environment variable.

I still don't know why users of clang are expected to step up to get
these issues addressed. Don't clang developers consider this an issue of
any importance ? Last I heard Windows was still be used vastly more than
Linux and/or Mac combined in the world. I also use Linux and have no
prejudices against it, but like many developers find Windows more
developer friendly overall.

Unlike Paul I do understand why clang uses gcc's headers and RTL ( aka
libstdc++ ). What I have always failed to understand is why, this being
the case, clang has so little documentation on the relationship of any
particular clang release to the particular underlying gcc releases with
which clang can work. Similarly, as I understand it, clang can use
libc++ instead of libstdc++. But again under Windows there is no
documentation on how this may be done. In general the porting of clang
to Windows, while working fine if everything is setup correctly, seems
like almost an afterthought for clang developers.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Nikola Smiljanic
I don't know where Paul Bristow's comments are coming from ( I don't see them in this mailing list recently anywhere ) but he has recently attempted to get clang on Windows targeting gcc working and has gotten help for it on the Boost developers mailing list.
 
He replied only to my email and didn't include cfe-dev.
 
I still don't know why users of clang are expected to step up to get these issues addressed. Don't clang developers consider this an issue of any importance ? Last I heard Windows was still be used vastly more than Linux and/or Mac combined in the world. I also use Linux and have no prejudices against it, but like many developers find Windows more developer friendly overall.
 
I'm starting to repeat myself, there's no "clang developers" in the sense you understand. There's people employed by companies and paid to work on stuff those companies find important. Chromium team cares about Windows support the most and as far as I know they're the main contributors for VC++ ABI stuff. The open source community (clang developers) would love to have Clang working seamlessly on Windows but haven't had the time to address it. There needs to be someone to drive this effort and we don't really have that someone right now. So whoever finds these issues important can either step up or wait for someone else to get this done, when and if they get to it.
 
Unlike Paul I do understand why clang uses gcc's headers and RTL ( aka libstdc++ ). What I have always failed to understand is why, this being the case, clang has so little documentation on the relationship of any particular clang release to the particular underlying gcc releases with which clang can work. Similarly, as I understand it, clang can use libc++ instead of libstdc++. But again under Windows there is no documentation on how this may be done. In general the porting of clang to Windows, while working fine if everything is setup correctly, seems like almost an afterthought for clang developers.
  
We went through this documentation issue in the other thread. As for libc++ on Windows, it's not much different from anything else, it's not officially supported because nobody cared enough to get it working. There's been a few efforts, you can search the mailing list, I don't know the exact details, I think someone recently asked about it.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows targeting gcc requirements

Edward Diener
In reply to this post by Yaron Keren
On 6/25/2015 2:13 PM, Yaron Keren wrote:
> See http://reviews.llvm.org/D5268
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=YgSrUuiAhPt76cF_h_LXb8Mg84W8p9nMvUiL3koHKP4&s=aW_6t6KDGfo5hO6NiTn5Hy9afNhzwfkX-BZHT9PtXmk&e=>

I can see that the patch has been applied officially to the latest clang
source. It's in the latest code when I update llvm/clang. Thanks very much !

But how do I use it ?

Am I supposed to be able to build clang using a mingw-64 distro in my PATH ?

When I compile with clang how do I tell it to use the mingw-64 headers
and RTL ? Does it matter whether the mingw-64 distro is 32 bit or 64 bit ?

Do I need to have the mingw-64 distro at c:\mingw ?

I am willing to test this for clang and report back results here, since
I can easily switch between mingw-64 distros ( 4.8.4, 4.9.2, 5.1 ) and I
test a number of Boost libraries including my own with clang, but I need
a little information on how to do it.

>
>
>
> 2015-06-25 10:46 GMT+03:00 Edward Diener
> <[hidden email]
> <mailto:[hidden email]>>:
>
>     For either the latest clang built from souce on Windows or a binary
>     distribution of clang on Windows it appears that clang expects the
>     supporting gcc include files and lib files to be in the hardcoded
>     directory:
>
>     c:\mingw
>
>     and follow the mingw directory structure.
>
>     1) Can this please be changed in the future so that some environment
>     variable ( maybe CLANG_GCC ) can be set to the gcc installation
>     rather than use a hardcoded path ?
>
>     2) Can clang be updated to support the mingw-64 directory structure
>     and not just the mingw directory structure ? The mingw-64 distros
>     seem now to be the preferred gcc distributions on Windows and
>     support the latest versions of gcc.
>
>     Do I need to make these suggestions on the clang bug tracker for the
>     suggestions to be seriously considered ?u


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
123