May 2014 - Boost - lists.boost.org

[context] Using Boost.Context on the BlueGene/Q
by Thomas Heller 16 May '14

16 May '14

Hi list, I was very happy to see that Boost.Context has been fixed for PPC64. Thanks a lot for that. I was able to verify that the fix worked on the BlueGene/Q. Both on the Head node, which is a POWER7 and the compute nodes which are a PowerPC A2. However, in order to build the library, I needed to manually call the assembler as the predefined commands did not work. For example, the BG/Q provided assembler doesn't know the "--64" switch and the assembler i want to use is called bgclang-as instead of plain as. For the compute nodes, I additionally want to use the -ma2 flag to have the proper assembly generated. Is there a way to have that configurable by the user? Right now, the only way i could find to fix that is to manually edit the Jamfile.v2 in the context build directory. Any advice or hints to fix it properly are highly appreciated. Thanks, Thomas -- Thomas Heller Friedrich-Alexander-Universität Erlangen-Nürnberg Department Informatik - Lehrstuhl Rechnerarchitektur Martensstr. 3 91058 Erlangen Tel.: 09131/85-27018 Fax: 09131/85-27912 Email: thomas.heller(a)cs.fau.de

2 2

Re: [boost] Community Maintenance Team and neglected libraries
by Edward Diener 16 May '14

16 May '14

On 4/22/2014 12:29 PM, Ben Pope wrote: > In case you haven't heard of the CMT: > https://svn.boost.org/trac/boost/wiki/CommunityMaintenance > > I'm also interested in getting the test results less yellow and more > green, I don't have a lot of time, I'm sure I'm not alone. > > There are quite a few places where the library code is probably fine, > but the failure is in the test itself, the fix is often simple and > uncontroversial. > > Without picking on any particular library or author, here are some > examples: > > * Link the tests with boost::system > http://thread.gmane.org/gmane.comp.lib.boost.maint/92 > * Merge existing fixes in develop to master > http://thread.gmane.org/gmane.comp.lib.boost.devel/250129 > * Fight with casts > http://thread.gmane.org/gmane.comp.lib.boost.devel/250143 > * Disambiguate a type > https://svn.boost.org/trac/boost/ticket/9540 These refer to system, MPI, utility, and assign. None of these are in the list of libraries which the community maintenance team has write acces to apply fixes. Hopefully the developers who do have write access to these libraries will look at the issues involved.

5 7

Re: [boost] Community Maintenance Team and neglected libraries
by Daniela Engert 15 May '14

15 May '14

Am 22.04.2014 18:29 schrieb Ben Pope: > There are quite a few places where the library code is probably fine, > but the failure is in the test itself, the fix is often simple and > uncontroversial. > ... > The responses have been frustrating to say the least, we really need a > way to move forward on this. > You're so true with your observation. I'm a bit disappointed too. I'm sitting on a pile of simple patches to cleanup the existing tests such that I don't have to wade through a morass of level-4 msvc compiler warnings when running the test suite. This requires both fixes to some of the libraries themselves (thereby finding real bugs on the way) and fixes to the test code to get the tests compiled in the first place. It's those sanitized libraries that I supply to my colleagues for production code because it's our policy to be absolutely clean on level-4 warnings. Some months ago, I've prepared some of those patches (more yet to come) for inclusion into boost mainline, and some of them were picked up. The rest of my pull requests seems to be neglected. I prefer to refrain from spamming the mailing lists with reminders, but is there a better way to get the message through? Dealing with quality-of-implementation issues and acting like a janitor might not be the most sexy job in the universe, but I'm happy to do it (rather than just sitting on the fence) as long as it has an effect, eventually. Ciao Dani

3 2

[GitHub] List open pull requests for all libraries? [resend]
by Beman Dawes 15 May '14

15 May '14

We need to be able to monitor the open pull requests for all Boost libraries, not just a individual library. I'm not seeing any canned way of doing that via the GitHub web site. Am I missing something? It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this? Thanks, --Beman

8 14

[test] Regression tests and boost.test merge questions
by Antony Polukhin 15 May '14

15 May '14

Hi, I'm just curious about the situation with Boost.Test. When will be the latest changes merged to master? Regression tests for master branch use develop or master version of Boost.Test? This is vital for me because TypeIndex library must be tested with RTTI off, but master version of Test fail to compile in that way. Compilation of Boost.Test in RTTI-off mode was fixed in develop branch. -- Best regards, Antony Polukhin

1 0

required toolsets
by Steven Watanabe 15 May '14

15 May '14

AMDG The list of required toolsets in explicit-failures-markup.xml is out-dated. Therefore, if no one objects, I propose setting it to the following: msvc-10.0, msvc-11.0, gcc-4.6, gcc-4.7, clang-darwin-11, clang-darwin-4.2.1, clang-linux-3.1, clang-linux-3.2, gcc-mingw-4.7, gcc-mingw-4.6 (two releases of each major compiler that appears in both the trunk and release regression tests) The sole effect of this is to determine which toolsets appear in the issues list: http://www.boost.org/development/tests/trunk/developer/issues.html In Christ, Steven Watanabe

10 32

[atomic] Support for specialized instructions
by Andrey Semashev 14 May '14

14 May '14

Hi, I've been contemplating the idea of adding support for some specialized atomic instructions to Boost.Atomic. Since I'm only familiar with x86 architecture, my current candidates are: * Increment/decrement with a check for zero result (lock inc/dec). The decrement is the most essential of the two because it would be useful for reference counters of various kinds. The increment is mostly beneficial in terms of code size, and it probably doesn't need the check for zero in most cases. * In-place logical operations (lock and/or/xor). These are useful in cases when the code needs to operate on flags or bit sets but doesn't need the result of the operation. Optional variants can be provided with a test for zero result. * Bit set/reset operations (lock bts/btr). The use cases are similar to the logical operations but the advantage is that the previous value of the altered bit can be returned. BTW, these operations are needed in Boost.Sync to implement mutexes on Windows. All these operations can be implemented through the standard atomic<> interface, and that's what would be done on platforms without support for the specialized instructions. For now the idea is to add special member functions to atomic<>, when used with arithmetic types. I was thinking about providing free functions as well, although I think that the complete set of the standard atomic functions would be required for that. Comments? Opinions?

4 6

[atomic] Major rewrite landed in develop
by Andrey Semashev 14 May '14

14 May '14

Hi, I've merged a major rewrite of Boost.Atomic into develop. The changes are quite massive to describe in a few words, but the most significant ones are: - The interface of atomic<> template and atomic_flag are now completely decoupled from the atomic operations implementation (the backends). It is now more consistent across all platforms and not duplicated everywhere. - atomic_flag and fences are now available through separate headers atomic_flag.hpp and fences.hpp. These headers are still included by atomic.hpp for backward compatibility. - The definition of configuration macros BOOST_ATOMIC_XXX_LOCK_FREE is now available through a separate header capabilities.hpp. Users are able to include it and test these macros before including the rest of Boost.Atomic. Most macros are now defined more correctly based on the sizes of the types (i.e. BOOST_ATOMIC_LONG_LOCK_FREE now actually depends on the size of long and is equivalent to BOOST_ATOMIC_INT32_LOCK_FREE or BOOST_ATOMIC_INT64_LOCK_FREE). - Added support for 128-bit atomic ops with MSVC. The support is always enabled for x86_64. There are some ancient AMD chips that don't support cmpxchg16b, users can define BOOST_ATOMIC_NO_CMPXCHG16B if they want to target those. - Added support for BOOST_ATOMIC_FLAG_INIT, although it is optional and atomic_flag is still zero initialized by default. I did not find a way to implement it and keep compatibility with C++03. - Improved ARM backend with gcc (tested for compilation). Now it supports 64- bit atomics. All operations are written in ll/sc manner instead of a CAS loop. - Added a separate ARM backend for MSVC (tested for compilation). Some support for ARM was added to develop earlier but the new implementation is better optimized (it uses appropriate intinsics wrt memory ordering). - Added support for 64-bit atomic ops for SPARCv9 with gcc (completely untested). - Added support for DEC Alpha backend with gcc (completely untested). It is based on the dead and incomplete code that was present in Boost.Atomic before. - Removed support for IA64 on Windows. Not sure if it is needed, but it can be added relatively easily. There are many more changes. Lots of code duplication removed, bugs with arithmetic overflow fixed and things I don't remember. This new version is the foundation for further improvements that are needed for Boost.Sync. In particular, I plan to add new operations (btr/bts, inplace logical operations) and maybe free atomic functions. You can see in the above list that much of the code is not properly tested, and I have little-to-none experience with some of the platforms. To my knowledge, there are no non-x86 regular testers. Therefore I'd appreciate if people reviewed and tried the code. Please, report any feedback, good or bad. Thank you.

1 0

[graph] Fix for directed_graph::swap
by Ben Pope 14 May '14

14 May '14

https://github.com/boostorg/graph/pull/5 Ben

1 1

compressed_pair breaks with multiple instances of empty types
by Hite, Christopher 14 May '14

14 May '14

I've been abusing compressed_pair to build a compressed_tuple. I'm pretty sure this bug can be fixed using intermediate types on the hierarchy. struct Empty1{}; struct Empty2{}; int i=sizeof( boost::compressed_pair<Empty1, boost::compressed_pair<Empty1, Empty2> >); //boom int j=sizeof( boost::compressed_pair<Empty1, Empty2>); //ok int k=sizeof( boost::compressed_pair<Empty1, Empty1>); //ok int h=sizeof( boost::compressed_pair<std::string, boost::compressed_pair<std::string, Empty2> >); //ok cc1plus: warnings being treated as errors In file included from ..../boost/boost_1_50_0/include/boost/compressed_pair.hpp:21, from /home/w461845/src/edgamm/src/lib/libLogger/include/libLogger/LogChain.hpp:4, from OLogTest.cpp:1: ..../boost/boost_1_50_0/include/boost/detail/compressed_pair.hpp: In instantiation of "boost::details::compressed_pair_imp<Empty1, boost::compressed_pair<Empty1, Empty2>, 3>": ..../boost/boost_1_50_0/include/boost/detail/compressed_pair.hpp:348: instantiated from "boost::compressed_pair<Empty1, boost::compressed_pair<Empty1, Empty2> >" OLogTest.cpp:112: instantiated from here ..../boost/boost_1_50_0/include/boost/detail/compressed_pair.hpp:73: error: direct base "Empty1" inaccessible in "boost::details::compressed_pair_imp<Empty1, boost::compressed_pair<Empty1, Empty2>, 3>" due to ambiguity g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) Chris Hite This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

1 0