Quantcast

Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

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

Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
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




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

codeblock-clang400-windows.log (48K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Peter Dimov via Boost
> Sent: 24 March 2017 18:37
> To: [hidden email]
> 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





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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
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.


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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
On 25 March 2017 at 05:17, Peter Dimov via Boost <[hidden email]>
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

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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.



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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
On 25 March 2017 at 08:39, Edward Diener via Boost <[hidden email]>
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

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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
On 3/25/2017 8:30 AM, Peter Dimov via Boost wrote:

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

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

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



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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
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.


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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
> #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.

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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
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.


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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
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 ?


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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
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.


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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
> 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.


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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.



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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
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.)


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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
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

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

Re: Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


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