On Tue, 29 Jul 2014, Jürgen Hunold wrote:

Hi Niall,

Am Dienstag, 29. Juli 2014, 12:01:41 schrieb Niall Douglas:

...

Is anyone else seeing this warnings spew on Boost 1.56 beta when compiled with clang 3.4?

No. But I don't see an AFIO module at the moment.

...

https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Build%20POSIX_ Linux64_clang%203.4/11/consoleFull

Yes, clang has a lot more warning. Which ones did you enable?

...

GCC 4.8 produces no such spew.

gcc is lacking some warnings.

The main warnings I see here are about C99 macros (empty or variadic). gcc also has those warnings, but they are useless enough that it doesn't enable them by default. -- Marc Glisse

On 7/29/2014 8:17 AM, Niall Douglas wrote:

On 29 Jul 2014 at 13:41, Marc Glisse wrote:

...

...

Yes, clang has a lot more warning. Which ones did you enable?

...

GCC 4.8 produces no such spew.

gcc is lacking some warnings.

The main warnings I see here are about C99 macros (empty or variadic). gcc also has those warnings, but they are useless enough that it doesn't enable them by default.

Firstly I didn't see these warnings in Boost 1.55. Something has changed.

I think we all agree that 23Mb of warnings spew per build using Boost 1.56 with clang is unacceptable for release. Either Boost.Preprocessor needs fixing, or clang toolset builds explicitly need to add -Wno-c99-extensions to every Boost build.

The change that was made in Preprocessor is that variadic macros support is turned on for clang by default. I made this change after a number of complaints from users compiling with clang and after verifying that clang has always had variadic macro support. I do realize that clang will spit out lots of warnings, so maybe making this change was not a good idea on a practical level.

On 07/30/2014 04:58 AM, Niall Douglas wrote:

On 29 Jul 2014 at 20:48, Edward Diener wrote:

...

...

I think we all agree that 23Mb of warnings spew per build using Boost 1.56 with clang is unacceptable for release. Either Boost.Preprocessor needs fixing, or clang toolset builds explicitly need to add -Wno-c99-extensions to every Boost build.

The change that was made in Preprocessor is that variadic macros support is turned on for clang by default. I made this change after a number of complaints from users compiling with clang and after verifying that clang has always had variadic macro support.

I do realize that clang will spit out lots of warnings, so maybe making this change was not a good idea on a practical level.

That's great news, now we know the cause of the spew!

This is definitely a showstopper for Boost 1.56, megabytes of warning spew on clang would be embarrassing for an official release. Bug is filed at:

https://svn.boost.org/trac/boost/ticket/10276

I suppose this is unfortunate all round - in particular using -Wno-c99-extensions is way wider than the warning we're trying to suppress here. In either case, for a simple change like this, a pull request might be better than an issue. - Volodya

On 07/30/2014 09:21 AM, Niall Douglas wrote:

On 30 Jul 2014 at 8:23, Vladimir Prus wrote:

...

...

That's great news, now we know the cause of the spew!

This is definitely a showstopper for Boost 1.56, megabytes of warning spew on clang would be embarrassing for an official release. Bug is filed at:

https://svn.boost.org/trac/boost/ticket/10276

I suppose this is unfortunate all round - in particular using -Wno-c99-extensions is way wider than the warning we're trying to suppress here.

In either case, for a simple change like this, a pull request might be better than an issue.

An alternative could be if Edward wraps the appropriate parts of Preprocessor with:

#pragma GCC diagnostic ignored "-Wc99-extensions"

iff building with clang.

I believe clang supports these pragma filters.

It is difficult to know where in the preprocessor code this pragma would need to be applied.

On Tue, Jul 29, 2014 at 4:12 PM, Niall Douglas wrote:

I don't believe I do anything special here. Moreover I wasn't seeing this warning spew on Boost 1.55 with identical code.

Here is what Jamfile sets:

<toolset>clang:<cxxflags>"-std=c++0x -fvisibility-inlines-hidden -fstrict-aliasing -Wstrict-aliasing -Wno-unused -Wno-mismatched-tags -fvisibility=hidden -fopenmp -fasynchronous-unwind-tables"

Unless I'm missing something, C++11 includes C99 preprocessor (variadic macros, at least). So I don't see why these warnings should be emitted. A compiler bug perhaps?

Andrey Semashev wrote:

On Tue, Jul 29, 2014 at 4:12 PM, Niall Douglas wrote:

...

I don't believe I do anything special here. Moreover I wasn't seeing this warning spew on Boost 1.55 with identical code.

Here is what Jamfile sets:

<toolset>clang:<cxxflags>"-std=c++0x -fvisibility-inlines-hidden -fstrict-aliasing -Wstrict-aliasing -Wno-unused -Wno-mismatched-tags -fvisibility=hidden -fopenmp -fasynchronous-unwind-tables"

Unless I'm missing something, C++11 includes C99 preprocessor (variadic macros, at least). So I don't see why these warnings should be emitted. A compiler bug perhaps?

C++11 (-std=c++11) does, but -std=c++0x probably doesn't.

On 29 Jul 2014 at 16:27, Peter Dimov wrote:

...

Unless I'm missing something, C++11 includes C99 preprocessor (variadic macros, at least). So I don't see why these warnings should be emitted. A compiler bug perhaps?

C++11 (-std=c++11) does, but -std=c++0x probably doesn't.

That occurred to me too, so I tried -std=c++11 and got the same warnings spew. If you look through the log I posted most of the warnings aren't generated by AFIO code, they're actually from dependent Boost libraries. AFIO doesn't use the preprocessor library unless we're on a non-variadic compiler which is either VS2010 or VS2012. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 7/29/2014 6:45 AM, Peter Dimov wrote:

Niall Douglas wrote:

...

On 29 Jul 2014 at 16:27, Peter Dimov wrote:

...

...

Unless I'm missing something, C++11 includes C99 preprocessor > > (variadic macros, at least). So I don't see why these warnings should be emitted. A compiler bug perhaps?

C++11 (-std=c++11) does, but -std=c++0x probably doesn't.

That occurred to me too, so I tried -std=c++11 and got the same warnings spew.

Definitely a clang bug then. It should not enable C99 warnings by default in C++11 mode. The fix is to disable the warning in the Jamfile. I thought that the clang toolset already did that as we've discussed this issue with Edward Diener in the past, but I can't find -Wno-c99-extensions anywhere.

Is someone working on a fix? I'd be willing to take a patch that suppresses the warning from the Jamfile(s). That's obviously unsatisfactory since it doesn't help people who build in other ways. \e

On 7/30/2014 2:58 PM, Eric Niebler wrote:

On 7/29/2014 6:45 AM, Peter Dimov wrote:

...

Niall Douglas wrote:

...

On 29 Jul 2014 at 16:27, Peter Dimov wrote:

...

...

Unless I'm missing something, C++11 includes C99 preprocessor > > (variadic macros, at least). So I don't see why these warnings should be emitted. A compiler bug perhaps?

C++11 (-std=c++11) does, but -std=c++0x probably doesn't.

That occurred to me too, so I tried -std=c++11 and got the same warnings spew.

Definitely a clang bug then. It should not enable C99 warnings by default in C++11 mode. The fix is to disable the warning in the Jamfile. I thought that the clang toolset already did that as we've discussed this issue with Edward Diener in the past, but I can't find -Wno-c99-extensions anywhere.

Is someone working on a fix? I'd be willing to take a patch that suppresses the warning from the Jamfile(s). That's obviously unsatisfactory since it doesn't help people who build in other ways.

The warnings mentioned in the OP are emitted when the '-pedantic' compiler option is used but do not appear otherwise. To get rid of the warnings when '-pedantic' is used you need to add '-Wno-c99-extensions' and '-Wno-variadic-macros' compiler options. It is up to Boost whether they want to add '-Wno-c99-extensions' and '-Wno-variadic-macros' when compiling with clang. I do not know how this is done in the clang jam files but I suspect Vladimir Prus does know and could implement this change in Boost Build if it is deemed necessary.

Niall Douglas wrote:

The following libraries use -pedantic and therefore generate warning spew on clang with Preprocessor:

Chrono Thread Test

...

An alternative is to remove -pedantic on clang.

Or, whoever adds -pedantic to the command line also needs to add -Wno-c99-extensions and -Wno-variadic-macros.

On 1/08/2014 10:08, Niall Douglas wrote:

Ok, so solutions to stopping tens of megabytes of compiler warnings spew for a build of Boost 1.56 on clang are as follows:

1. Boost Build adds -Wno-c99-extensions and -Wno-variadic-macros to all clang builds.

2. All those libraries using -pedantic with Preprocessor (at least Chrono, Thread and Test) wrap their use of Preprocessor with #pragmas disabling the warnings.

3. All those libraries using -pedantic with Preprocessor (at least Chrono, Thread and Test) add -Wno-c99-extensions and -Wno-variadic-macros to all clang builds.

4. Those libraries currently using -pedantic stop doing so, at least for clang builds. (I don't know whether this is better or worse than any of the others, just that it's an option that wasn't listed.)

On 7/31/2014 5:03 PM, Edward Diener wrote:

On 7/31/2014 7:17 PM, Gavin Lambert wrote:

...

On 1/08/2014 10:08, Niall Douglas wrote:

...

Ok, so solutions to stopping tens of megabytes of compiler warnings spew for a build of Boost 1.56 on clang are as follows:

1. Boost Build adds -Wno-c99-extensions and -Wno-variadic-macros to all clang builds.

2. All those libraries using -pedantic with Preprocessor (at least Chrono, Thread and Test) wrap their use of Preprocessor with #pragmas disabling the warnings.

3. All those libraries using -pedantic with Preprocessor (at least Chrono, Thread and Test) add -Wno-c99-extensions and -Wno-variadic-macros to all clang builds.

4. Those libraries currently using -pedantic stop doing so, at least for clang builds.

In clang-linux.jam and clang-darwin.jam, the '-pedantic' option is passed when <warnings>all is specified and not passed when <warnings>on is specified. So what appears to be needed is either just changing the line which specifies <warnings>all to be the same as <warnings>on in the clang jam files, or keeping the clang jam file as is and changing the particular libraries putting out the excessive messages to either specify <warnings>on rather than <warnings>all for clang builds or add the options specified in 3) above.

The problem with changing the jam files is that end-users will also get the change where <warnings>all does not specify '-pedantic' where they might really want it to.

Since nobody has made a definite suggestion or submitted a patch, this issue will in all likelihood not be fixed for 1.56. Sorry, guys. \e

On 8/3/2014 4:35 PM, Eric Niebler wrote:

On 7/31/2014 5:03 PM, Edward Diener wrote:

...

On 7/31/2014 7:17 PM, Gavin Lambert wrote:

...

On 1/08/2014 10:08, Niall Douglas wrote:

...

Ok, so solutions to stopping tens of megabytes of compiler warnings spew for a build of Boost 1.56 on clang are as follows:

1. Boost Build adds -Wno-c99-extensions and -Wno-variadic-macros to all clang builds.

2. All those libraries using -pedantic with Preprocessor (at least Chrono, Thread and Test) wrap their use of Preprocessor with #pragmas disabling the warnings.

3. All those libraries using -pedantic with Preprocessor (at least Chrono, Thread and Test) add -Wno-c99-extensions and -Wno-variadic-macros to all clang builds.

4. Those libraries currently using -pedantic stop doing so, at least for clang builds.

In clang-linux.jam and clang-darwin.jam, the '-pedantic' option is passed when <warnings>all is specified and not passed when <warnings>on is specified. So what appears to be needed is either just changing the line which specifies <warnings>all to be the same as <warnings>on in the clang jam files, or keeping the clang jam file as is and changing the particular libraries putting out the excessive messages to either specify <warnings>on rather than <warnings>all for clang builds or add the options specified in 3) above.

The problem with changing the jam files is that end-users will also get the change where <warnings>all does not specify '-pedantic' where they might really want it to.

Since nobody has made a definite suggestion or submitted a patch, this issue will in all likelihood not be fixed for 1.56. Sorry, guys.

I am willing to patch Boost PP so that clang is treated like gcc, since it is an easy patch. That is that clang will be tested for variadic macro support as gcc has always been tested for variadic macro support. The corresponding lines for clang, as it has always been for gcc, would then be:

# elif !defined __cplusplus && __STDC_VERSION__ >= 199901L || __cplusplus >= 201103L # define BOOST_PP_VARIADICS 1 # else # define BOOST_PP_VARIADICS 0

This of course needs to be tested by everybody in the 'master' test matrix to make sure it does not break anyone's code. This is the main reason I have been loth to do this at this late time before the Boost 1.56 release. When the clang issue originally came up months ago a number of people were upset that clang was set not to have variadic macro support in Boost PP. There was originally specific code in the Boost PP for turning off variadic macro support for clang unconditionally. So my reaction was to turn it on unconditionally after finding out that clang has always supported variadic macros from the beginning, and this satisfied those working with clang and using variadic macros. Now with the issue of warnings when '<warnings>all' is specifically used in jam files, we have the situation we find ourselves in. I do not feel empowered to make this call myself, since a change to the guts of Boost PP config.h affects every library using Boost PP. But I am confident it should work in theory. But if some library is using Boost PP variadic macros and doesn't have the clang equivalent option set that turns on C++0x or better support then that library will fail. OTOH we could look for the libraries that have '<warnings>all' in their jam files and create pull requests so that it gets changed to <warning>on whenever clang is the compiler. Something like: '<toolset>clang:<warnings>on' as a project requirement I suppose. As far as end-user using Boost libraries, other than building them, with clang they would only see the clang warnings if they specify '-pedantic' and the library used variadic macros.

On 8/3/2014 7:44 PM, Niall Douglas wrote:

On 3 Aug 2014 at 18:53, Edward Diener wrote:

...

I do not feel empowered to make this call myself, since a change to the guts of Boost PP config.h affects every library using Boost PP. But I am confident it should work in theory. But if some library is using Boost PP variadic macros and doesn't have the clang equivalent option set that turns on C++0x or better support then that library will fail.

I think turning off variadic macros for clang would be a retrograde step considering the much superior alternatives.

...

OTOH we could look for the libraries that have '<warnings>all' in their jam files and create pull requests so that it gets changed to <warning>on whenever clang is the compiler. Something like:

'<toolset>clang:<warnings>on' as a project requirement I suppose.

As far as end-user using Boost libraries, other than building them, with clang they would only see the clang warnings if they specify '-pedantic' and the library used variadic macros.

For a 1.56 release, this seems like a very sensible least cost solution. It breaks nothing, is easy to do, and can be done immediately.

Later on individual libraries can restore pedantic warnings for clang if they do whatever #pragma warning fixes necessary. Up to their maintainers.

I am not empowered to change the .jam files for the affected libraries. I can make pull requests but if they are not responded to it will be too late for Boost 1.56, if it is not already too late.

----- Original Message -----

From: "Edward Diener"

...

...

As far as end-user using Boost libraries, other than building them, with clang they would only see the clang warnings if they specify '-pedantic' and the library used variadic macros.

For a 1.56 release, this seems like a very sensible least cost solution. It breaks nothing, is easy to do, and can be done immediately.

Later on individual libraries can restore pedantic warnings for clang if they do whatever #pragma warning fixes necessary. Up to their maintainers.

I submitted pull requests, directly on 'master', for chrono, regex, threads, and test to fix the warnings problem. But it appears to be too late for 1.56.

I understand your being upset by all the warnings, and perhaps users will not like them when they build Boost 1.56 with clang, but there are worse things that can happen in a new release.

Are these just warnings, but the results are still correct? Either way, this is a clang issue. They intentionally chose to *not* implement the standard instead deferring to the garbage MSVC status quo. Given that and their attitude of "more" being put above "better", a sea of warnings is a good thing. Regards, Paul Mensonides

----- Original Message -----

From: "Edward Diener"

...

Are these just warnings, but the results are still correct?

Yes.

...

Either way, this is a clang issue. They intentionally chose to *not* implement the standard instead deferring to the garbage MSVC status quo. Given that and their attitude of "more" being put above "better", a sea of warnings is a good thing.

No, that is not what is happening. We are not talking about the clang Windows VC++ targeted implementation but just the regular clang-linux ( or mingw/gcc on Windows ) implementation.

In your original config.h you had turned off variadic macro support for clang unconditionally. Then I turned it on unconditionally after complaints from Boost users and developers and being told by clang developers that clang has always supported variadic macros. However if the necessary clang compiler options are not on ( probably something like gcc's std=c++0x option ), clang issues lots of warnings when you use variadic macros although the output is fine.

I should have probably probably just allowed your code of:

...

# elif !defined __cplusplus && __STDC_VERSION__ >= 199901L || __cplusplus >= 201103L # define BOOST_PP_VARIADICS 1 # else # define BOOST_PP_VARIADICS 0

to determine the issue for clang rather than unconditionally turn it on. Then using clang in Boost PP with variadic macros would have been the same as using gcc in Boost PP with variadic macros.

Ah, thanks for the clarification. (I had just went back and read through the clang mailing list about MSVC compatible preprocessor a couple of days ago.) Regards, Paul Mensonides

On 8/4/2014 10:15 PM, Andrey Semashev wrote:

On Monday 04 August 2014 20:55:01 Edward Diener wrote:

...

In your original config.h you had turned off variadic macro support for clang unconditionally. Then I turned it on unconditionally after complaints from Boost users and developers and being told by clang developers that clang has always supported variadic macros. However if the necessary clang compiler options are not on ( probably something like gcc's std=c++0x option ), clang issues lots of warnings when you use variadic macros although the output is fine.

The warnings are emitted in C++11 mode, see how the topic started.

I did not see any clang command line in the OP or the OP's link which shows the warnings emitted in C++11 mode. Would you please point this out to me ?

It's a bug in clang and should be reported to clang devs (probably by someone who is interested in it being fixed and has some context of the issue).

On 5 Aug 2014 at 0:38, Edward Diener wrote:

...

...

In your original config.h you had turned off variadic macro support for clang unconditionally. Then I turned it on unconditionally after complaints from Boost users and developers and being told by clang developers that clang has always supported variadic macros. However if the necessary clang compiler options are not on ( probably something like gcc's std=c++0x option ), clang issues lots of warnings when you use variadic macros although the output is fine.

The warnings are emitted in C++11 mode, see how the topic started.

I do see this now. I forgot the discussion that specified that this was happening.

If the OP was me, I was originally mistaken. AFIO sets -std=c++0x for itself, but AFIO does not generate any warnings. It is AFIO's dependent libraries in Boost which generate the warnings, and these are compiled with whatever default flags each library has. These are C++03 mode. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 30 Jul 2014 at 10:44, Edward Diener wrote:

...

Is anyone else seeing this warnings spew on Boost 1.56 beta when compiled with clang 3.4?

https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Build%20POSIX_ Linux64_clang%203.4/11/consoleFull

GCC 4.8 produces no such spew.

I cannot duplicate, using clang, the sort of excessive output in your link above with the tests of the Boost PP library, or the tests in my VMD library which exercise various Boost PP variadic macros pretty extensively.

Others have also reported such spew, but not everyone. It might be a clang packaging thing.

My clang command line options for the tests looks like:

"clang++" -c -x c++ -O0 -g -fno-inline -Wall -g -fPIC

Can you tell me what the clang command line in your AFIO tests in your link above actually is ?

AFIO itself does not trigger any of the spew, as it does not use Preprocessor. Rather it is the dependent libraries such as Thread, Filesystem, ASIO, Test etc. I did actually post this earlier, but as I have a SSH session open right now here it is again, this being an example from Boost.Test: "clang++" -c -x c++ -O0 -g -fno-inline -Wall -pedantic -g -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_DYN_LINK=1 -I"." -o "bin.v2/libs/test/build/clang-linux-3.4.2/debug/threading-multi/debug. o" "libs/test/src/debug.cpp" In file included from libs/test/src/debug.cpp:16: In file included from ./boost/test/impl/debug.ipp:21: In file included from ./boost/test/detail/global_typedef.hpp:18: In file included from ./boost/test/utils/basic_cstring/basic_cstring.hpp:21: In file included from ./boost/test/utils/basic_cstring/bcs_char_traits.hpp:22: In file included from ./boost/type_traits/add_const.hpp:16: In file included from ./boost/type_traits/detail/type_trait_def.hpp:14: In file included from ./boost/type_traits/detail/template_arity_spec.hpp:12: In file included from ./boost/mpl/aux_/preprocessor/params.hpp:46: In file included from ./boost/preprocessor/repeat.hpp:15: In file included from ./boost/preprocessor/repetition/repeat.hpp:21: ./boost/preprocessor/tuple/eat.hpp:23:26: warning: variadic macros are a C99 feature [-Wvariadic-macros] # define BOOST_PP_EAT(...) ^ In file included from libs/test/src/debug.cpp:16: In file included from ./boost/test/impl/debug.ipp:56: In file included from ./boost/test/utils/class_properties.hpp:24: In file included from ./boost/preprocessor/seq/for_each.hpp:20: In file included from ./boost/preprocessor/tuple/elem.hpp:20: In file included from ./boost/preprocessor/facilities/overload.hpp:17: ./boost/preprocessor/variadic/size.hpp:25:40: warning: variadic macros are a C99 feature [-Wvariadic-macros] # define BOOST_PP_VARIADIC_SIZE(...) BOOST_PP_VARIADIC_SIZE_I(__VA_ARGS__, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1,) ^ ./boost/preprocessor/variadic/size.hpp:27:354: warning: variadic macros are a C99 feature [-Wvariadic-macros] # define BOOST_PP_VARIADIC_SIZE_I(e0, e1, e2, e3, e4, e5, e6, e7, e8, e9, e10, e11, e12, e13, e14, e15, e16, e17, e18, e19, e20, e21, e22, e23, e24, e25, e26, e27, e28, e29, e30, e31, e32, e33, e34, e35, e36, e37, e38, e39, e40, e41, e42, e43, e44, e45, e46, e47, e48, e49, e50, e51, e52, e53, e54, e55, e56, e57, e58, e59, e60, e61, e62, e63, size, ...) size I have set it running to generate a complete set of spew with how clang++ was called so you can nail all the occasions with #pragma. It's only a wee ARM board, so it will take a while as there are a few hundred Mb of stuff. Once done I'll upload it to Google Drive and post the link here. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/