November 2015 - Boost - lists.preview.boost.org

Interest in an LLVM library?
by Andy Jost 26 Nov '15

26 Nov '15

Is there interest in an LLVM library? My motivation is to simplify the dynamic creation of functions, modules, and programs by defining an EDSL modeled after the C language. LLVM provides an API based exclusively on function calls that is verbose and difficult to use. The EDSL is more expressive and easier to use. (This may remind some people of Boost.Python and indeed these libraries are similar in motivation.) The scope of this proposal is limited. The proposed library does not compile, link, optimize, save, or load anything, for example, since the LLVM API is suitable for that. Also, it may not support obscure features, even if they seem to be within its purview, since one can always make direct calls to the LLVM API. I have written about 6500 lines of prototype code in the context of another project (a compiler for the language Curry, if anyone is interested). It is not a complete solution, but is by no means trivial, either. I'll discuss that next, but since the discussion is somewhat lengthy, let me first explain what I'm looking for by sending this. I think this EDSL would make a good Boost library. If others agree, then the next step is to review the design. I need second opinions and help from more knowledgeable people to improve the design. There are a few places in particular where I think a redesign is necessary. After that, I'm happy to implement the final library (and would gladly accept help, if anyone is interested). Now, I'll show a few examples and provide links to the prototype code. First, here's how to create a module and put it in scope: module const example_module("example"); scope _ = example_module; The scope object sets the insertion point for types, functions, and global variables. We can create a type as follows: type i32 = int_(32); i32 is a 32-bit integer. It is easy to build more complex types, e.g., i32[2] is an array type, *i32 is a pointer type, and i32(i32,i32) is a function type. An expression like i32(42) produces a constexpr. As you might guess at this point, the prototype makes heavy use of SFINAE. I've gone to a lot of effort to make this work with everything I can think of, particularly multi-dimensional arrays and initializer_lists. So, an expression like (i32[3][2])({{1,2,3},{4,5,6}}) works! (Note: i32[3][2] is the C++ type int32_t[2][3] because that's the only sensible way to interpret successive calls to operator[]). We can create a struct from a sequence of types like this: type foo = struct_("foo", {i32, *i32}); Or, we can leave out the sequence to get an opaque struct. A function prototype can be created as follows: function const f = extern_(i32(i32), "f", {"i"}); This function, f, takes an i32 (named "i") and returns an i32. The function is placed in example_module, since the code appears in its scope. There are two other linkage-specifying functions: static_ and inline_. extern_ and static_ are also used to create global variables (i.e., if the type is not a function). To define the body, we create another scope: { scope _ = f; // code for f. } To understand this, we have to discuss scopes in more depth. There are three nested levels of scope: the current module, the current function, and the current basic block. The code above sets the current function to f and the current basic block to f's entry point. Generally speaking, within a function body we write statements that generate instructions. Those instructions are inserted into the current function at the end of the current basic block. To define the body, we can declare values and operate on them. For example: value i = arg("i"); Here, "arg" is a special function that fetches the named function parameter. We can add instructions to f using operators or special methods. For example: value j = i + 1; return_(j); Branches manipulate the current basic block. Here's an if statement: label true_path, false_path; if_(i, true_path, false_path); { scope _ = true_path; // code for true. } /* else */ { scope _ = false_path; // code for false. } // new basic block here. This generates instructions to test i, take the appropriate branch, and then continue to a new basic block in the right places (which depends on whether the paths terminate with a branch instruction). It also updates the scope so that statements following if_() are inserted into the new basic block. Believe me when I say it is not trivial to do this with the LLVM API. Although it is sometimes necessary to pre-declare labels as shown above, we can usually employ C++11 lambdas to simplify the encoding: if_(i , []{ /* code for true */} , []{ /* code for false */ } ); The prototype code can be found under https://github.com/andyjost/Sprite-3/tree/master/include/sprite/backend. Also, there are many examples under https://github.com/andyjost/Sprite-3/tree/master/examples. Other parts of the Sprite-3 project are unrelated to this proposal. A good example to start with generates the Fibonacci numbers (https://github.com/andyjost/Sprite-3/blob/master/examples/fib.cpp) Here's the interesting part: // Create a new module and associate it with this lexical scope. module const fib_module("fib"); scope _ = fib_module; // Declare types. auto const char_ = types::char_(); auto const i32 = types::int_(32); auto const i64 = types::int_(64); // Declare external functions. auto const printf = extern_(i32(*char_, dots), "printf"); // Define the @fib function. auto const fib = extern_(i64(i64), "fib", {"n"}); { scope _ = fib; value n = arg("n"); if_(n <(signed_) (2), []{return_(1);}); return_(fib(n-2) + fib(n-1)); } // Define the @main function. auto const main = extern_(i32(), "main"); { scope _ = main; value const x = fib(5); printf("fib(5)=%d\n", x); return_(0); } After this code runs, fib_module contains an intermediate representation of the program. The LLVM API can be used to save that to disk, compile it to assembly, link in the C library (to get printf), or JIT compile any of the functions, among other things. Thanks to everyone who made it this far :) I'm looking forward to your feedback. -Andy

9 21

[trippels-ppc64le][math] Missing quadmath.h errors
by Andrey Semashev 24 Nov '15

24 Nov '15

Hi, I'm seeing some test failures on the trippels-powerpc64le-gcc-6.0 tester that amount to Boost.Math failing to build because the quadmath.h header is missing. http://www.boost.org/development/tests/develop/developer/output/trippels-po… I understand that gcc 6.0 is an unreleased compiler, but the error is probably not a consequence of a compiler bug. Besides, another tester, Flast-FreeBSD10-gcc-6.0.0~gnu++11, passes. Is it possible that the header is not provided for powerpc64le? Or is an optional dependency whose presence is misdetected? Is this a known problem?

3 5

[teeks99][test] Test failures on MSVC 8-11
by Andrey Semashev 23 Nov '15

23 Nov '15

Hi, I'm seeing massive Boost.Log test failures on teeks99 with MSVC versions 8 through 11. The links to the failure messages lead to Boost.Test but the console output is not helpful (shows a successful compilation of a source file [1]). I can see Boost.Test tests are also failing massively on these compilers. Could this be fixed? [1]: http://www.boost.org/development/tests/develop/developer/output/ teeks99-08d-win2012R2-64on64-boost-bin-v2-libs-log-test-attr_attribute_set- test-msvc-11-0-dbg-adrs-mdl-64-thrd-mlt.html

6 18

[Config] boost::uint32_t != std::uint32_t on some targets
by Louis Dionne 23 Nov '15

23 Nov '15

Dear Boost, I recently fell into a trap where a program wouldn't compile because of a difference between `boost::uint32_t` and `std::uint32_t`. Specifically, I was trying to cross-compile from OS X to ARM, and the following program wouldn't compile #include <boost/cstdint.hpp> #include <cstdint> #include <type_traits> static_assert(std::is_same<std::uint32_t, boost::uint32_t>::value, ""); int main() { } I was building with arm-none-eabi-g++ -I /path/to/boost -std=c++11 -c main.cpp I have asked a question on StackOverflow [1], and I now understand why the two types are not required to be the same. However, I think it is a QOI issue that those two types are not the same, since it makes interoperating between `std::uint32_t` and `boost::uin32_t` more difficult. Is there a reason for this difference, and if not would it be reasonable to ensure that `boost::uint32_t == std::uint32_t` whenever the latter is defined, i.e. in C++11 and above? Regards, Louis [1]: http://stackoverflow.com/q/33857554/627587

3 2

build and install boost subset does not install the header files
by George Georgiev 22 Nov '15

22 Nov '15

Hi, I am trying to use github boost to obtain a subset of the libraries. I found that using the following subset of modules allows me to build boost_system. git submodule update --init tools/build || exit 1 git submodule update --init tools/inspect || exit 1 git submodule update --init libs/assert || exit 1 git submodule update --init libs/config || exit 1 git submodule update --init libs/core || exit 1 git submodule update --init libs/predef || exit 1 git submodule update --init libs/system || exit 1 git submodule update --init libs/utility || exit 1 The problem is that ./b2 ... install does not copy the header files. Is this a bug that I am hitting? My commands are: ./bootstrap.sh --prefix=../../boost --includedir=../../boost/include || exit 1 PATH=$CLANGBIN:$PATH \ ./b2 \ toolset=clang \ cxxflags="-std=c++11 -stdlib=libc++ -isystem/Developer/SDKs/MacOSX10.7.sdk/usr/include" \ linkflags="-stdlib=libc++" \ install threading=multi link=static Thanks, -g

2 3

[type_traits] Is_nothrow_move_constructible fails on mngw
by Andrzej Krzemienski 21 Nov '15

21 Nov '15

Hi, It looks like is_nothrow_move_constructible (in branch develop, on testers igaztanaga-gcc-4.6c++11 and igaztanaga-gcc-4.7c++11) fails the compilation rather than returning a true-false answer. <http://www.boost.org/development/tests/develop/igaztanaga-gcc-4-7c++11.html>I filed a ticket for it: https://svn.boost.org/trac/boost/ticket/11811 Reards, &rzej

1 0

[thread] Boost threading on VMware ESXi
by Fu ji 20 Nov '15

20 Nov '15

Hello, Is there anyone who try to use boost threading on ESXi (posix like system from VMware) or try to port it? Best regards, Damian

1 0

Re: [boost] boost log memory leak? Maybe it is my wrong.
by Jefferyliangmh 16 Nov '15

16 Nov '15

Many thanks andrey.semashev's reply. I send my demo application codes in BoostDemo.rar file. "logger" is my wrapped module by win32 dll. "BoostDemo" is my MFC test application, call logger code written in CMainFrame::CMainFrame() fuction, like this : AppLogger::log("this is test message"). Memory leak display in output windows when compiled BoostDemo application. 2015-11-16 2015-11-16 Jefferyliangmh 发件人：boost-request(a)lists.boost.org 发送时间：2015-11-16 01:00 主题：Boost Digest, Vol 4908, Issue 1 收件人："boost"<boost(a)lists.boost.org> 抄送： Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. boost log memory leak? Maybe it is my wrong. (=?UTF-8?B?5qKB5piO6L6J?=) 2. Re: boost log memory leak? Maybe it is my wrong. (Andrey Semashev) 3. Re: checking __INTEL_COMPILER == 9999 (Blower, Melanie) 4. Re: checking __INTEL_COMPILER == 9999 (Edward Diener) ---------------------------------------------------------------------- Message: 1 Date: Sat, 14 Nov 2015 19:31:28 +0800 From: "=?UTF-8?B?5qKB5piO6L6J?="<liang_mh(a)163.com> To: "boost"<boost(a)lists.boost.org> Subject: [boost] boost log memory leak? Maybe it is my wrong. Message-ID: <220730f2.126658.15105c3ab0c.Coremail.liang_mh(a)163.com> Content-Type: text/plain; charset="UTF-8" Way I want to use win32 dynamic link library encapsulates the boost.log, the wrapper DLL in MFC MSVC 2015 calls, memory leak in output window prompt; The same library in a console program calls, no such problems. I am very depressed. Who can help me? 2015-11-14 ??? ------------------------------ Message: 2 Date: Sun, 15 Nov 2015 00:05:28 +0300 From: Andrey Semashev <andrey.semashev(a)gmail.com> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Subject: Re: [boost] boost log memory leak? Maybe it is my wrong. Message-ID: <CAEhD+6BH=Lnw1ghLwOVarXbYGDBqoNygzcWnML+TtU7mVbB1zQ(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Sat, Nov 14, 2015 at 2:31 PM, ??? <liang_mh(a)163.com> wrote: > Way I want to use win32 dynamic link library encapsulates the boost.log, the wrapper DLL in MFC MSVC 2015 calls, memory leak in output window prompt; The same library in a console program calls, no such problems. > I am very depressed. Who can help me? If you work with Boost.Log the same way in both cases then it's likely a problem in your code and not the library. Otherwise I can't help without a minimal working code sample. ------------------------------ Message: 3 Date: Sun, 15 Nov 2015 13:05:27 +0000 From: "Blower, Melanie" <melanie.blower(a)intel.com> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Subject: Re: [boost] checking __INTEL_COMPILER == 9999 Message-ID: <B3584E72CFEBED439A3ECA9BCE67A4EF40258FCC(a)fmsmsx116.amr.corp.intel.com> Content-Type: text/plain; charset="us-ascii" Thanks for all your suggestions and replies, I will work it on the Intel side. To Edward, at the bottom of my first message there's info about one of the failure modes. --Melanie ------------------------------ Message: 4 Date: Sun, 15 Nov 2015 10:43:25 -0500 From: Edward Diener <eldiener(a)tropicsoft.com> To: boost(a)lists.boost.org Subject: Re: [boost] checking __INTEL_COMPILER == 9999 Message-ID: <n2a971$msb$1(a)ger.gmane.org> Content-Type: text/plain; charset=windows-1252; format=flowed On 11/15/2015 8:05 AM, Blower, Melanie wrote: > Thanks for all your suggestions and replies, I will work it on the Intel side. To Edward, at the bottom of my first message there's info about one of the failure modes. Thanks, I see that now. ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 4908, Issue 1 **************************************

1 0

checking __INTEL_COMPILER == 9999
by Blower, Melanie 15 Nov '15

15 Nov '15

A few years ago, circa 2010, the Intel 12.x compiler was released without having a correct value for the macro __INTEL_COMPILER. It was released using the development-only version number 9999 instead of the correct value 12xx. Later on, an Intel 12.x compiler was updated to remove this problem and the version number made correct. Meanwhile, since boost needed to add some workarounds, there was code added in a couple of boost files to check for version 9999. The check for 9999 in boost causes trouble in our current development compiler in-house testing. Is it possible to have this version checking removed from the boost sources? There's no advantage to boost users, and possibly a disadvantage if someone is still using a not-updated 12.x compiler. But hopefully that is unlikely, we're currently shipping our 16.x compiler. Here's the diff, diff --git a/include/boost/config/compiler/intel.hpp b/include/boost/config/compiler/intel.hpp index 7789b94..bbbf876 100644 --- a/include/boost/config/compiler/intel.hpp +++ b/include/boost/config/compiler/intel.hpp @@ -47,11 +47,7 @@ #undef BOOST_COMPILER #if defined(__INTEL_COMPILER) -#if __INTEL_COMPILER == 9999 -# define BOOST_INTEL_CXX_VERSION 1200 // Intel bug in 12.1. -#else # define BOOST_INTEL_CXX_VERSION __INTEL_COMPILER -#endif #elif defined(__ICL) # define BOOST_INTEL_CXX_VERSION __ICL #elif defined(__ICC) @@ -93,11 +89,7 @@ #include "boost/config/compiler/common_edg.hpp" #if defined(__INTEL_COMPILER) -#if __INTEL_COMPILER == 9999 -# define BOOST_INTEL_CXX_VERSION 1200 // Intel bug in 12.1. -#else # define BOOST_INTEL_CXX_VERSION __INTEL_COMPILER -#endif #elif defined(__ICL) # define BOOST_INTEL_CXX_VERSION __ICL #elif defined(__ICC) @@ -289,7 +281,7 @@ template<> struct assert_intrinsic_wchar_t<unsigned short> {}; // (Niels Dekker, LKEB, May 2010) // Apparently Intel 12.1 (compiler version number 9999 !!) has the same issue (compiler regression). #if defined(__INTEL_COMPILER) -# if (__INTEL_COMPILER <= 1110) || (__INTEL_COMPILER == 9999) || (defined(_WIN32) && (__INTEL_COMPILER < 1600)) +# if (__INTEL_COMPILER <= 1110) || (__INTEL_COMPILER == 1210) || (defined(_WIN32) && (__INTEL_COMPILER < 1600)) # define BOOST_NO_COMPLETE_VALUE_INITIALIZATION # endif #endif Here's the other checking for 9999 that I found. Not known to cause a problem. diff --git a/include/boost/regex/v4/regex_format.hpp b/include/boost/regex/v4/regex_format.hpp index e9006a7..bf2e552 100644 --- a/include/boost/regex/v4/regex_format.hpp +++ b/include/boost/regex/v4/regex_format.hpp @@ -180,7 +180,7 @@ private: } inline int toi(ForwardIter& i, ForwardIter j, int base) { -#if defined(_MSC_VER) && defined(__INTEL_COMPILER) && ((__INTEL_COMPILER == 9999) || (__INTEL_COMPILER == 1210)) +#if defined(_MSC_VER) && defined(__INTEL_COMPILER) && (__INTEL_COMPILER == 1210) // Workaround for Intel support issue #656654. // See also https://svn.boost.org/trac/boost/ticket/6359 return toi(i, j, base, mpl::false_()); The intel.hpp check for 9999 causes this problem, among others, float128 tests from (boost_multiprecision suite) fail due to workaround in intel.hpp fo 12.1 compiler that was released with __INTEL_COMPILER == 9999 Fails like this: $ "icpc" -c -xc++ -O0 -w1 -inline-level=0 -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DSLOW_COMPILER -DTEST_FLOAT128 -I"../../.." -I"../include" -c -o "../../../bin.v2/libs/multiprecision/test/test_tanh_float128.test/intl-lnx/dbg/dbg-symbl-\ off/test_tanh.o" "test_tanh.cpp" In file included from test_tanh.cpp(53): ../../../boost/multiprecision/float128.hpp(48): error: identifier "_Quad" is undefined typedef _Quad float128_type; ^ Thanks and regards, Melanie Blower

5 6

boost log memory leak? Maybe it is my wrong.
by 梁明辉 14 Nov '15

14 Nov '15

Way I want to use win32 dynamic link library encapsulates the boost.log, the wrapper DLL in MFC MSVC 2015 calls, memory leak in output window prompt; The same library in a console program calls, no such problems. I am very depressed. Who can help me? 2015-11-14 梁明辉

2 1