Quantcast

[regression runner] Preference libstdc++ vs. libc++

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
I have a bunch of linux regression runners that are executing clang runs of
the boost regression suite (clang 3.0 - 4.0), currently these are all using
the default, GCC libstdc++. Is there an interest from developers to see
these runs with libc++?

The basic options:

1) Convert all compatible clang builds to libc++, don't mess with libstdc++
& clang.
2) Duplicate all the clang builds to build each version with both
(acknowledging that will add nearly 1/3 to the already large ~125 linux
runs).
3) Change most of the runs, but keep a few token libstdc++ & clang runs,
with the latest compiler version (what c++ standard c++14? c++1z?).
4) Just add a few token libc++ runs, with the latest compiler version (what
c++ standard c++14? c++1z?).
5) Don't add libc++.

For background (you can respond to one of the above preferences without
reading on), there are two machines constantly running linux builds (in
addition to the two windows ones) that I manage.

One I consider the "full" suite of compilers. It runs clang 3.0 - 4.0 and
gcc 4.4 - 6. For the oldest and latest releas (gcc 4.4, gcc 6, clang 3.0,
clang 3.9), I run all the supported standard configs I could find (c++98,
c++0x, gnu98, gnu0x -- c++03, c++11, c++14, c++1z and their gnu
equivalents). I also do runs with optimization and warnings cranked,
against the latest standard config e.g. "-std=c++1z -O2". For all the
compiler versions that aren't on the endcaps, I just run a single config
with whatever was the latest standard config for that compiler (e.g.
gcc-4.8 with c++1y). This is all repeated for develop and master for a
total of about 100 different configurations.

The machine I consider the "fast results" machine is configured with only
four runs, one each for the latest release of gcc and clang  with the
latest supported standard config (currently gcc-6 1z and clang-3.9 1z), for
both master and develop. The goal here is that for any change checked in,
the author will have feedback on its success against something modern and
relevant within just a few hours.

As a backup to the "fast results" machine, I also run those four regression
modern runs, interspersed with the rest of the configs every dozen or so
runs, bringing the total number of runs on the "full" machine up to around
125, which takes about a week for the machine to get through all the
configurations.

You can see more details about all of this on the github page where I keep
my regression build scripts:
https://github.com/teeks99/boost-build/tree/master/Regression

The actual confgs run by the "full":
https://github.com/teeks99/boost-build/blob/master/
Regression/teeks99-02/machine_vars.json

The docker builds for all these machine configurations are kept at:
https://github.com/teeks99/boost-build/tree/master/Docker
And can be pulled from the docker hub with e.g. `docker pull
teeks99/boost-build:clang-3.9`

If you've read this far, I'd be happy for any other opinions from
developers who use the test matrix. Is it worth keeping all those compilers
in the middle? Do we need to test the latest compilers with all the
different standard configs (03, 11, 14, 1z + gnu equivalents)?

Thanks,
Tom

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
On 3/6/2017 5:50 PM, Tom Kent via Boost wrote:

> I have a bunch of linux regression runners that are executing clang runs of
> the boost regression suite (clang 3.0 - 4.0), currently these are all using
> the default, GCC libstdc++. Is there an interest from developers to see
> these runs with libc++?
>
> The basic options:
>
> 1) Convert all compatible clang builds to libc++, don't mess with libstdc++
> & clang.
> 2) Duplicate all the clang builds to build each version with both
> (acknowledging that will add nearly 1/3 to the already large ~125 linux
> runs).
> 3) Change most of the runs, but keep a few token libstdc++ & clang runs,
> with the latest compiler version (what c++ standard c++14? c++1z?).
> 4) Just add a few token libc++ runs, with the latest compiler version (what
> c++ standard c++14? c++1z?).
> 5) Don't add libc++.
>
> For background (you can respond to one of the above preferences without
> reading on), there are two machines constantly running linux builds (in
> addition to the two windows ones) that I manage.

There is no libc++ on Windows AFAIK. The clang compiler seems always to
have worked pretty good with libstdc++, so I do not think these tests
should be dropped. I am for 4) because I do not think that many earlier
versions of clang supported libc++ ( I could be wrong ), but you can
certainly add tests for clang 3.8 and up for using libc++.

>
> One I consider the "full" suite of compilers. It runs clang 3.0 - 4.0 and
> gcc 4.4 - 6. For the oldest and latest releas (gcc 4.4, gcc 6, clang 3.0,
> clang 3.9), I run all the supported standard configs I could find (c++98,
> c++0x, gnu98, gnu0x -- c++03, c++11, c++14, c++1z and their gnu
> equivalents). I also do runs with optimization and warnings cranked,
> against the latest standard config e.g. "-std=c++1z -O2". For all the
> compiler versions that aren't on the endcaps, I just run a single config
> with whatever was the latest standard config for that compiler (e.g.
> gcc-4.8 with c++1y). This is all repeated for develop and master for a
> total of about 100 different configurations.
>
> The machine I consider the "fast results" machine is configured with only
> four runs, one each for the latest release of gcc and clang  with the
> latest supported standard config (currently gcc-6 1z and clang-3.9 1z), for
> both master and develop. The goal here is that for any change checked in,
> the author will have feedback on its success against something modern and
> relevant within just a few hours.
>
> As a backup to the "fast results" machine, I also run those four regression
> modern runs, interspersed with the rest of the configs every dozen or so
> runs, bringing the total number of runs on the "full" machine up to around
> 125, which takes about a week for the machine to get through all the
> configurations.
>
> You can see more details about all of this on the github page where I keep
> my regression build scripts:
> https://github.com/teeks99/boost-build/tree/master/Regression
>
> The actual confgs run by the "full":
> https://github.com/teeks99/boost-build/blob/master/
> Regression/teeks99-02/machine_vars.json
>
> The docker builds for all these machine configurations are kept at:
> https://github.com/teeks99/boost-build/tree/master/Docker
> And can be pulled from the docker hub with e.g. `docker pull
> teeks99/boost-build:clang-3.9`
>
> If you've read this far, I'd be happy for any other opinions from
> developers who use the test matrix. Is it worth keeping all those compilers
> in the middle? Do we need to test the latest compilers with all the
> different standard configs (03, 11, 14, 1z + gnu equivalents)?

Do any Boost libraries really target gnu features, if they exist, that
are not in the corresponding c++ level ? If not there is no reason to
test the gnu levels and the c++ levels seem just fine. I know that I do
not specifically test gnu levels but c++ levels instead when I run local
tests.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
> Do any Boost libraries really target gnu features, if they exist, that
> are not in the corresponding c++ level ?

There are compiler-specific macros for things like forced inlining. Not
sure if that's what you mean.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Mar 7, 2017 at 1:50 AM, Tom Kent via Boost
<[hidden email]> wrote:

> I have a bunch of linux regression runners that are executing clang runs of
> the boost regression suite (clang 3.0 - 4.0), currently these are all using
> the default, GCC libstdc++. Is there an interest from developers to see
> these runs with libc++?
>
> The basic options:
>
> 1) Convert all compatible clang builds to libc++, don't mess with libstdc++
> & clang.
> 2) Duplicate all the clang builds to build each version with both
> (acknowledging that will add nearly 1/3 to the already large ~125 linux
> runs).
> 3) Change most of the runs, but keep a few token libstdc++ & clang runs,
> with the latest compiler version (what c++ standard c++14? c++1z?).
> 4) Just add a few token libc++ runs, with the latest compiler version (what
> c++ standard c++14? c++1z?).
> 5) Don't add libc++.

I think, on Linux libstdc++ is the major standard library, even with
clang. So I'd prefer #4 with one or two latest clang versions, c++14
and c++1z.

> You can see more details about all of this on the github page where I keep
> my regression build scripts:
> https://github.com/teeks99/boost-build/tree/master/Regression
>
> The actual confgs run by the "full":
> https://github.com/teeks99/boost-build/blob/master/
> Regression/teeks99-02/machine_vars.json
>
> The docker builds for all these machine configurations are kept at:
> https://github.com/teeks99/boost-build/tree/master/Docker
> And can be pulled from the docker hub with e.g. `docker pull
> teeks99/boost-build:clang-3.9`
>
> If you've read this far, I'd be happy for any other opinions from
> developers who use the test matrix. Is it worth keeping all those compilers
> in the middle? Do we need to test the latest compilers with all the
> different standard configs (03, 11, 14, 1z + gnu equivalents)?

I don't think there's need to do separate runs for warnings (i.e. with
-Wall -Wextra flags). Those can be combined with debug or release
runs.

Regarding gnu++, personally, I almost always build my projects and
test my libraries with GNU extensions (because why not). I'm not sure
exactly what extensions are enabled in that mode compared to c++
modes. AFAIR, the extensions were essential with C++03 (if I'm not
mistaken, the long long/int64_t/etc. type was considered a GNU
extension back then and this type is used in quite a few places). Not
sure how much needed those are with C++11 and later.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Mar 6, 2017 at 4:50 PM, Tom Kent via Boost <[hidden email]>
wrote:

> 2) Duplicate all the clang builds to build each version with both
> (acknowledging that will add nearly 1/3 to the already large ~125 linux
> runs).
>

Lets please avoid that until such a time that report generation is
considerably faster.

--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 06/03/2017 22:50, Tom Kent via Boost wrote:

> 1) Convert all compatible clang builds to libc++, don't mess with libstdc++
> & clang.
> 2) Duplicate all the clang builds to build each version with both
> (acknowledging that will add nearly 1/3 to the already large ~125 linux
> runs).
> 3) Change most of the runs, but keep a few token libstdc++ & clang runs,
> with the latest compiler version (what c++ standard c++14? c++1z?).
> 4) Just add a few token libc++ runs, with the latest compiler version (what
> c++ standard c++14? c++1z?).
> 5) Don't add libc++.

A data point no one else seems to have mentioned yet is that while
libstdc++ is pretty much the default STL on Linux, it is increasingly
libc++ which is the default STL on Android. So, longer run, the right
and proper approach would be to test both STLs on Linux assuming that
Android usage of Boost will continue to grow.

Also, I don't know about anyone else, but I use Microsoft's C2 clang
generating the MSVC ABI a LOT. I know it still can't compile all of
Boost without ICEing, but it's getting close and if a regression runner
were available for C2 clang I don't doubt the Microsoft folk would find
that useful.

Finally, LLVM clang targeting the MSVC ABI is also getting close to
viable as a daily compiler on Windows. For me personally, the C2 clang
is much more important because you can run Visual Studio debug sessions
with its output unlike LLVM clang's output which works but is barely
viable. LLVM clang also ICEs when facing Boost with the MSVC ABI, but
it's in totally different places to the C2 clang :)

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 6 March 2017 at 23:14, Edward Diener via Boost wrote:

>
> Do any Boost libraries really target gnu features, if they exist, that are
> not in the corresponding c++ level ? If not there is no reason to test the
> gnu levels and the c++ levels seem just fine. I know that I do not
> specifically test gnu levels but c++ levels instead when I run local tests.
>
>
Does Boost.Multiprecision depend on the __int128 and __float128 extensions?

std::is_integral<__int128>::value is true for gnu++14 but false for c++14

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/7/2017 6:03 AM, Niall Douglas via Boost wrote:

> On 06/03/2017 22:50, Tom Kent via Boost wrote:
>
>> 1) Convert all compatible clang builds to libc++, don't mess with libstdc++
>> & clang.
>> 2) Duplicate all the clang builds to build each version with both
>> (acknowledging that will add nearly 1/3 to the already large ~125 linux
>> runs).
>> 3) Change most of the runs, but keep a few token libstdc++ & clang runs,
>> with the latest compiler version (what c++ standard c++14? c++1z?).
>> 4) Just add a few token libc++ runs, with the latest compiler version (what
>> c++ standard c++14? c++1z?).
>> 5) Don't add libc++.
>
> A data point no one else seems to have mentioned yet is that while
> libstdc++ is pretty much the default STL on Linux, it is increasingly
> libc++ which is the default STL on Android. So, longer run, the right
> and proper approach would be to test both STLs on Linux assuming that
> Android usage of Boost will continue to grow.
>
> Also, I don't know about anyone else, but I use Microsoft's C2 clang
> generating the MSVC ABI a LOT. I know it still can't compile all of
> Boost without ICEing, but it's getting close and if a regression runner
> were available for C2 clang I don't doubt the Microsoft folk would find
> that useful.
>
> Finally, LLVM clang targeting the MSVC ABI is also getting close to
> viable as a daily compiler on Windows. For me personally, the C2 clang
> is much more important because you can run Visual Studio debug sessions
> with its output unlike LLVM clang's output which works but is barely
> viable. LLVM clang also ICEs when facing Boost with the MSVC ABI, but
> it's in totally different places to the C2 clang :)

The problem with clang targeting the MSVC ABI, as far as Boost is
concerned, is that it erroneously implements the non-standard VC++
preprocessor. This makes it all but useless for using with Boost. That
it should have even been designed to do this for all macros, rather than
just for the macros it needed when processing VC++ and Windows headers,
is its major downfall. When you have to emulate something that is
already non-standard, and for which no internal knowledge is available,
you are already on the wrong path.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 03/07/17 16:14, Jonathan Wakely via Boost wrote:

> On 6 March 2017 at 23:14, Edward Diener via Boost wrote:
>
>>
>> Do any Boost libraries really target gnu features, if they exist, that are
>> not in the corresponding c++ level ? If not there is no reason to test the
>> gnu levels and the c++ levels seem just fine. I know that I do not
>> specifically test gnu levels but c++ levels instead when I run local tests.
>>
>>
> Does Boost.Multiprecision depend on the __int128 and __float128 extensions?
>
> std::is_integral<__int128>::value is true for gnu++14 but false for c++14

__int128 is definitely used in Boost.Atomic, although it's an optional
dependency.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> The problem with clang targeting the MSVC ABI, as far as Boost is
> concerned, is that it erroneously implements the non-standard VC++
> preprocessor. This makes it all but useless for using with Boost. That
> it should have even been designed to do this for all macros, rather than
> just for the macros it needed when processing VC++ and Windows headers,
> is its major downfall. When you have to emulate something that is
> already non-standard, and for which no internal knowledge is available,
> you are already on the wrong path.

You can tell C2 clang to not use MSVC compatibility and VS2015 Update 2
and later's headers will now compile cleanly. I would assume VS2017 is
the same.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
On 3/7/2017 9:47 AM, Niall Douglas via Boost wrote:

>> The problem with clang targeting the MSVC ABI, as far as Boost is
>> concerned, is that it erroneously implements the non-standard VC++
>> preprocessor. This makes it all but useless for using with Boost. That
>> it should have even been designed to do this for all macros, rather than
>> just for the macros it needed when processing VC++ and Windows headers,
>> is its major downfall. When you have to emulate something that is
>> already non-standard, and for which no internal knowledge is available,
>> you are already on the wrong path.
>
> You can tell C2 clang to not use MSVC compatibility and VS2015 Update 2
> and later's headers will now compile cleanly. I would assume VS2017 is
> the same.

Where is C2/clang available for download ? It seems the only thing that
is not mentioned in the C2/clang blogs. Nice going Microsoft !

>
> Niall
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
On 07/03/2017 16:48, Edward Diener via Boost wrote:

> On 3/7/2017 9:47 AM, Niall Douglas via Boost wrote:
>>> The problem with clang targeting the MSVC ABI, as far as Boost is
>>> concerned, is that it erroneously implements the non-standard VC++
>>> preprocessor. This makes it all but useless for using with Boost. That
>>> it should have even been designed to do this for all macros, rather than
>>> just for the macros it needed when processing VC++ and Windows headers,
>>> is its major downfall. When you have to emulate something that is
>>> already non-standard, and for which no internal knowledge is available,
>>> you are already on the wrong path.
>>
>> You can tell C2 clang to not use MSVC compatibility and VS2015 Update 2
>> and later's headers will now compile cleanly. I would assume VS2017 is
>> the same.
>
> Where is C2/clang available for download ? It seems the only thing that
> is not mentioned in the C2/clang blogs. Nice going Microsoft !

In the VS2017 installer, you just choose C2 clang just as you would any
other component.

I can't remember if Visual Studio's default project settings turn on
MSVC compatibility, but if they do, turn it off. Bar newly introduced
bugs in the headers (ping Stephan on those), C2 clang is compiling the
Windows SDK headers fairly well without MSVC emulation. There are some
warnings at -Wall though.

Note cmake et al don't understand the new path locations in VS2017 yet
and it's a pain. HOWEVER you can now load cmake projects straight into
VS2017 whereupon they find the new toolset because VS2017 ships a custom
cmake internally. It's incredibly slow though, almost unusably slow. And
VS2017 in cmake mode gets very badly confused frequently i.e. it's buggy.

(Before someone from Microsoft asks for me to report the bug, let me
suggest to you to go install WSL and try running cmake-within-WSL on the
same project as VS2017 has loaded via cmake. It's a disaster, and a real
impediment to the whole point of cmake project loading, you need to add
some logic to account for concurrent cmake-outside-of-VS2017 especially
when that is Linux cmake not Windows cmake)

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
On 3/7/2017 12:12 PM, Niall Douglas via Boost wrote:

> On 07/03/2017 16:48, Edward Diener via Boost wrote:
>> On 3/7/2017 9:47 AM, Niall Douglas via Boost wrote:
>>>> The problem with clang targeting the MSVC ABI, as far as Boost is
>>>> concerned, is that it erroneously implements the non-standard VC++
>>>> preprocessor. This makes it all but useless for using with Boost. That
>>>> it should have even been designed to do this for all macros, rather than
>>>> just for the macros it needed when processing VC++ and Windows headers,
>>>> is its major downfall. When you have to emulate something that is
>>>> already non-standard, and for which no internal knowledge is available,
>>>> you are already on the wrong path.
>>>
>>> You can tell C2 clang to not use MSVC compatibility and VS2015 Update 2
>>> and later's headers will now compile cleanly. I would assume VS2017 is
>>> the same.
>>
>> Where is C2/clang available for download ? It seems the only thing that
>> is not mentioned in the C2/clang blogs. Nice going Microsoft !
>
> In the VS2017 installer, you just choose C2 clang just as you would any
> other component.

Your mention of VS2015 Update 2 above led me to think it was some
downloadable software available for that product. Now I realize that it
is available for VS2017 currently being launched. So much hubbub for a
product which is just now being officially made available has confused
me. I have this bad habit of waiting until some software actually
officially exists and can be used before I become interested in it.
Excuse me <g> !

>
> I can't remember if Visual Studio's default project settings turn on
> MSVC compatibility, but if they do, turn it off. Bar newly introduced
> bugs in the headers (ping Stephan on those), C2 clang is compiling the
> Windows SDK headers fairly well without MSVC emulation. There are some
> warnings at -Wall though.
>
> Note cmake et al don't understand the new path locations in VS2017 yet
> and it's a pain. HOWEVER you can now load cmake projects straight into
> VS2017 whereupon they find the new toolset because VS2017 ships a custom
> cmake internally. It's incredibly slow though, almost unusably slow. And
> VS2017 in cmake mode gets very badly confused frequently i.e. it's buggy.
>
> (Before someone from Microsoft asks for me to report the bug, let me
> suggest to you to go install WSL and try running cmake-within-WSL on the
> same project as VS2017 has loaded via cmake. It's a disaster, and a real
> impediment to the whole point of cmake project loading, you need to add
> some logic to account for concurrent cmake-outside-of-VS2017 especially
> when that is Linux cmake not Windows cmake)

Thanks for all the info !

>
> Niall
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
On 2017-03-07 20:01, Edward Diener via Boost wrote:

> On 3/7/2017 12:12 PM, Niall Douglas via Boost wrote:
>> On 07/03/2017 16:48, Edward Diener via Boost wrote:
>>> On 3/7/2017 9:47 AM, Niall Douglas via Boost wrote:
>>>>> The problem with clang targeting the MSVC ABI, as far as Boost is
>>>>> concerned, is that it erroneously implements the non-standard VC++
>>>>> preprocessor. This makes it all but useless for using with Boost. That
>>>>> it should have even been designed to do this for all macros, rather
>>>>> than
>>>>> just for the macros it needed when processing VC++ and Windows
>>>>> headers,
>>>>> is its major downfall. When you have to emulate something that is
>>>>> already non-standard, and for which no internal knowledge is
>>>>> available,
>>>>> you are already on the wrong path.
>>>>
>>>> You can tell C2 clang to not use MSVC compatibility and VS2015 Update 2
>>>> and later's headers will now compile cleanly. I would assume VS2017 is
>>>> the same.
>>>
>>> Where is C2/clang available for download ? It seems the only thing that
>>> is not mentioned in the C2/clang blogs. Nice going Microsoft !
>>
>> In the VS2017 installer, you just choose C2 clang just as you would any
>> other component.
>
> Your mention of VS2015 Update 2 above led me to think it was some
> downloadable software available for that product. Now I realize that it
> is available for VS2017 currently being launched. So much hubbub for a
> product which is just now being officially made available has confused
> me. I have this bad habit of waiting until some software actually
> officially exists and can be used before I become interested in it.
> Excuse me <g> !
>

It is available in the VS2015 installer as well. And has been all the time.

But if you want to try it out now, from today VS2017 would be the
obvious choice. :-)



    Bo Persson




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
On 2017-03-07 20:18, Bo Persson via Boost wrote:

> On 2017-03-07 20:01, Edward Diener via Boost wrote:
>> On 3/7/2017 12:12 PM, Niall Douglas via Boost wrote:
>>> On 07/03/2017 16:48, Edward Diener via Boost wrote:
>>>> On 3/7/2017 9:47 AM, Niall Douglas via Boost wrote:
>>>>>> The problem with clang targeting the MSVC ABI, as far as Boost is
>>>>>> concerned, is that it erroneously implements the non-standard VC++
>>>>>> preprocessor. This makes it all but useless for using with Boost.
>>>>>> That
>>>>>> it should have even been designed to do this for all macros, rather
>>>>>> than
>>>>>> just for the macros it needed when processing VC++ and Windows
>>>>>> headers,
>>>>>> is its major downfall. When you have to emulate something that is
>>>>>> already non-standard, and for which no internal knowledge is
>>>>>> available,
>>>>>> you are already on the wrong path.
>>>>>
>>>>> You can tell C2 clang to not use MSVC compatibility and VS2015
>>>>> Update 2
>>>>> and later's headers will now compile cleanly. I would assume VS2017 is
>>>>> the same.
>>>>
>>>> Where is C2/clang available for download ? It seems the only thing that
>>>> is not mentioned in the C2/clang blogs. Nice going Microsoft !
>>>
>>> In the VS2017 installer, you just choose C2 clang just as you would any
>>> other component.
>>
>> Your mention of VS2015 Update 2 above led me to think it was some
>> downloadable software available for that product. Now I realize that it
>> is available for VS2017 currently being launched. So much hubbub for a
>> product which is just now being officially made available has confused
>> me. I have this bad habit of waiting until some software actually
>> officially exists and can be used before I become interested in it.
>> Excuse me <g> !
>>
>
> It is available in the VS2015 installer as well. And has been all the time.
>
> But if you want to try it out now, from today VS2017 would be the
> obvious choice. :-)
>
>

Oh, and the reference to Update 2 is when it started to compile the
Windows headers without any special options.


    Bo Persson





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/7/2017 2:18 PM, Bo Persson via Boost wrote:

> On 2017-03-07 20:01, Edward Diener via Boost wrote:
>> On 3/7/2017 12:12 PM, Niall Douglas via Boost wrote:
>>> On 07/03/2017 16:48, Edward Diener via Boost wrote:
>>>> On 3/7/2017 9:47 AM, Niall Douglas via Boost wrote:
>>>>>> The problem with clang targeting the MSVC ABI, as far as Boost is
>>>>>> concerned, is that it erroneously implements the non-standard VC++
>>>>>> preprocessor. This makes it all but useless for using with Boost.
>>>>>> That
>>>>>> it should have even been designed to do this for all macros, rather
>>>>>> than
>>>>>> just for the macros it needed when processing VC++ and Windows
>>>>>> headers,
>>>>>> is its major downfall. When you have to emulate something that is
>>>>>> already non-standard, and for which no internal knowledge is
>>>>>> available,
>>>>>> you are already on the wrong path.
>>>>>
>>>>> You can tell C2 clang to not use MSVC compatibility and VS2015
>>>>> Update 2
>>>>> and later's headers will now compile cleanly. I would assume VS2017 is
>>>>> the same.
>>>>
>>>> Where is C2/clang available for download ? It seems the only thing that
>>>> is not mentioned in the C2/clang blogs. Nice going Microsoft !
>>>
>>> In the VS2017 installer, you just choose C2 clang just as you would any
>>> other component.
>>
>> Your mention of VS2015 Update 2 above led me to think it was some
>> downloadable software available for that product. Now I realize that it
>> is available for VS2017 currently being launched. So much hubbub for a
>> product which is just now being officially made available has confused
>> me. I have this bad habit of waiting until some software actually
>> officially exists and can be used before I become interested in it.
>> Excuse me <g> !
>>
>
> It is available in the VS2015 installer as well. And has been all the time.

You are right. I missed it when installing. It is called "Clang with
Microsoft codegen" in the VS2015 install.

>
> But if you want to try it out now, from today VS2017 would be the
> obvious choice. :-)

Understood. Thanks !

>
>
>
>    Bo Persson



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 06/03/17 22:50, Tom Kent via Boost wrote:

> I have a bunch of linux regression runners that are executing clang runs of
> the boost regression suite (clang 3.0 - 4.0), currently these are all using
> the default, GCC libstdc++. Is there an interest from developers to see
> these runs with libc++?
>
> The basic options:
>
> 1) Convert all compatible clang builds to libc++, don't mess with libstdc++
> & clang.
> 2) Duplicate all the clang builds to build each version with both
> (acknowledging that will add nearly 1/3 to the already large ~125 linux
> runs).
> 3) Change most of the runs, but keep a few token libstdc++ & clang runs,
> with the latest compiler version (what c++ standard c++14? c++1z?).
> 4) Just add a few token libc++ runs, with the latest compiler version (what
> c++ standard c++14? c++1z?).
> 5) Don't add libc++.
>
> For background (you can respond to one of the above preferences without
> reading on), there are two machines constantly running linux builds (in
> addition to the two windows ones) that I manage.
>
> One I consider the "full" suite of compilers. It runs clang 3.0 - 4.0 and
> gcc 4.4 - 6. For the oldest and latest releas (gcc 4.4, gcc 6, clang 3.0,
> clang 3.9), I run all the supported standard configs I could find (c++98,
> c++0x, gnu98, gnu0x -- c++03, c++11, c++14, c++1z and their gnu
> equivalents). I also do runs with optimization and warnings cranked,
> against the latest standard config e.g. "-std=c++1z -O2". For all the
> compiler versions that aren't on the endcaps, I just run a single config
> with whatever was the latest standard config for that compiler (e.g.
> gcc-4.8 with c++1y). This is all repeated for develop and master for a
> total of about 100 different configurations.
>
> The machine I consider the "fast results" machine is configured with only
> four runs, one each for the latest release of gcc and clang  with the
> latest supported standard config (currently gcc-6 1z and clang-3.9 1z), for
> both master and develop. The goal here is that for any change checked in,
> the author will have feedback on its success against something modern and
> relevant within just a few hours.
>
> As a backup to the "fast results" machine, I also run those four regression
> modern runs, interspersed with the rest of the configs every dozen or so
> runs, bringing the total number of runs on the "full" machine up to around
> 125, which takes about a week for the machine to get through all the
> configurations.
>
> You can see more details about all of this on the github page where I keep
> my regression build scripts:
> https://github.com/teeks99/boost-build/tree/master/Regression
>
> The actual confgs run by the "full":
> https://github.com/teeks99/boost-build/blob/master/
> Regression/teeks99-02/machine_vars.json
>
> The docker builds for all these machine configurations are kept at:
> https://github.com/teeks99/boost-build/tree/master/Docker
> And can be pulled from the docker hub with e.g. `docker pull
> teeks99/boost-build:clang-3.9`
>
> If you've read this far, I'd be happy for any other opinions from
> developers who use the test matrix. Is it worth keeping all those compilers
> in the middle? Do we need to test the latest compilers with all the
> different standard configs (03, 11, 14, 1z + gnu equivalents)?

Hi Tom,

I personally used to compile my software with gcc/libstdc++ (latest) and
clang/libc++ (latest) on x64 linux.

I used to have runners for the latest (released) clang and libc++ on x64
linux with the latest (released) C++ standard.  In addition I would run
about-to-be-released versions of clang/libc++, especially if an
about-to-be-released C++ standard was on the way.  The idea was to help
boost and/or clang have releases that worked well together.

Unfortunately, I no longer have spare hardware, but I fully appreciate
any efforts in this direction.


> Thanks,
> Tom

No, thank you.  My 34" 21:9 screen can no longer fit all of your
configurations on it (at native res); you may single-handedly be a
justification for an even larger screen and/or for somebody to fix the
report generation speed.

Epic thanks,

Ben



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
On Wed, Mar 8, 2017 at 1:51 AM, Ben Pope via Boost
<[hidden email]> wrote:
> On 06/03/17 22:50, Tom Kent via Boost wrote:
> No, thank you.  My 34" 21:9 screen can no longer fit all of your
> configurations on it (at native res); you may single-handedly be a
> justification for an even larger screen and/or for somebody to fix the
> report generation speed.

4K and 5K were invented for a reason, you know? ;)


--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/7/2017 2:24 PM, Bo Persson via Boost wrote:

> On 2017-03-07 20:18, Bo Persson via Boost wrote:
>> On 2017-03-07 20:01, Edward Diener via Boost wrote:
>>> On 3/7/2017 12:12 PM, Niall Douglas via Boost wrote:
>>>> On 07/03/2017 16:48, Edward Diener via Boost wrote:
>>>>> On 3/7/2017 9:47 AM, Niall Douglas via Boost wrote:
>>>>>>> The problem with clang targeting the MSVC ABI, as far as Boost is
>>>>>>> concerned, is that it erroneously implements the non-standard VC++
>>>>>>> preprocessor. This makes it all but useless for using with Boost.
>>>>>>> That
>>>>>>> it should have even been designed to do this for all macros, rather
>>>>>>> than
>>>>>>> just for the macros it needed when processing VC++ and Windows
>>>>>>> headers,
>>>>>>> is its major downfall. When you have to emulate something that is
>>>>>>> already non-standard, and for which no internal knowledge is
>>>>>>> available,
>>>>>>> you are already on the wrong path.
>>>>>>
>>>>>> You can tell C2 clang to not use MSVC compatibility and VS2015
>>>>>> Update 2
>>>>>> and later's headers will now compile cleanly. I would assume
>>>>>> VS2017 is
>>>>>> the same.
>>>>>
>>>>> Where is C2/clang available for download ? It seems the only thing
>>>>> that
>>>>> is not mentioned in the C2/clang blogs. Nice going Microsoft !
>>>>
>>>> In the VS2017 installer, you just choose C2 clang just as you would any
>>>> other component.
>>>
>>> Your mention of VS2015 Update 2 above led me to think it was some
>>> downloadable software available for that product. Now I realize that it
>>> is available for VS2017 currently being launched. So much hubbub for a
>>> product which is just now being officially made available has confused
>>> me. I have this bad habit of waiting until some software actually
>>> officially exists and can be used before I become interested in it.
>>> Excuse me <g> !
>>>
>>
>> It is available in the VS2015 installer as well. And has been all the
>> time.
>>
>> But if you want to try it out now, from today VS2017 would be the
>> obvious choice. :-)
>>
>>
>
> Oh, and the reference to Update 2 is when it started to compile the
> Windows headers without any special options.

I installed the "Clang with Microsoft codegen", aka C2/clang, for VS2015
in order to see what I might need to do to integrate it into Boost
PP/VMD. I then went looking for documentation in the VS2015 IDE Help for
how to use it either from the IDE or command line. Absolutely no
documentation exists within Visual Studio 2015 about it, nor is there
any official docs anywhere on the web which I could find. I doubt very
much whether this is a viable option in VS2015 for compiling Boost
libraries. I will take a look again with VS2017, which I have just
downloaded, but considering that no documentation for this exists AFAICS
I highly doubt whether this Microsoft offering, whatever it is, will
work with Boost. Call me a skeptic, but if I a C++ product is released
without documentation, whether from Microsoft or anyone else, I have
great doubts that it will actually work with C++ standard code.

>
>
>    Bo Persson



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [regression runner] Preference libstdc++ vs. libc++

Boost - Dev mailing list
On 8 March 2017 at 09:34, Edward Diener via Boost <[hidden email]>
wrote:

> I installed the "Clang with Microsoft codegen", aka C2/clang, for VS2015
> in order to see what I might need to do to integrate it into Boost PP/VMD.
> I then went looking for documentation in the VS2015 IDE Help for how to use
> it either from the IDE or command line. Absolutely no documentation exists
> within Visual Studio 2015 about it, nor is there any official docs anywhere
> on the web which I could find. I doubt very much whether this is a viable
> option in VS2015 for compiling Boost libraries. I will take a look again
> with VS2017, which I have just downloaded, but considering that no
> documentation for this exists AFAICS I highly doubt whether this Microsoft
> offering, whatever it is, will work with Boost. Call me a skeptic, but if I
> a C++ product is released without documentation, whether from Microsoft or
> anyone else, I have great doubts that it will actually work with C++
> standard code.


 This SO question glosses
<http://stackoverflow.com/questions/42593423/whats-the-difference-between-clang-with-microsoft-codegen-and-llvm-vs2014>
over the what and why of Clang/C2 (vs Clang/LLVM).

degski

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12
Loading...