[boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

[Paul A. Bristow via Boost]

I am trying to check code that works on VS2015 update 3 and GCC 6.3.0 using Clang 4.0.0

I am using the CodeBlocks IDE (though I don't think that is relevant).

The code indirectly uses next.hpp and prior.hpp

There are several warnings like this (after adding the -Wignored-attributes option)
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\immintrin.h|45|warning: __declspec attribute 'intrin_type' is not
supported [-Wignored-attributes]

I:\modular-boost\boost\mpl\next_prior.hpp|44|error: too many arguments provided to function-like macro invocation|

Following suggestions in this thread, I have added -Wno-invalid-token-paste
http://clang-developers.42468.n3.nabble.com/invalid-token-paste-td4025526.html

and also -DBOOST_PP_CONFIG_FLAGS=1,

but I get a blizzard of errors - see below

It would seem that this may be because of a misconfiguration in Boost mpl?

If I understand right, the thread above suggests that this is MS pre-processor-specific MPL code because of code in
boost/preprocessor/config/config.hpp that determines the MPL code?

Is this correct?
Target: x86_64-pc-windows-msvc
-triple x86_64-pc-windows-msvc19.0.24123

Complete log attached in case this helps.

Can anyone say what I am doing wrong and/or suggest a workaround for this?

Thanks

Paul

Compile line is

clang++.exe -Wall -fexceptions -Wignored_attributes -D"BOOST_PP_CONFIG_FLAGS()"=1 -m64 -v -Wignored-attributes
-Wno-invalid-token-paste -II:\modular-boost -I"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include" -c
J:\Cpp\Misc\lambert_w_single\lambert_w_single.cpp -o .objs\Misc\lambert_w_single\lambert_w_single.o
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\LLVM\bin
"C:\\LLVM\\bin\\clang++.exe" -cc1 -triple x86_64-pc-windows-msvc19.0.24123

In file included from I:\modular-boost\boost/mpl/next.hpp:17:
I:\modular-boost\boost/mpl/next_prior.hpp:44:23: error: too many arguments provided to function-like macro invocation
BOOST_MPL_AUX_NA_SPEC(1, next)
^
I:\modular-boost\boost/preprocessor/facilities/expand.hpp:26:10: note: macro 'BOOST_PP_EXPAND_I' defined here
# define BOOST_PP_EXPAND_I(x) x
^

In file included from I:\modular-boost\boost/mpl/next.hpp:17:
I:\modular-boost\boost/mpl/next_prior.hpp:44:1: error: expected a qualified name after 'typename'
BOOST_MPL_AUX_NA_SPEC(1, next)
^
I:\modular-boost\boost/mpl/aux_/na_spec.hpp:161:40: note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC'
#define BOOST_MPL_AUX_NA_SPEC(i, name) \
^
I:\modular-boost\boost/mpl/aux_/na_spec.hpp:154:47: note: expanded from macro '\
BOOST_MPL_AUX_NA_SPEC_NO_ETI'
#define BOOST_MPL_AUX_NA_SPEC_NO_ETI(i, name) \
^
I:\modular-boost\boost/mpl/aux_/na_spec.hpp:64:11: note: expanded from macro '\
BOOST_MPL_AUX_NA_SPEC_MAIN'
BOOST_MPL_PP_PARAMS(i, typename T) \
^
I:\modular-boost\boost/mpl/aux_/preprocessor/params.hpp:58:11: note: expanded from macro 'BOOST_MPL_PP_PARAMS'
, BOOST_MPL_PP_AUX_PARAM_FUNC \
^

...

I:\modular-boost\boost/mpl/void.hpp:71:1: error: expected ',' or '>' in template-parameter-list
I:\modular-boost\boost/mpl/aux_/na_spec.hpp:161:40: note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC'
#define BOOST_MPL_AUX_NA_SPEC(i, name) \
^
I:\modular-boost\boost/mpl/aux_/na_spec.hpp:154:47: note: expanded from macro '\
BOOST_MPL_AUX_NA_SPEC_NO_ETI'
#define BOOST_MPL_AUX_NA_SPEC_NO_ETI(i, name) \
^
I:\modular-boost\boost/mpl/aux_/na_spec.hpp:65:9: note: expanded from macro '\
BOOST_MPL_AUX_NA_SPEC_MAIN'
BOOST_MPL_PP_NESTED_DEF_PARAMS_TAIL(i, typename T, na) \
^
note: (skipping 6 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
I:\modular-boost\boost/preprocessor/repetition/repeat.hpp:38:37: note: expanded from macro 'BOOST_PP_REPEAT_1'
# define BOOST_PP_REPEAT_1(c, m, d) BOOST_PP_REPEAT_1_I(c, m, d)
^
I:\modular-boost\boost/preprocessor/repetition/repeat.hpp:43:39: note: expanded from macro 'BOOST_PP_REPEAT_1_I'
# define BOOST_PP_REPEAT_1_I(c, m, d) BOOST_PP_REPEAT_1_ ## c(m, d)
^
<scratch space>:64:1: note: expanded from here
BOOST_PP_REPEAT_1_BOOST_PP_REM
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830

[Peter Dimov via Boost]

Paul A. Bristow wrote:
> I am trying to check code that works on VS2015 update 3 and GCC 6.3.0
> using Clang 4.0.0

...

> Following suggestions in this thread, I have
> added -Wno-invalid-token-paste
> http://clang-developers.42468.n3.nabble.com/invalid-token-paste-td4025526.html

You could try disabling Clang's MS mode with -fno-ms-compatibility and see
if that helps.


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

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Peter Dimov via Boost
> Sent: 24 March 2017 18:37
> To: bo...@lists.boost.org
> Cc: Peter Dimov
> Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
>
> Paul A. Bristow wrote:
> > I am trying to check code that works on VS2015 update 3 and GCC 6.3.0
> > using Clang 4.0.0
> ...
> > Following suggestions in this thread, I have
> > added -Wno-invalid-token-paste
> > http://clang-developers.42468.n3.nabble.com/invalid-token-paste-td4025526.html
>
> You could try disabling Clang's MS mode with -fno-ms-compatibility and see
> if that helps.

With adding <cxxflags>-fno-ms-compatibility to user_config.jam and a command line

modular-boost\libs\hello_boost\example>b2 toolset=clang-4.0.0 -a -d2 --debug-configuration > clang40_25Mar17.log

"c:\LLVM\bin\clang++.exe" -c -x c++ -v -fno-ms-compatibility -O0 -g -fno-inline -Wall -g -m64 -DBOOST_ALL_NO_LIB=1 -I"..\..\.."
-o "..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug\hello_boost.obj" "hello_boost.cpp"

I still get

In file included from ..\..\..\boost/config.hpp:44:
..\..\..\boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found
# include <cstddef>

But I note that the line above mentions to object file location is

clang-linux-4.0.0\debug\hello_boost.obj

but default target x86_64-pc-windows-msvc

should I expect Clang-msvc here?

Do I do this using a different 'triple' and/or target and if so what?

compileflags>"-target x86_64-pc-windows-gnu" or ?

Thanks

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830

[Peter Dimov via Boost]

Paul A. Bristow wrote:
> With adding <cxxflags>-fno-ms-compatibility to user_config.jam and a

> command line...

> I still get
>
> In file included from ..\..\..\boost/config.hpp:44:
> ..\..\..\boost/config/select_stdlib_config.hpp:18:12: fatal error:
> 'cstddef' file not found
> # include <cstddef>

You never mentioned how you got rid of that error.

Would not adding the MSVC include directory manually with -isystem work?

> But I note that the line above mentions to object file location is
>
> clang-linux-4.0.0\debug\hello_boost.obj
>
> but default target x86_64-pc-windows-msvc
>
> should I expect Clang-msvc here?

I have no idea why we have two clang toolsets, or which would be the correct
one to use here.

[degski via Boost]

On 25 March 2017 at 05:17, Peter Dimov via Boost <bo...@lists.boost.org>
wrote:

> I have no idea why we have two clang toolsets, or which would be the
> correct one to use here.

Because there ARE (at least) two, the Clang-msvc option is (for the
moment) a dead end, though.

@Paul: Edward and Niall have looked into this extensively (there's a few
threads on this on the mailing list, around April 2016) and nothing
(obvious) seems to work (even after getting the build to start) as a mix of
'errors' in Clang-cl's VC-PP emulation goes together with
mis-identification of the Clang/LLVM/C2/VC-STL combo in the boost-headers
(possibly clang-cl is the culprit, what -fno-ms-compatibility tries to
solve, but it doesn't) starting with type-traits and typeof (but not
limited to), which then avalache through the rest of the boost-code. On the
bright side, if it doesn't work, there's no need for testing either :-) .

Both Niall and Edward have submitted several PR's to Clang, which seem to
be ignored. Edward seems to think it's just to big a mess to fix for the
Clang team.

Without some fixes to type-traits and typeof, one cannot use clang-cl
successfully for code that contains boost library headers, even when
linking to boost libraries compiled with vanilla VC.

It might be that either Niall or Edward has made progress on this subject,
but I'm not aware of that.

degski

[Edward Diener via Boost]

On 3/25/2017 4:17 AM, Peter Dimov via Boost wrote:
> Paul A. Bristow wrote:
>> With adding <cxxflags>-fno-ms-compatibility to user_config.jam and a
>> command line...
>
>
>> I still get
>>
>> In file included from ..\..\..\boost/config.hpp:44:
>> ..\..\..\boost/config/select_stdlib_config.hpp:18:12: fatal error:
>> 'cstddef' file not found
>> # include <cstddef>
>
> You never mentioned how you got rid of that error.
>
> Would not adding the MSVC include directory manually with -isystem work?
>
>> But I note that the line above mentions to object file location is
>>
>> clang-linux-4.0.0\debug\hello_boost.obj
>>
>> but default target x86_64-pc-windows-msvc
>>
>> should I expect Clang-msvc here?
>
> I have no idea why we have two clang toolsets, or which would be the
> correct one to use here.

Disclaimer: I contributed clang-win.jam to Boost Build but did not write
it and do not know how it works. Nobody else who knows how Boost build
works internally has ever taken an interest in it and I am not qualified
to fix any of its problems.

The two clang toolsets are clang, which normally translates to
clang-linux, and clang-win. The former is used on Linux, Mac, and on
Windows when targeting mingw(-64)/gcc. Using VC++ as the backend you
normally use clang-win. However clang targeting VC++ is broken in Boost
PP because the clang developers incorrectly emulated the already
non-standard VC++ preprocessor.

Whether -fno-ms-compatibility fixes anything or does anything I do not
know. I have never been able to find the slightest documentation from
clang about it, but then again clang's documentation has always taken a
distinct backseat to clang's development ( I am being nice here ). I
suspect that even when using -fno-ms-compatibility you still need to use
the clang-win toolset since you are still using the VC++ backend. If I
knew what -fno-ms-compatibility actually does vis-a-vis predefined
macros I would try to update the BoostPP config.hpp accordingly. I was
hoping to find out more about it in the VS2017 documentation, but since
Microsoft put out VS2017 without any documentation ( nice going
Microsoft ! ) that is currently impossible.

I explained to Paul via e-mail my rather elaborate setup for testing
clang on Windows, both for targeting mingw(-64)/gcc and VC++. It is
elaborate since it involves setting the PATH variable without which,
AFAIK, clang and its gcc/VC++ backends do not work.

[degski via Boost]

On 25 March 2017 at 08:39, Edward Diener via Boost <bo...@lists.boost.org>
wrote:

> I suspect that even when using -fno-ms-compatibility you still need to use
> the clang-win toolset since you are still using the VC++ backend.

Isn't the issue mostly related to the use of the Dinkumware STL, as opposed
to the Clang backends, of which there are two: LLVM (the one Paul was
trying to get to work) and C2. The latter gives better debugging support,
the former often (not always though) generates better code.

degski

[Peter Dimov via Boost]

Paul A. Bristow wrote:

> In file included from I:\modular-boost\boost/mpl/next.hpp:17:
> I:\modular-boost\boost/mpl/next_prior.hpp:44:23: error: too many arguments
> provided to function-like macro invocation
> BOOST_MPL_AUX_NA_SPEC(1, next)
> ^

I tried to compile

#include <boost/mpl/list.hpp>
#include <boost/mpl/push_front.hpp>

int main()
{
namespace mpl = boost::mpl;

using L = mpl::list<>;
using L2 = mpl::push_front<L, void>;
}

with the build-in Clang/C2, hit

1>../boost-git/boost\boost/mpl/next_prior.hpp(44,1): error : pasting formed
'BOOST_PP_TUPLE_ELEM_O_3(', an invalid preprocessing token
[-Winvalid-token-paste]
1>BOOST_MPL_AUX_NA_SPEC(1, next)

Tried

#define BOOST_PP_CONFIG_FLAGS() 1

at the top, same. The "strict" PP configuration is used, it just doesn't
work for some reason I couldn't figure out. It's possible
that -fms-extensions also changes the preprocessor and this breaks PP, but
without it, MS's headers don't compile.

If you tell MPL to not use PP though:

#include <boost/mpl/aux_/config/preprocessor.hpp>
#undef BOOST_MPL_CFG_NO_OWN_PP_PRIMITIVES

this simple example works. I've no idea whether more complex ones will.

But if you don't insist on an MS-compatible Clang and can stomach the old
and busted 3.9, you can just use the Cygwin Clang. That's what I do.

[Edward Diener via Boost]

There is also BOOST_PP_VARIADICS_MSVC, which provides lots of special
VC++ variadics workarounds.

[Peter Dimov via Boost]

Edward Diener wrote:

> There is also BOOST_PP_VARIADICS_MSVC, which provides lots of special VC++
> variadics workarounds.

Yes there was, thanks for the hint.

#define BOOST_PP_CONFIG_FLAGS() 1
#include <boost/preprocessor/config/config.hpp>

#define BOOST_PP_VARIADICS_MSVC 0

#include <boost/mpl/list.hpp>
#include <boost/mpl/push_front.hpp>

int main()
{
namespace mpl = boost::mpl;

using L = mpl::list<>;
using L2 = mpl::push_front<L, void>;
}

works.

The reason is

# elif defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) ||
!defined __EDG__ || defined(__INTELLISENSE__) || defined(__INTEL_COMPILER)
&& __INTEL_COMPILER >= 1700)
# define BOOST_PP_VARIADICS 1
# undef BOOST_PP_VARIADICS_MSVC
# define BOOST_PP_VARIADICS_MSVC 1

which defines BOOST_PP_VARIADICS_MSVC for Clang and must not.

You can tell Clang to not define _MSC_VER (-fmsc-version="0"), but MS's
headers don't work with that yet (although STL said they are going to.)

-fno-ms-compatibility is default for Clang/C2 at least, so I think that the
above should just define BOOST_PP_VARIADICS_MSVC to 0 on Clang.

[Peter Dimov via Boost]

> #define BOOST_PP_CONFIG_FLAGS() 1
> #include <boost/preprocessor/config/config.hpp>
>
> #define BOOST_PP_VARIADICS_MSVC 0
>
> #include <boost/mpl/list.hpp>
> #include <boost/mpl/push_front.hpp>
>
> int main()
> {
> namespace mpl = boost::mpl;
>
> using L = mpl::list<>;
> using L2 = mpl::push_front<L, void>;
> }
>
> works.

It works without

#define BOOST_PP_CONFIG_FLAGS() 1

as well.

#include <boost/preprocessor/config/config.hpp>
#define BOOST_PP_VARIADICS_MSVC 0

is all that's required.

[Edward Diener via Boost]

On 3/25/2017 10:46 AM, Peter Dimov via Boost wrote:
> Edward Diener wrote:
>
>> There is also BOOST_PP_VARIADICS_MSVC, which provides lots of special
>> VC++ variadics workarounds.
>
> Yes there was, thanks for the hint.
>
> #define BOOST_PP_CONFIG_FLAGS() 1
> #include <boost/preprocessor/config/config.hpp>
>
> #define BOOST_PP_VARIADICS_MSVC 0
>
> #include <boost/mpl/list.hpp>
> #include <boost/mpl/push_front.hpp>
>
> int main()
> {
> namespace mpl = boost::mpl;
>
> using L = mpl::list<>;
> using L2 = mpl::push_front<L, void>;
> }
>
> works.
>
> The reason is
>
> # elif defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) ||
> !defined __EDG__ || defined(__INTELLISENSE__) ||
> defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 1700)
> # define BOOST_PP_VARIADICS 1
> # undef BOOST_PP_VARIADICS_MSVC
> # define BOOST_PP_VARIADICS_MSVC 1
>
> which defines BOOST_PP_VARIADICS_MSVC for Clang and must not.

I am well aware of what is in config.hpp and why.

>
> You can tell Clang to not define _MSC_VER (-fmsc-version="0"), but MS's
> headers don't work with that yet (although STL said they are going to.)
>
> -fno-ms-compatibility is default for Clang/C2 at least, so I think that
> the above should just define BOOST_PP_VARIADICS_MSVC to 0 on Clang.

My problem is that I do not know what -fno-ms-compatibility sets as
predefined macros. I suppose I can test it and then try to adjust
config.hpp accordingly but I hate doing something when there is no
documentation and things can change anytime clang, or is it Microsoft
with Clang/C2, gets it in their head to change things again. I do not
even know what -fno-ms-compatibility does as far as the preprocessor is
concerned; does this mean we are back to clang's normal C++ standard
preprocessor as in clang for Linux or clang for Windows targeting
mingw(-64)/gcc ? I know I am being unreasonably stubborn but I
absolutely hate it when clang or a Microsoft refuses to document
something and then expects everyone to jump through hoops trying to
figure out what they have done and/or react to what they decide to do
next. My guess, through some unofficial blogs, is that
-fno-ms-compatibility sets __clang__, _MSC_VER, and __GNUC__ to various
values.

I can test this with various releases of clang and the clang-win
toolset, but I have no idea even how to invoke clang/C2 in
VS2015/VS2017, since there is no documentation about clang/C2 in the
former and there is no documentation for anything in the latter.

[Peter Dimov via Boost]

Edward Diener wrote:

> My problem is that I do not know what -fno-ms-compatibility sets as
> predefined macros.

Well given that BOOST_PP_VARIADICS_MSVC=0 works at least some of the time
and BOOST_PP_VARIADICS_MSVC=1 never works, it seems to me that the choice is
a rather easy one and does not depend on any predefined macros.

[Edward Diener via Boost]

On 3/25/2017 12:46 PM, Peter Dimov via Boost wrote:
> Edward Diener wrote:
>
>> My problem is that I do not know what -fno-ms-compatibility sets as
>> predefined macros.
>
> Well given that BOOST_PP_VARIADICS_MSVC=0 works at least some of the
> time and BOOST_PP_VARIADICS_MSVC=1 never works, it seems to me that the
> choice is a rather easy one and does not depend on any predefined macros.

I am not sure what you are saying here:

1) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for clang
targeting VC++ allows that compiler to work with BoostPP ?

2) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for clang
targeting VC++, allows that compiler to work with BoostPP when
-fno-ms-compatibility is defined ?

3) 2) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for clang
targeting VC++, allows clang/C2 to work with BoostPP when
-fno-ms-compatibility is defined ?

Or are you telling me something else ?

[Peter Dimov via Boost]

Edward Diener wrote:
On 3/25/2017 12:46 PM, Peter Dimov via Boost wrote:
> > Well given that BOOST_PP_VARIADICS_MSVC=0 works at least some of the
> > time and BOOST_PP_VARIADICS_MSVC=1 never works, it seems to me that the
> > choice is a rather easy one and does not depend on any predefined
> > macros.
>
> I am not sure what you are saying here:
>
> 1) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for clang
> targeting VC++ allows that compiler to work with BoostPP ?
>
> 2) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for clang
> targeting VC++, allows that compiler to work with BoostPP
> when -fno-ms-compatibility is defined ?
>
> 3) 2) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for clang
> targeting VC++, allows clang/C2 to work with BoostPP
> when -fno-ms-compatibility is defined ?

I'm telling you 3)2), yes, at least for this simple MPL program I tested.

If I could get b2 to work with Clang/C2, I would have run the tests, but I'm
not sure I can do that.

I'm also telling you that since BOOST_PP_VARIADICS_MSVC=1 never works with
any Clang, there is perhaps no reason to ever set it to 1 regardless of what
Clang it is and what options have been defined.

[Peter Dimov via Boost]

> I'm also telling you that since BOOST_PP_VARIADICS_MSVC=1 never works with
> any Clang, there is perhaps no reason to ever set it to 1 regardless of
> what Clang it is and what options have been defined.

Unless of course BOOST_PP_VARIADICS_MSVC=1 works on some Clang
configurations - you know better than me if that's the case, but I was left
with the impression that you consider Clang in -fms-compatibility mode
hopelessly broken.

[Edward Diener via Boost]

On 3/25/2017 4:37 PM, Peter Dimov via Boost wrote:
> Edward Diener wrote:
> On 3/25/2017 12:46 PM, Peter Dimov via Boost wrote:
>> > Well given that BOOST_PP_VARIADICS_MSVC=0 works at least some of the
>> > time and BOOST_PP_VARIADICS_MSVC=1 never works, it seems to me that
>> the > choice is a rather easy one and does not depend on any
>> predefined > macros.
>>
>> I am not sure what you are saying here:
>>
>> 1) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for clang
>> targeting VC++ allows that compiler to work with BoostPP ?
>>
>> 2) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for clang
>> targeting VC++, allows that compiler to work with BoostPP when
>> -fno-ms-compatibility is defined ?
>>
>> 3) 2) Are you saying that turning off BOOST_PP_VARIADICS_MSVC for
>> clang targeting VC++, allows clang/C2 to work with BoostPP when
>> -fno-ms-compatibility is defined ?
>
> I'm telling you 3)2), yes, at least for this simple MPL program I tested.

I meant to write "3)" and not "3)2)" above. Sorry !

Try running all the Boost PP tests <g>. I would be very surprised if
they worked in -fno-ms-compatibility mode. I will try it myself with
clang targeting VC++ using clang-win.

>
> If I could get b2 to work with Clang/C2, I would have run the tests, but
> I'm not sure I can do that.

Touche ! I am not sure whether to use clang ( clang-linux ) or
clang-win, but I am guessing the latter is the right match. Also I still
don't know how to invoke clang/C2. I will look in the VS2015/VS2017
directory structure unless you know what it is called and where it is ?

>
> I'm also telling you that since BOOST_PP_VARIADICS_MSVC=1 never works
> with any Clang, there is perhaps no reason to ever set it to 1
> regardless of what Clang it is and what options have been defined.

Well I can change config.hpp to reflect that. Ideally if clang targeting
VC++ actually emulated the VC++ non-standard preprocessor perfectly
BOOST_PP_VARIADICS_MSVC=1 would absolutely have to be defined in order
for clang targeting VC++ to work properly with Boost PP. That is the
obvious reason why it has been used in that situation.

[Peter Dimov via Boost]

Edward Diener wrote:

> Try running all the Boost PP tests <g>. I would be very surprised if they
> worked in -fno-ms-compatibility mode. I will try it myself with clang
> targeting VC++ using clang-win.

Even if all the PP tests don't pass, if what MPL needs works, that would at
least solve Paul's immediate problem. (And not only his, I suppose.)

[degski via Boost]

Some description (defined macros, defines identifying the toolset, and
installation) can be found here
<https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-codegen-in-vs-2015-update-1/>
.

degski

[Peter Dimov via Boost]

Edward Diener wrote:
> Try running all the Boost PP tests <g>. I would be very surprised if they
> worked in -fno-ms-compatibility mode. I will try it myself with clang
> targeting VC++ using clang-win.

I tried and failed. Clang/C2 in VS 2017 is in

C:\Program Files (x86)\Microsoft Visual

Studio\2017\Community\VC\Tools\ClangC2\14.10.25903\bin\HostX86\clang.exe

so I put

using clang : 14.1 : "C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe" :
<cxxflags>-fno-ms-compatibility <linkflags>-v ;

in user-config.jam. This failed with "can't find c2". I then tried a VS2017
developer command prompt. Clang then compiles, but linking fails with:

clang-linux.link
..\..\bin.v2\libs\mp11\test\mp_remove_if.test\clang-linux-14.1\
debug\mp_remove_if.exe
clang with Microsoft CodeGen version 3.8.0
Provided as - is without support

C:\Program Files (x86)\Microsoft Visual

Studio\2017\Community\VC\Tools\ClangC2\14.10.25903\bin\HostX86\x86\c2.dll
version 19.10.25903.0
Target: i686-pc-windows-msvc
Thread model: posix
InstalledDir: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86
"link.exe"
"-out:..\\..\\bin.v2\\libs\\mp11\\test\\mp_remove_if.test\\clang-linux-14.1\\debug\\mp_remove_if.exe"
-defaultlib:libcmt -nologo -debug --start-group
"..\\..\\bin.v2\\libs\\mp11\\test\\mp_remove_if.test\\clang-linux-14.1\\debug\\mp_remove_if.obj"
-Bstatic -Bdynamic --end-group
clang.exe: error: unable to execute command: program not executable
clang.exe: error: linker command failed with exit code 1 (use -v to see
invocation)

So, Clang/C2 can't link for some reason. The link rule probably needs to be
changed to use link.exe, but that's beyond my capabilities right now.

> Ideally if clang targeting VC++ actually emulated the VC++ non-standard
> preprocessor perfectly BOOST_PP_VARIADICS_MSVC=1 would absolutely have to
> be defined in order for clang targeting VC++ to work properly with Boost
> PP.

Bug compatibility with cl.exe has never been a Clang goal. The point
of -fms-compatibility was to compile MS's headers. Those however have
improved to a point where they work in -fno-ms-compatibility mode, and this
is default in 2017 now.

So I think that we can ignore -fms-compatibility from now on as there's no
need to use it.

[Peter Dimov via Boost]

> So, Clang/C2 can't link for some reason.

It occurred to me that the PP tests don't need to link. So,

...failed updating 25 targets...
...skipped 26 targets...
...updated 118 targets...

...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\array.test\clang-linux-14.1\debug\array.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\list.test\clang-linux-14.1\debug\list.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\arithmetic_nvm.test\clang-linux-14.1\debug\arithmetic_nvm.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\array_nvm.test\clang-linux-14.1\debug\array_nvm.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\comparison_nvm.test\clang-linux-14.1\debug\comparison_nvm.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\control_nvm.test\clang-linux-14.1\debug\control_nvm.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\iteration_nvm.test\clang-linux-14.1\debug\iteration_nvm.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\list_nvm.test\clang-linux-14.1\debug\list_nvm.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\repetition_nvm.test\clang-linux-14.1\debug\repetition_nvm.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\selection_nvm.test\clang-linux-14.1\debug\selection_nvm.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\seq_nvm.test\clang-linux-14.1\debug\seq_nvm.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\tuple_nvm.test\clang-linux-14.1\debug\tuple_nvm.obj...
...failed clang-linux.compile.c.without-pth
..\..\bin.v2\libs\preprocessor\test\array_c.test\clang-linux-14.1\debug\array_c.obj...
...failed clang-linux.compile.c.without-pth
..\..\bin.v2\libs\preprocessor\test\list_c.test\clang-linux-14.1\debug\list_c.obj...
...failed clang-linux.compile.c.without-pth
..\..\bin.v2\libs\preprocessor\test\arithmetic_c_nvm.test\clang-linux-14.1\debug\arithmetic_c_nvm.obj...
...failed clang-linux.compile.c.without-pth
..\..\bin.v2\libs\preprocessor\test\array_c_nvm.test\clang-linux-14.1\debug\array_c_nvm.obj...
...failed clang-linux.compile.c.without-pth
..\..\bin.v2\libs\preprocessor\test\comparison_c_nvm.test\clang-linux-14.1\debug\comparison_c_nvm.obj...
...failed clang-linux.compile.c.without-pth
..\..\bin.v2\libs\preprocessor\test\control_c_nvm.test\clang-linux-14.1\debug\control_c_nvm.obj...
...failed clang-linux.compile.c.without-pth
..\..\bin.v2\libs\preprocessor\test\list_c_nvm.test\clang-linux-14.1\debug\list_c_nvm.obj...
...failed clang-linux.compile.c.without-pth
..\..\bin.v2\libs\preprocessor\test\selection_c_nvm.test\clang-linux-14.1\debug\selection_c_nvm.obj...
...failed clang-linux.compile.c.without-pth
..\..\bin.v2\libs\preprocessor\test\seq_c_nvm.test\clang-linux-14.1\debug\seq_c_nvm.obj...
...failed clang-linux.compile.c.without-pth
..\..\bin.v2\libs\preprocessor\test\tuple_c_nvm.test\clang-linux-14.1\debug\tuple_c_nvm.obj...
...failed clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\isempty_nvm.test\clang-linux-14.1\debug\isempty_nvm.obj...
...failed clang-linux.compile.c.without-pth
..\..\bin.v2\libs\preprocessor\test\isempty_c_nvm.test\clang-linux-14.1\debug\isempty_c_nvm.obj...

clang.exe: error: linker command failed with exit code 1 (use -v to see
invocation)

...failed clang-linux.link
..\..\bin.v2\libs\preprocessor\test\config_info.test\clang-linux-14.1\debug\config_info.exe...

All the _nvm failures are an invalid token paste, which shouldn't in
principle happen in a strict configuration, and are probably not something
users will encounter because they disable BOOST_PP_VARIADICS by hand.

Full failure log attached.

[Peter Dimov via Boost]

> > So, Clang/C2 can't link for some reason.
>
> It occurred to me that the PP tests don't need to link. So,
>
> ...failed updating 25 targets...
> ...skipped 26 targets...
> ...updated 118 targets...

This is with

C:\Projects\boost-git\boost\libs\preprocessor>git diff
diff --git a/include/boost/preprocessor/config/config.hpp
b/include/boost/prepro
index 4801903..10778d8 100644
--- a/include/boost/preprocessor/config/config.hpp
+++ b/include/boost/preprocessor/config/config.hpp
@@ -79,7 +79,7 @@

# elif defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) ||
!defin

# define BOOST_PP_VARIADICS 1
# undef BOOST_PP_VARIADICS_MSVC

-# define BOOST_PP_VARIADICS_MSVC 1
+# define BOOST_PP_VARIADICS_MSVC 0
# /* Wave (C/C++), GCC (C++) */
# elif defined __WAVE__ && __WAVE_HAS_VARIADICS__ || defined __GNUC__ &&
def
# define BOOST_PP_VARIADICS 1
@@ -94,7 +94,7 @@
# define BOOST_PP_VARIADICS 1
# if defined _MSC_VER && _MSC_VER >= 1400 && (defined(__clang__) ||
defined(
# undef BOOST_PP_VARIADICS_MSVC
-# define BOOST_PP_VARIADICS_MSVC 1
+# define BOOST_PP_VARIADICS_MSVC 0
# endif
# else
# undef BOOST_PP_VARIADICS

[Edward Diener via Boost]

Sure but that is not right in the long run because you are turning it
off for VC++ also.

[Peter Dimov via Boost]

Edward Diener wrote:

> Sure but that is not right in the long run because you are turning it off
> for VC++ also.

It's not, I temporarily switched it off just for the test.

[Edward Diener via Boost]

I have updated Boost PP on the develop branch to support the
-fno-ms-compatibility mode of clang targeting VC++ or clang/C2. I still
get plenty of errors with clang 4.0 using clang-win and
-fno-ms-compatibility when running the Boost PP tests, but maybe it is
good enough for MPL although I highly doubt even in that case it would
be good enough for all the other Boost libraries that use Boost PP.

As I have expressed in the past this is a miasma created by the clang
team trying to accomodate Microsoft and VC++, as well as Microsoft
wanting to use clang and their hybridized and buggy VC++ like preprocessor.

This would have all been avoided if Microsoft had not created their own
non-standard C++ preprocessor and held onto it for over a quarter of a
century.

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Peter Dimov via Boost
> Sent: 26 March 2017 00:52
> To: bo...@lists.boost.org
> Cc: Peter Dimov
> Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
>

> Edward Diener wrote:
>
> > Try running all the Boost PP tests <g>. I would be very surprised if they
> > worked in -fno-ms-compatibility mode. I will try it myself with clang
> > targeting VC++ using clang-win.
>
> Even if all the PP tests don't pass, if what MPL needs works, that would at
> least solve Paul's immediate problem. (And not only his, I suppose.)

My current needs are indeed quite simple (and might be circumnavigated by removing use of float_distance.hpp (thus next.hpp)
checking the generation of some simple numerical code.

So I'll give that all a try.

I remain still confused as to what controls the choice of clang-linux and clang-win, and what needs to switched. Perhaps trying to
use some of the features in

https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-codegen-in-vs-2015-update-1/

will enlighten me.

With the compatibility mode on, and providing an include to the MSVC cstddef, I still get references to clang-linux. So does this
mean that I am/should be using mingw cstddef and libstd++ for STL?

I'm very grateful for the all thought and work going into this meanwhile.

Does all this mean that I would be better off getting the very newest VS update? (A task that I need to do anyway sometime).

Thanks

Paul

[Peter Dimov via Boost]

Edward Diener wrote:

> I have updated Boost PP on the develop branch to support
> the -fno-ms-compatibility mode of clang targeting VC++ or clang/C2.

...failed updating 1 target...
...skipped 2 targets...
...updated 133 targets...

The only error is config_info.exe, because my Clang configuration can't
link, as explained.

My two errors in my previous run were (1) forgetting to patch the first
_MSC_VER section to use strict and (2) using <cxxflags>
for -fno-ms-compatibility, which left all C tests in -fms-compatibility
mode.

No idea why it doesn't work for you.

[Edward Diener via Boost]

On 3/26/2017 1:38 AM, Paul A. Bristow via Boost wrote:
>> -----Original Message-----
>> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Peter Dimov via Boost
>> Sent: 26 March 2017 00:52
>> To: bo...@lists.boost.org
>> Cc: Peter Dimov
>> Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
>>
>> Edward Diener wrote:
>>
>>> Try running all the Boost PP tests <g>. I would be very surprised if they
>>> worked in -fno-ms-compatibility mode. I will try it myself with clang
>>> targeting VC++ using clang-win.
>>
>> Even if all the PP tests don't pass, if what MPL needs works, that would at
>> least solve Paul's immediate problem. (And not only his, I suppose.)
>
> My current needs are indeed quite simple (and might be circumnavigated by removing use of float_distance.hpp (thus next.hpp)
> checking the generation of some simple numerical code.
>
> So I'll give that all a try.
>
> I remain still confused as to what controls the choice of clang-linux and clang-win, and what needs to switched.

Normal use of the clang toolset means clang-linux on Linux and Windows,
and clang-darwin on the Mac.

> Perhaps trying to
> use some of the features in
>
> https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-codegen-in-vs-2015-update-1/
>
> will enlighten me.

This probably needs the clang-win toolset since the backend is VC++ as I
understand it, even with -fno-ms-compatibility. However because the docs
are mostly non-existent I really do not know ( or personally care
because I would not touch clang targeting VC++ as it is now implemented
in the preprocessor ).

[Peter Dimov via Boost]

> Edward Diener wrote:
>
> > I have updated Boost PP on the develop branch to support
> > the -fno-ms-compatibility mode of clang targeting VC++ or clang/C2.
>
> ...failed updating 1 target...
> ...skipped 2 targets...
> ...updated 133 targets...

For reference, results in -fms-compatibility:

...failed updating 45 targets...
...skipped 46 targets...
...updated 45 targets...

And same, but using the strict config here as well:

...failed updating 2 targets...
...skipped 3 targets...
...updated 131 targets...

So, as I suspected, detecting -fno-ms-compatibility using __GNUC__ makes
things worse.



-# elif defined(_MSC_VER) && defined(__clang__) && defined(__GNUC__)
// -fno-ms-compatibility mode
+# elif defined(_MSC_VER) && defined(__clang__)

-# elif defined(_MSC_VER) && defined(__clang__) && defined(__GNUC__)
// -fno-ms-compatibility mode
+# elif defined(_MSC_VER) && defined(__clang__)

-# if defined _MSC_VER && _MSC_VER >= 1400 && !(defined(__clang__) &&
defined(__GNUC__)) && (defined(__clang__) || defined(__INTELLISENSE__) ||
(defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 1700) || !(defined __EDG__
|| defined __GCCXML__ || defined __CUDACC__ || defined __PATHSCALE__ ||
defined __DMC__ || defined __CODEGEARC__ || defined __BORLANDC__ || defined
__MWERKS__ || defined __SUNPRO_CC || defined __HP_aCC || defined __MRC__ ||
defined __SC__ || defined __IBMCPP__ || defined __PGI))
+# if defined _MSC_VER && _MSC_VER >= 1400 && !(defined(__clang__)) &&
(defined(__clang__) || defined(__INTELLISENSE__) ||
(defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 1700) || !(defined __EDG__
|| defined __GCCXML__ || defined __CUDACC__ || defined __PATHSCALE__ ||
defined __DMC__ || defined __CODEGEARC__ || defined __BORLANDC__ || defined
__MWERKS__ || defined __SUNPRO_CC || defined __HP_aCC || defined __MRC__ ||
defined __SC__ || defined __IBMCPP__ || defined __PGI))

The failing test is seq.cpp, with

clang-linux.compile.c++.without-pth
..\..\bin.v2\libs\preprocessor\test\seq.test\clang-linux-14.1\debug\seq.obj
In file included from test\seq.cpp:14:
..\..\libs/preprocessor/test/seq.cxx:213:42: error: too few arguments

provided to function-like macro invocation

BEGIN BOOST_PP_IS_EMPTY(BOOST_PP_LIST_AT(BOOST_PP_SEQ_TO_LIST(SEQ_NONE),0))
== 1 END

No idea why only seq.cpp fails, as seq.c should be the same.

[Peter Dimov via Boost]

> > Edward Diener wrote:
> >
> > > I have updated Boost PP on the develop branch to support
> > > the -fno-ms-compatibility mode of clang targeting VC++ or clang/C2.
> >
> > ...failed updating 1 target...
> > ...skipped 2 targets...
> > ...updated 133 targets...
>
> For reference, results in -fms-compatibility:
>
> ...failed updating 45 targets...
> ...skipped 46 targets...
> ...updated 45 targets...
>
> And same, but using the strict config here as well:
>
> ...failed updating 2 targets...
> ...skipped 3 targets...
> ...updated 131 targets...

LLVM 4.0.0 Clang (using clang-linux toolset), -fno-ms-compatibility:

...failed updating 1 target...
...skipped 3 targets...
...updated 262 targets...

The failure is because you pass -std=c++0x, but MS's headers indirectly
included by config_info use C++14 features. Should work with -std=c++14.

-fms-compatibility (using the strict config, as patched):

...failed updating 1 target...
...skipped 3 targets...
...updated 132 targets...

This one doesn't even fail seq.cpp, was probably a bug they fixed.

No idea why you couldn't get it to work, all I did was install LLVM in
C:\LLVM and then added

using clang : 4.0 :
"C:/LLVM/bin/clang.exe" :
<compileflags>-fno-ms-compatibility ;

in user-config.jam. I probably don't even need the <compileflags>, it works
either way.

[Peter Dimov via Boost]

Edward Diener wrote:

> This probably needs the clang-win toolset since the backend is VC++ as I
> understand it, even with -fno-ms-compatibility.

Not sure why you'd want to use clang-win at present; I use clang-linux for
everything.

[Peter Dimov via Boost]

> The failure is because you pass -std=c++0x, but MS's headers indirectly
> included by config_info use C++14 features. Should work with -std=c++14.

Actually no, it was because I needed to set _MSC_VER
using -fmsc-version=1910.

using clang : 4.0 :
"C:/LLVM/bin/clang.exe" :

<compileflags>-fmsc-version=1910 <linkflags>-v ;

And now it fails to link with the usual mysterious

clang-linux.link
..\..\bin.v2\libs\preprocessor\test\config_info.test\clang-linux-4.0\debug\config_info.exe
clang version 4.0.0 (tags/RELEASE_400/final)

Target: i686-pc-windows-msvc
Thread model: posix

InstalledDir: C:\LLVM\bin
"link.exe"
"-out:..\\..\\bin.v2\\libs\\preprocessor\\test\\config_info.test\\clang-linux-4.0\\debug\\config_info.exe"

-defaultlib:libcmt -nologo -debug --start-group

"..\\..\\bin.v2\\libs\\preprocessor\\test\\config_info.test\\clang-linux-
4.0\\debug\\config_info.obj" -Bstatic -Bdynamic --end-group

clang.exe: error: unable to execute command: program not executable

clang.exe: error: linker command failed with exit code 1 (use -v to see
invocation)

about which problem I can't find anything sensible.

> Not sure why you'd want to use clang-win at present; I use clang-linux for
> everything.

So here's why, I suppose.

Either way, I can't link, but at least the PP lib works (once the __GNUC__
checks are removed).

[Peter Dimov via Boost]

> using clang : 4.0 :
> "C:/LLVM/bin/clang.exe" :
> <compileflags>-fmsc-version=1910 <linkflags>-v ;
>
> And now it fails to link with the usual mysterious

...

> clang.exe: error: unable to execute command: program not executable
> clang.exe: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> about which problem I can't find anything sensible.

A-ha.

using clang : 4.0 :
"C:/LLVM/bin/clang.exe" :

<compileflags>-fmsc-version=1910 <linkflags>-fuse-ld=lld ;

This whines about

ignoring unknown argument: --start-group
ignoring unknown argument: -Bstatic
ignoring unknown argument: -Bdynamic
ignoring unknown argument: --end-group

because lld takes MS link.exe command-line options, not GNU ld, but it
links.

[Peter Dimov via Boost]

Paul A. Bristow wrote:

> I remain still confused as to what controls the choice of clang-linux and
> clang-win, and what needs to switched.

If you just need to test things using "b2 test toolset=clang", I repeat my
recommendation of using Cygwin. It has g++ 6.3 and clang 3.9, and they work
more or less "out of the box". The only thing I did was symlink
clang-3.9.exe to clang++.exe.

[Edward Diener via Boost]

On 3/26/2017 4:06 AM, Peter Dimov via Boost wrote:
> Edward Diener wrote:
>
>> I have updated Boost PP on the develop branch to support the
>> -fno-ms-compatibility mode of clang targeting VC++ or clang/C2.
>
> ...failed updating 1 target...
> ...skipped 2 targets...
> ...updated 133 targets...
>
> The only error is config_info.exe, because my Clang configuration can't
> link, as explained.
>
> My two errors in my previous run were (1) forgetting to patch the first
> _MSC_VER section to use strict and (2) using <cxxflags> for
> -fno-ms-compatibility, which left all C tests in -fms-compatibility mode.
>
> No idea why it doesn't work for you.

I did forget about "cflags=-fno-ms-compatibility" in my testing. Now I
see that with both "cxxflags=-fno-ms-compatibility" and
"cflags=-fno-ms-compatibility" the Boost PP tests all pass for clang
using -fno-ms-compatibility and the clang-win toolset. Well I am
certainly glad it worked and that clang targeting VC++ using
-fno-ms-compatibility does work with my latest fix of Boost PP on the
develop branch.

Since that update only affects Boost PP when using clang in
-fno-ms-compatibility mode ( aka clang targeting VC++ with
-fno-ms-compatibility turned on ) I wonder If it is not too late to get
it into the 'master' branch for the upcoming 1.64 release. Of course the
Boost PP regression tests on the develop branch will not have cycled
yet, but this fix may be important for VC++ developers wanting to use
clang/C2 and Boost.

However there are still some problems with the clang-win jam file which
I am not experienced enough with Boost Build to solve, so others will
need to figure them out. These are some PRs for Boost Build relating to
those problems.

You seem to be using the clang.jam file instead. I do not know how you
are supposed to get that to work with clang targeting VC++ or clang/C2,
but I strongly believe that my Boost PP config.hpp for
-fno-ms-compatibility is correct. I could not follow on your subsequent
posts what you are doing so if you can stick to a single reply it would
be appreciated.

[Peter Dimov via Boost]

Edward Diener wrote:

> but I strongly believe that my Boost PP config.hpp
> for -fno-ms-compatibility is correct. I could not follow on your
> subsequent posts what you are doing so if you can stick to a single reply
> it would be appreciated.

TL;DR as I said yesterday, you need to to the changes unconditionally for
__clang__ and not look at __GNUC__.

[degski via Boost]

On 26 March 2017 at 08:07, Edward Diener via Boost <bo...@lists.boost.org>
wrote:

> This probably needs the clang-win toolset since the backend is VC++ ...
>

This *surely* needs the clang-win toolset since one is (wants to be) using
the Dinkumware (VC++'s) STL. Clang/C2 is using the VC++ backend C2 (the
VC++ (cl.exe) frontend is called C1), while Clang/LLVM is using the LLVM
backend (LLVM), not any VC++ backend.

I'm happy to be corrected, and please do, if my understanding of matters is
wrong, in which case I apoligize up front for rambling on about this.

degski

[Edward Diener via Boost]

On 3/26/2017 7:59 AM, Peter Dimov via Boost wrote:
> Edward Diener wrote:
>
>> but I strongly believe that my Boost PP config.hpp for
>> -fno-ms-compatibility is correct. I could not follow on your
>> subsequent posts what you are doing so if you can stick to a single
>> reply it would be appreciated.
>
> TL;DR as I said yesterday, you need to to the changes unconditionally
> for __clang__ and not look at __GNUC__.

I do not understand this. You are saying that __clang__ being defined
and _MSC_VER being defined should always be strict compliance with
variadics turned on but without any VC++ related fixes ? What about the
so-called emulation by clang of the non-standard VC++ preprocessor ? it
does not work of course but you still want me to ignore it completely
and consider that clang targeting VC++ ( aka clang-cl in clang for
Windows ) uses a C++ standard preprocessor ?

[Peter Dimov via Boost]

Edward Diener wrote:
On 3/26/2017 7:59 AM, Peter Dimov via Boost wrote:
>
> > TL;DR as I said yesterday, you need to to the changes unconditionally
> > for __clang__ and not look at __GNUC__.
>
> I do not understand this. You are saying that __clang__ being defined and
> _MSC_VER being defined should always be strict compliance with variadics
> turned on but without any VC++ related fixes ?

Yes.

Before the changes:

clang -fms-compatibility: broken
clang -fno-ms-compatibility: broken

After your changes (conditional upon __GNUC__):

clang -fms-compatibility: broken
clang -fno-ms-compatibility: working

After same changes, unconditional:

clang -fms-compatibility: working
clang -fno-ms-compatibility: working

> What about the so-called emulation by clang of the non-standard VC++
> preprocessor ?

There apparently exists no such emulation, at least as far as the PP tests
show. Maybe it existed once, I don't know, but this doesn't seem to be the
case today.

[Peter Dimov via Boost]

degski wrote:

> This *surely* needs the clang-win toolset since one is (wants to be) using
> the Dinkumware (VC++'s) STL.

LLVM Clang finds and uses the 14.1 headers for me when using the clang-linux
toolset. I could tell because it gave me errors in these headers when I
wasn't supplying -fms-version=1910.

clang-win is outdated. It's predicated on the assumption that the Windows
Clang would be a separate animal, a drop-in replacement for Microsoft's
cl.exe. This was the original plan, but it has been abandoned for at least a
year now, if not more. Clang under Windows is more or less the same as Clang
under Linux now, except that it targets the Microsoft ABI (and fails to
link). Visual Studio 2017 doesn't use clang-cl.exe, it understands Clang's
options natively and uses clang.exe.

A proper clang-win toolset today would treat Clang as Clang, not as cl.exe,
only it would replace the link phase with a working one.

And a proper clang-c2 toolset would do the same except it would use
14.0/14.1 as the version and look for clang.exe at the appropriate
locations.

[Edward Diener via Boost]

On 3/26/2017 8:28 AM, Peter Dimov via Boost wrote:
> Edward Diener wrote:
> On 3/26/2017 7:59 AM, Peter Dimov via Boost wrote:
>>
>> > TL;DR as I said yesterday, you need to to the changes
>> unconditionally > for __clang__ and not look at __GNUC__.
>>
>> I do not understand this. You are saying that __clang__ being defined
>> and _MSC_VER being defined should always be strict compliance with
>> variadics turned on but without any VC++ related fixes ?
>
> Yes.
>
> Before the changes:
>
> clang -fms-compatibility: broken
> clang -fno-ms-compatibility: broken
>
> After your changes (conditional upon __GNUC__):
>
> clang -fms-compatibility: broken
> clang -fno-ms-compatibility: working
>
> After same changes, unconditional:
>
> clang -fms-compatibility: working
> clang -fno-ms-compatibility: working
>
>> What about the so-called emulation by clang of the non-standard VC++
>> preprocessor ?
>
> There apparently exists no such emulation, at least as far as the PP
> tests show. Maybe it existed once, I don't know, but this doesn't seem
> to be the case today.

You are absolutely correct and I have updated Boost PP on the 'develop'
branch accordingly.

I did see a few errors testing clang 3.8.1 clang-cl, but with clang
3.9.1 clang-cl, clang 4.0 clang-cl, and the latest clang built from
source clang-cl all Boost PP tests passed. I did use clang-win.jam.

How did you get just clang.jam to work ? Doesn't it need VC++ support
when using clang-cl ?

[Peter Dimov via Boost]

Edward Diener wrote:

> How did you get just clang.jam to work ? Doesn't it need VC++ support when
> using clang-cl ?

I installed LLVM 4.0 in C:\LLVM and put

using clang : 4.0 :
"C:/LLVM/bin/clang.exe" :
<compileflags>-fmsc-version=1910 <linkflags>-fuse-ld=lld ;

in my user-config.jam. It found my VS 2017 installation by itself. There was
no need to use the developer command prompt or put anything into PATH.

[Edward Diener via Boost]

On 3/26/2017 12:10 PM, Peter Dimov via Boost wrote:
> Edward Diener wrote:
>
>> How did you get just clang.jam to work ? Doesn't it need VC++ support
>> when using clang-cl ?
>
> I installed LLVM 4.0 in C:\LLVM and put
>
> using clang : 4.0 :
> "C:/LLVM/bin/clang.exe" :
> <compileflags>-fmsc-version=1910 <linkflags>-fuse-ld=lld ;
>
> in my user-config.jam. It found my VS 2017 installation by itself. There
> was no need to use the developer command prompt or put anything into PATH.

That works fine for the Boost PP tests. I will have to try it with other
libraries, like MPL, but hopefully it is an answer to Paul's original
problem using my latest Boost PP fix on 'develop'.

I also tried invoking clang-cl instead of clang++, but it failed
miserably because it did was not able to process the options generated
by the clang-linux.jam file.

[degski via Boost]

On 26 March 2017 at 09:39, Peter Dimov via Boost <bo...@lists.boost.org>
wrote:

> LLVM Clang finds and uses the 14.1 headers for me when using the
> clang-linux toolset. I could tell because it gave me errors in these
> headers when I wasn't supplying -fms-version=1910.
>

It seeems to me that that was not was intended. But having said that, if
clang-linux works (with the Dinkumware STL), then progress is definitely
being made and we're moving towards having just clang-any (on the 3 major
platforms). I (and I guess I'm not alone) really appreciate the work (by
yourself and others) that is being put into this!


> clang-win is outdated.


Yes, it's lagging, but I would say the only benefit is the better debugging.

> Clang under Windows is more or less the same as Clang under Linux now,
> except that it targets the Microsoft ABI (and fails to link).

Don't know about linking, must be a path problem or something to do with
the clang-*linux* bit (ELF?). I'm using Clang/LLVM (from the VS2015 IDE) on
a daily basis, no issues.

> Visual Studio 2017 doesn't use clang-cl.exe, it understands Clang's
> options natively and uses clang.exe.
>

Great, cannot wait getting back home from Central-America to Central
-Europe, so I can give it a try, as hotel WIFI is flaky here. Are you
talking about Clang/C2 or Clang/LLVM?

> A proper clang-win toolset today would treat Clang as Clang, not as
> cl.exe, only it would replace the link phase with a working one.
>

+1

> And a proper clang-c2 toolset would do the same except it would use
> 14.0/14.1 as the version and look for clang.exe at the appropriate
> locations.

If Clang/LLVM works as any Clang, the only difference should be the
backend. Obviously, one can only hope for this to work with VC14.1(0) or
higher...

degski

[degski via Boost]

Just noticed the following, compiling:

#if __cplusplus >= 201103L
#error This library uses a C++11 compliant compiler
#else
#error This library will benefit from a C++11 compliant compiler
#endif

Compiling this with VC14, update 3, (options, a.o.) /std:c++latest, the
second line is generated as an error. Compiling this with Clang/LLVM
(option a.o.) -std=c++1y results in the first error being produced.

It is this bug
https://connect.microsoft.com/VisualStudio/feedback/details/763051/a-value-of-predefined-macro-cplusplus-is-still-199711l

A value of predefined macro __cplusplus is still 199711L - by Barfy
Status : Closed as Deferred

Maybe relevant in the context of this thread?

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Peter Dimov via Boost
> Sent: 26 March 2017 17:11
> To: bo...@lists.boost.org
> Cc: Peter Dimov
> Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
>

> Edward Diener wrote:
>
> > How did you get just clang.jam to work ? Doesn't it need VC++ support when
> > using clang-cl ?
>
> I installed LLVM 4.0 in C:\LLVM and put
>
> using clang : 4.0 :
> "C:/LLVM/bin/clang.exe" :
> <compileflags>-fmsc-version=1910 <linkflags>-fuse-ld=lld ;
>
> in my user-config.jam. It found my VS 2017 installation by itself. There was
> no need to use the developer command prompt or put anything into PATH.

I'm trying to walk before I can run (but have stumbled :-( )

I:\modular-boost\libs\hello_boost\example\jamfile.v2 just calls run hello_boost.cpp ;

I have pulled Edward's pre-processor update
https://github.com/boostorg/preprocessor/commit/dfc1c46ecedef21274eb142e267e91400aa33ec8

and tried this in my user_config.jam

with discouraging results.

It picks up the compiler as expected (I think)

notice: will use 'C:/LLVM/bin/clang.exe' for clang-linux, condition <toolset>clang-linux-4.0.0

but doesn't find any targets or do anything beyond config checks???

Performing configuration checks

- 32-bit : no (cached)
- 64-bit : yes (cached)
- arm : no (cached)
- mips1 : no (cached)
- power : no (cached)
- sparc : no (cached)
- x86 : yes (cached)
- symlinks supported : yes (cached)

delete I:\modular-boost\bin.v2\libs\hello_boost to check what is created. But there is no expected folders and files here.

But I still only have VS 2015 14.0.25402.00 update 3RC - does this mean I need to update? (Sigh)

Or use a different <compileflags>-fmsc-version=1910 ???

Or am I doing something silly?

But thanks for making progress on this - I still hope to catch up.

Paul

PS I would use Cygwin, but I already have mingw installed and changing would muck other things up.

[Peter Dimov via Boost]

Paul A. Bristow wrote:

> I:\modular-boost\libs\hello_boost\example\jamfile.v2 just calls run
> hello_boost.cpp ;

What are the entire contents of this Jamfile? Where does this hello_boost
come from?

[Edward Diener via Boost]

I use -fmsc-version=1900 for VS2015. My entry using the distributed
clang 4.0 version, which by default targets VC++, is:

using clang : 4.0 : C:/Utilities/LLVM/400/x32/bin/clang++
:
<cxxflags>-fmacro-backtrace-limit=0
<cxxflags>-Wno-invalid-token-paste
<compileflags>-fmsc-version=1900
<linkflags>-fuse-ld=lld
;

and is invoked with "toolset=clang-4.0".

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Peter Dimov via Boost
> Sent: 27 March 2017 16:03
> To: bo...@lists.boost.org
> Cc: Peter Dimov
> Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
>

> Paul A. Bristow wrote:
>
> > I:\modular-boost\libs\hello_boost\example\jamfile.v2 just calls run
> > hello_boost.cpp ;
>
> What are the entire contents of this Jamfile? Where does this hello_boost
> come from?

jamfile and hello_boost.cpp (a hello World that uses boost/config) attached.

As I feared, doing something silly.

Now I get something as bad - back to missing the cstddef file.

I've tried adding to user_config.jam

<cxxflags>"-IC:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include"

and as many other other variants as I can conceive, but the quoting is not working right and the compiler finds the space and stops
rather than finding the file. I think this is a bug in bjam? but I don't see how to get around it. I have added an INCLUDE=
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\ucrt

but I don't see how to add a second item using the windows environment Variable editor.

(Using the Codeblocks IDE - to confuse myself completely, adding this include folder as a Search directory allows some progress, at
least finding the MS <cstddef>).

Suggestions? And many thanks.

Paul

PS You didn't say if I really needed the most recent March 2017 VS update?



I:\modular-boost\libs\hello_boost\example>b2
Performing configuration checks

- 32-bit : yes (cached)

- arm : no (cached)
- mips1 : no (cached)
- power : no (cached)
- sparc : no (cached)
- x86 : yes (cached)
- symlinks supported : yes (cached)

...found 200 targets...
...updating 13 targets...
common.mkdir ..\..\..\bin.v2\libs\hello_boost
common.mkdir ..\..\..\bin.v2\libs\hello_boost\example
common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test
common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0
common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug
common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on
common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static
common.mkdir
..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static
compile-c-c++
..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static\hello
_boost.obj
hello_boost.cpp
msvc.link
..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static\hello
_boost.exe
msvc.manifest
..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static\hello
_boost.exe
testing.capture-output
..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static\hello
_boost.run
1 file(s) copied.
**passed**
..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\msvc-14.0\debug\asynch-exceptions-on\link-static\runtime-link-static\hello
_boost.test
...updated 13 targets...

I:\modular-boost\libs\hello_boost\example>b2 toolset=gcc-6.3.0

Performing configuration checks

- 32-bit : no

- 64-bit : yes
- arm : no
- mips1 : no
- power : no
- sparc : no
- x86 : yes
- symlinks supported : yes
...found 192 targets...
...updating 6 targets...
common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0
common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0\debug
gcc.compile.c++ ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0\debug\hello_boost.o
gcc.link ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0\debug\hello_boost.exe
testing.capture-output ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0\debug\hello_boost.run
1 file(s) copied.
**passed** ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\gcc-mingw-6.3.0\debug\hello_boost.test
...updated 6 targets...

I:\modular-boost\libs\hello_boost\example>b2 toolset=clang-4.0.0

Performing configuration checks

- 32-bit : no (cached)
- 64-bit : yes (cached)
- arm : no (cached)
- mips1 : no (cached)
- power : no (cached)
- sparc : no (cached)
- x86 : yes (cached)
- symlinks supported : yes (cached)

...found 196 targets...
...updating 6 targets...
common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0
common.mkdir ..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug
clang-linux.compile.c++.without-pth
..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug\hello_boost.obj
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc

Thread model: posix
InstalledDir: C:\LLVM\bin

"C:\\LLVM\\bin\\clang.exe" -cc1 -triple x86_64-pc-windows-msvc19.0.24123 -emit-obj -mrelax-all -mincremental-linker-compatible
-disable-free -main-file-name hello_boost.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info -debug-info-kind=limited
-dwarf-version=4 -debugger-tuning=gdb -coverage-notes-file
"I:\\modular-boost\\libs\\hello_boost\\example\\..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\
\debug\\hello_boost.gcno" -resource-dir "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0" -D BOOST_ALL_NO_LIB=1 -I "..\\..\\.."
-internal-isystem "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0\\include" -internal-isystem "C:\\Program Files (x86)\\Windows
Kits\\10\\Include\\10.0.10586.0\\ucrt" -O0 -Wall -fdeprecated-macro -fdebug-compilation-dir
"I:\\modular-boost\\libs\\hello_boost\\example" -ferror-limit 19 -fmessage-length 0 -fms-extensions -fms-compatibility
-fms-compatibility-version=19.0.24123 -std=c++14 -fdelayed-template-parsing -fno-inline -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -o
"..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\\debug\\hello_boost.obj" -x c++ hello_boost.cpp
clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target x86_64-pc-windows-msvc
#include "..." search starts here:
#include <...> search starts here:
..\..\..
C:\LLVM\bin\..\lib\clang\4.0.0\include
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\ucrt
End of search list.
In file included from hello_boost.cpp:13:
In file included from ..\..\..\boost/config.hpp:44:
..\..\..\boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found
# include <cstddef>
^~~~~~~~~
1 error generated.

"C:/LLVM/bin/clang.exe" -c -x c++ -O0 -g -fno-inline -Wall -g -v -m64 -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -o
"..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug\hello_boost.obj" "hello_boost.cpp"

...failed clang-linux.compile.c++.without-pth
..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug\hello_boost.obj...
...skipped <p..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug>hello_boost.exe for lack of
<p..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug>hello_boost.obj...
...skipped <p..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug>hello_boost.run for lack of
<p..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug>hello_boost.exe...
...failed updating 1 target...
...skipped 3 targets...
...updated 2 targets...

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Edward Diener via Boost
> Sent: 27 March 2017 17:25
> To: bo...@lists.boost.org
> Cc: Edward Diener
> Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
>

> On 3/27/2017 9:57 AM, Paul A. Bristow via Boost wrote:
> >
> > But I still only have VS 2015 14.0.25402.00 update 3RC - does this mean I need to update? (Sigh)
> >
> > Or use a different <compileflags>-fmsc-version=1910 ???
>
> I use -fmsc-version=1900 for VS2015. My entry using the distributed
> clang 4.0 version, which by default targets VC++, is:
>
> using clang : 4.0 : C:/Utilities/LLVM/400/x32/bin/clang++
> :
> <cxxflags>-fmacro-backtrace-limit=0
> <cxxflags>-Wno-invalid-token-paste
> <compileflags>-fmsc-version=1900
> <linkflags>-fuse-ld=lld
> ;
>
> and is invoked with "toolset=clang-4.0".

For me, this gives the same missing cstddef.

clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\LLVM\bin

"C:\\LLVM\\bin\\clang.exe" -cc1 -triple x86_64-pc-windows-msvc19.0.0 -emit-obj -mrelax-all -mincremental-linker-compatible

-disable-free -main-file-name hello_boost.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info -debug-info-kind=limited
-dwarf-version=4 -debugger-tuning=gdb -coverage-notes-file
"I:\\modular-boost\\libs\\hello_boost\\example\\..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\
\debug\\hello_boost.gcno" -resource-dir "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0" -D BOOST_ALL_NO_LIB=1 -I "..\\..\\.."
-internal-isystem "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0\\include" -internal-isystem "C:\\Program Files (x86)\\Windows
Kits\\10\\Include\\10.0.10586.0\\ucrt" -O0 -Wall -fdeprecated-macro -fdebug-compilation-dir
"I:\\modular-boost\\libs\\hello_boost\\example" -ferror-limit 19 -fmessage-length 0 -fms-extensions -fms-compatibility

-fms-compatibility-version=19.0 -std=c++14 -fdelayed-template-parsing -fno-inline -fobjc-runtime=gcc -fcxx-exceptions -fexceptions

-fdiagnostics-show-option -o
"..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\\debug\\hello_boost.obj" -x c++ hello_boost.cpp
clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target x86_64-pc-windows-msvc
#include "..." search starts here:
#include <...> search starts here:
..\..\..
C:\LLVM\bin\..\lib\clang\4.0.0\include
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\ucrt
End of search list.
In file included from hello_boost.cpp:13:
In file included from ..\..\..\boost/config.hpp:44:
..\..\..\boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found
# include <cstddef>
^~~~~~~~~
1 error generated.

There is something I am doing different/wrong here?

(Before I can even try to get into Meta-troubles ;-) )

Paul

[Peter Dimov via Boost]

Paul A. Bristow wrote:

> Now I get something as bad - back to missing the cstddef file.

I honestly have no idea why you have this problem and I do not. Clang finds
the VC include directories for me.

> PS You didn't say if I really needed the most recent March 2017 VS update?

It's true that I have VS 2017 installed and Clang finds and uses it, but
Edward reports in the other message that VS 2015 works for him (when
setting -msc-version=1900 as appropriate.)

> I've tried adding to user_config.jam
>
> <cxxflags>"-IC:/Program Files (x86)/Microsoft Visual Studio
> 14.0/VC/include"

The correct way to set the include path is with

<include>"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include"

although I'm not sure about the quoting. If that doesn't work, you could try
double-quoting:

<include>"\"C:/Program Files (x86)/Microsoft Visual Studio
14.0/VC/include\""

[degski via Boost]

On 27 March 2017 at 10:59, Paul A. Bristow via Boost <bo...@lists.boost.org>
wrote:

> <cxxflags>"-IC:/Program Files (x86)/Microsoft Visual Studio
> 14.0/VC/include"

<cxxflags> -I"C:/Program Files (x86)/Microsoft Visual Studio
14.0/VC/include"

degski

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of degski via Boost
> Sent: 27 March 2017 18:24
> To: boost
> Cc: degski
> Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
>

> On 27 March 2017 at 10:59, Paul A. Bristow via Boost <bo...@lists.boost.org>
> wrote:
>
> > <cxxflags>"-IC:/Program Files (x86)/Microsoft Visual Studio
> > 14.0/VC/include"
>
>
> <cxxflags> -I"C:/Program Files (x86)/Microsoft Visual Studio
> 14.0/VC/include"

I've tried this, and a host of other possibles.

What is *your* bjam version?

C:\Users\Paul>b2 -v
Boost.Jam Version 2015.07. OS=NT.
Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc.
Copyright 2001 David Turner.
Copyright 2001-2004 David Abrahams.
Copyright 2002-2015 Rene Rivera.
Copyright 2003-2015 Vladimir Prus.

My bjam/b2 is recent from the develop branch.

Baffling :-(

Thanks

Paul

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Peter Dimov via Boost
> Sent: 27 March 2017 18:12
> To: bo...@lists.boost.org
> Cc: Peter Dimov
> Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
>
> Paul A. Bristow wrote:

> The correct way to set the include path is with
>
> <include>"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include"

Adding that to my clang compiler options in my user-config.jam has no effect (wrong place?).

But adding that to my hello_boost jamfile produces a command line

"C:/LLVM/bin/clang.exe" -c -x c++ -O0 -g -fno-inline -Wall -g -v -fmsc-version=1900 -m64 -DBOOST_ALL_NO_LIB=1 -I"..\..\.."
-I"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include" -o

"..\..\..\bin.v2\libs\hello_boost\example\hello_boost.test\clang-linux-4.0.0\debug\hello_boost.obj" "hello_boost.cpp"

which is as I expect - apart from the clang-linux rather than clang-msvc or clang-win?

It start as I expect too

clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\LLVM\bin

"C:\\LLVM\\bin\\clang.exe" -cc1 -triple x86_64-pc-windows-msvc19.0.0 -emit-obj -mrelax-all -mincremental-linker-compatible

-disable-free -main-file-name hello_boost.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info -debug-info-kind=limited
-dwarf-version=4 -debugger-tuning=gdb -coverage-notes-file
"I:\\modular-boost\\libs\\hello_boost\\example\\..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\

\debug\\hello_boost.gcno" -resource-dir "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0" -D BOOST_ALL_NO_LIB=1 -I "..\\..\\.." -I "C:\\Program
Files (x86)\\Microsoft Visual Studio 14.0\\VC\\include" -internal-isystem "C:\\LLVM\\bin\\..\\lib\\clang\\4.0.0\\include"

-internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.10586.0\\ucrt" -O0 -Wall -fdeprecated-macro
-fdebug-compilation-dir "I:\\modular-boost\\libs\\hello_boost\\example" -ferror-limit 19 -fmessage-length 0 -fms-extensions

-fms-compatibility -fms-compatibility-version=19.0 -std=c++14 -fdelayed-template-parsing -fno-inline -fobjc-runtime=gcc

-fcxx-exceptions -fexceptions -fdiagnostics-show-option -o
"..\\..\\..\\bin.v2\\libs\\hello_boost\\example\\hello_boost.test\\clang-linux-4.0.0\\debug\\hello_boost.obj" -x c++ hello_boost.cpp
clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target x86_64-pc-windows-msvc
#include "..." search starts here:
#include <...> search starts here:
..\..\..

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include

C:\LLVM\bin\..\lib\clang\4.0.0\include
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\ucrt

but then there are warnings, and then terminates with extreme prejudice :-(

In file included from hello_boost.cpp:13:

In file included from ..\..\..\boost/config.hpp:48:
In file included from ..\..\..\boost/config/stdlib/dinkumware.hpp:98:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\typeinfo:21:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\exception:320:8: warning: private field '_Data1' is not used
[-Wunused-private-field]
void* _Data1;
^
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\exception:321:8: warning: private field '_Data2' is not used
[-Wunused-private-field]
void* _Data2;
^
Assertion failed: ~FI && "Expected valid index", file D:\src\llvm_package_4.0.0\llvm\lib\CodeGen\AsmPrinter/DwarfDebug.h, line 92
Wrote crash dump file "C:\Users\Paul\AppData\Local\Temp\clang.exe-ad54f0.dmp"
...

So, in some desperation, I changed my system variable INCLUDE to provide the necessary MSVC include files, and could then use bjam
to build the chrono and system libraries with Clang (lots of warnings, some not suppressible) , and run my timing test to compare
Lambert_w timing with GCC and MSVC (surprisingly Clang and MSVC are similar but GCC takes over twice as long).

Phew!

But thanks for all your many efforts on my behalf. I think that the changed to MPL config were critically important).

Paul

PS I think the next step is to install the VS 2017 upgrade and hope this include problem just goes away.

PPS (Changing the system INCLUDE might not be a good idea? Does anyone know how this works usually?
C:\Users\Paul\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd contains this setting

SET INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\ucrt;C:\Program Files (x86)\Windows
Kits\NETFXSDK\4.6.1\include\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\shared;C:\Program Files (x86)\Windows
Kits\10\include\10.0.10586.0\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\winrt;C:\Program Files (x86)\Windows
Kits\10\Include\10.0.10586.0\ucrt)

so how is Clang not finding/using it???

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830