[serialization][tru64cxx] assertion failed at extended_type_info.cpp
Hello, As of recently, the serialization test of Boost.MultiIndex has begun failing in Compaq C++ for Tru64, the behavior being a failed asertion at tkmap::insert(): http://tinyurl.com/kfqfs The test used to work, but has hundergone a significant change that I've got the hunch might be related to its currently failing: previously all serialization tests were performed in a single translation unit named test_serialization.cpp, while now the code has been split (for reasons irrelevant to this discussion) into two files test_serialization1.cpp and test_serialization2.cpp. Does this ring some bell? I've scanned the net for more info, the only thing I found is a reference to the same assertion at: http://lists.boost.org/boost-users/2006/02/17253.php but there's no conclusive answer in that thread, alas. Any help much appreciated, thank you in advance, Joaquín M López Muñoz Telefónica, Investigtación y Desarrollo
JOAQUIN LOPEZ MU?Z wrote: [...]
The test used to work, but has hundergone a significant change that I've got the hunch might be related to its currently failing: previously all serialization tests were performed in a single translation unit named test_serialization.cpp, while now the code has been split (for reasons irrelevant to this discussion) into two files test_serialization1.cpp and test_serialization2.cpp. Does this ring some bell?
[...] This is most probably caused by having multiple instances of some static object, which in turn is caused by a limitation of the template instantiation model used. (All automatically instantiated templates are placed in the output object and given internal linkage.) If you can identify the static object in question, adding a manual instantiation of the enclosing template will work around this, because those will be placed in an external template repository with external linkage. I had a quick look at the code but as I don't know a thing about either serialization or multi_index, I'm afraid I won't be of much help with finding the problematic code. Markus
Hello Markus Markus Schöpflin ha escrito:
JOAQUIN LOPEZ MU?Z wrote:
[...]
The test used to work, but has hundergone a significant change that I've got the hunch might be related to its currently failing: previously all serialization tests were performed in a single translation unit named test_serialization.cpp, while now the code has been split (for reasons irrelevant to this discussion) into two files test_serialization1.cpp and test_serialization2.cpp. Does this ring some bell?
[...]
This is most probably caused by having multiple instances of some static object, which in turn is caused by a limitation of the template instantiation model used. (All automatically instantiated templates are placed in the output object and given internal linkage.)
If you can identify the static object in question, adding a manual instantiation of the enclosing template will work around this, because those will be placed in an external template repository with external linkage.
That's precisely what I'd like to ask you :) Could you trap the assertion and dump the stack trace? Hopefully, that'll reveal the type of the object which is causing the problem.
I had a quick look at the code but as I don't know a thing about either serialization or multi_index, I'm afraid I won't be of much help with finding the problematic code.
As for Boost.MultiIndex, there's no static object involved neither in the lib nor the tests, AFAIK, but if you could get that stacktrace we could tell better. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
Hello Markus
Markus Schöpflin ha escrito:
JOAQUIN LOPEZ MU?Z wrote:
[...]
The test used to work, but has hundergone a significant change that I've got the hunch might be related to its currently failing: previously all serialization tests were performed in a single translation unit named test_serialization.cpp, while now the code has been split (for reasons irrelevant to this discussion) into two files test_serialization1.cpp and test_serialization2.cpp. Does this ring some bell? [...]
This is most probably caused by having multiple instances of some static object, which in turn is caused by a limitation of the template instantiation model used. (All automatically instantiated templates are placed in the output object and given internal linkage.)
If you can identify the static object in question, adding a manual instantiation of the enclosing template will work around this, because those will be placed in an external template repository with external linkage.
That's precisely what I'd like to ask you :) Could you trap the assertion and dump the stack trace? Hopefully, that'll reveal the type of the object which is causing the problem.
(ladebug) where
0 0x3ff800ed6d8 in __kill(...) in /usr/shlib/libc.so #1 0x3ff80220090 in UnknownProcedure18FromFile10(...) in /usr/shlib/libc.so #2 0x3ff80140234 in __tis_raise(...) in /usr/shlib/libc.so #3 0x3ff801d21f8 in abort(...) in /usr/shlib/libc.so #4 0x3ff801d1c60 in __assert(...) in /usr/shlib/libc.so #5 0x3ffbfdf17f0 in boost::serialization::detail::tkmap::insert(eti=0x1400503e8) "../../../libs/serialization/src/extended_type_info.cpp":74 #6 0x3ffbfdf211c in ((extended_type_info*)0x1400503e8)->boost::serialization::extended_type_info::self_register() "../../../libs/serialization/src/extended_type_info.cpp":227 #7 0x12010bf90 in ((extended_type_info_typeid_1<constboost::multi_index::detail::index_node_base<int> *)0x1400503e8)->boost::serialization::detail::extended_type_info_typeid_1<constboost::multi_index::detail::index_node_base<int> ::extended_type_info_typeid_1() "../../../boost/serialization/extended_type_info_typeid.hpp":77 #8 0x12010c99c in boost::serialization::detail::extended_type_info_typeid_1<constboost::multi_index::detail::index_node_base<int> ::get_instance() "../../../boost/serialization/extended_type_info_typeid.hpp":96 #9 0x120113664 in ((pointer_oserializer<boost::multi_index::detail::index_node_base<int>,boost::archive::text_oarchive>*)0x1400502a0)->boost::archive::detail::pointer_oserializer<boost::multi_index::detail::index_node_base<int>,boost::archive::text_oarchive>::pointer_oserializer() "../../../boost/archive/detail/oserializer.hpp":220 #10 0x120120b98 in __init_sti__test_serialization2_cpp_dadc3ca5() "../../../boost/archive/detail/oserializer.hpp":197 #11 0x120160fb8 in ../../../bin.v2/libs/multi_index/test/test_serialization.test/hp_cxx-71_006_tru64/debug/test_serialization #12 0x3ff800069b0
I had a quick look at the code but as I don't know a thing about either serialization or multi_index, I'm afraid I won't be of much help with finding the problematic code.
As for Boost.MultiIndex, there's no static object involved neither in the lib nor the tests, AFAIK, but if you could get that stacktrace we could tell better.
I had a look at extended_type_info_typeid_1::get_instance::instance and oserializer::instantiate::instance but those look correct. Hmmm... Markus
Markus Schöpflin ha escrito:
Joaquín Mª López Muñoz wrote:
Hello Markus
Markus Schöpflin ha escrito:
JOAQUIN LOPEZ MU?Z wrote:
[...]
The test used to work, but has hundergone a significant change that I've got the hunch might be related to its currently failing: previously all serialization tests were performed in a single translation unit named test_serialization.cpp, while now the code has been split (for reasons irrelevant to this discussion) into two files test_serialization1.cpp and test_serialization2.cpp. Does this ring some bell? [...]
This is most probably caused by having multiple instances of some static object, which in turn is caused by a limitation of the template instantiation model used. (All automatically instantiated templates are placed in the output object and given internal linkage.)
If you can identify the static object in question, adding a manual instantiation of the enclosing template will work around this, because those will be placed in an external template repository with external linkage.
That's precisely what I'd like to ask you :) Could you trap the assertion and dump the stack trace? Hopefully, that'll reveal the type of the object which is causing the problem.
[...]
I had a look at extended_type_info_typeid_1::get_instance::instance and oserializer::instantiate::instance but those look correct. Hmmm...
I think I know what's going on: the calls to tkmap::insert are generated fon the constructors of automatically generated extended_type_info_typeid<> instantiations. For the test program we're dealing with, the complete list of instantiation arguments of extended_type_info_typeid<> is: boost::multi_index::detail::index_node_base<int> boost::multi_index::detail::bucket_array<boost::detail::allocator::partial_std_allocator_wrapper<int> > boost::multi_index::detail::index_node_base<std::pair<int,int> > boost::multi_index::multi_index_container<...1...> boost::multi_index::safe_mode::safe_iterator<...1...> boost::multi_index::multi_index_container<...2...> boost::multi_index::safe_mode::safe_iterator<...2...> boost::multi_index::multi_index_container<...3...> boost::multi_index::safe_mode::safe_iterator<...3...> std::pair<int,int> boost::multi_index::multi_index_container<...4...> boost::multi_index::safe_mode::safe_iterator<...4...> 12 types in total. Of these, only the first one, boost::multi_index::detail::index_node_base<int>, is shared between test_serialization1.cpp and test_serialization2.cpp. This sharing, according to your reasoning about automatically instantiated templates being given internal linakge treatment, is what is causing the duplicate call to tkmap::insert making the assert trigger. The stack trace you've provided corroborates this. You said in a previous mail:
If you can identify the static object in question, adding a manual instantiation of the enclosing template will work around this, because those will be placed in an external template repository with external linkage.
The enclosing template is then, if I'm not wrong, the following: boost::serialization::extended_type_info_typeid< boost::multi_index::detail::index_node_base<int> > Could you add a manual instantiation of that to your local copy of the test and check? Also, I'm not entirely sure by you mean by "manual instantiation", but once you've done the test I hope you can refer me to your code. Thank you again for your continuous support, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
Markus Schöpflin ha escrito:
Joaquín Mª López Muñoz wrote:
Hello Markus
Markus Schöpflin ha escrito:
JOAQUIN LOPEZ MU?Z wrote:
[...]
The test used to work, but has hundergone a significant change that I've got the hunch might be related to its currently failing: previously all serialization tests were performed in a single translation unit named test_serialization.cpp, while now the code has been split (for reasons irrelevant to this discussion) into two files test_serialization1.cpp and test_serialization2.cpp. Does this ring some bell? [...]
This is most probably caused by having multiple instances of some static object, which in turn is caused by a limitation of the template instantiation model used. (All automatically instantiated templates are placed in the output object and given internal linkage.)
If you can identify the static object in question, adding a manual instantiation of the enclosing template will work around this, because those will be placed in an external template repository with external linkage. That's precisely what I'd like to ask you :) Could you trap the assertion and dump the stack trace? Hopefully, that'll reveal the type of the object which is causing the problem.
[...]
I had a look at extended_type_info_typeid_1::get_instance::instance and oserializer::instantiate::instance but those look correct. Hmmm...
I think I know what's going on: the calls to tkmap::insert are generated fon the constructors of automatically generated extended_type_info_typeid<> instantiations. For the test program we're dealing with, the complete list of instantiation arguments of extended_type_info_typeid<> is:
[...]
12 types in total. Of these, only the first one, boost::multi_index::detail::index_node_base<int>, is shared between test_serialization1.cpp and test_serialization2.cpp. This sharing, according to your reasoning about automatically instantiated templates being given internal linakge treatment, is what is causing the duplicate call to tkmap::insert making the assert trigger. The stack trace you've provided corroborates this.
You said in a previous mail:
If you can identify the static object in question, adding a manual instantiation of the enclosing template will work around this, because those will be placed in an external template repository with external linkage.
The enclosing template is then, if I'm not wrong, the following:
boost::serialization::extended_type_info_typeid< boost::multi_index::detail::index_node_base<int> >
Could you add a manual instantiation of that to your local copy of the test and check? Also, I'm not entirely sure by you mean by "manual instantiation", but once you've done the test I hope you can refer me to your code.
Seems we're on the right track, but unfortunately adding the manual instantiations to the files in question didn't help. I did some further debugging; here is what I got. Maybe you can spot something that will help. (ladebug) run [2] stopped at [void boost::serialization::detail::tkmap::insert(const class boost::serialization::extended_type_info*):71 0x3ffbfdf4980] 71 std::cerr << eti->get_key() << '\n'; (ladebug) where
0 0x3ffbfdf4980 in boost::serialization::detail::tkmap::insert(eti=0x140050110) "../../../libs/serialization/src/extended_type_info.cpp":71 #1 0x3ffbfdf53ec in ((extended_type_info*)0x140050110)->boost::serialization::extended_type_info::self_register() "../../../libs/serialization/src/extended_type_info.cpp":230 #2 0x1200d48b8 in ((extended_type_info_typeid_1<constboost::multi_index::detail::index_node_base<int> *)0x140050110)->boost::serialization::detail::extended_type_info_typeid_1<constboost::multi_index::detail::index_node_base<int> ::extended_type_info_typeid_1() "../../../boost/serialization/extended_type_info_typeid.hpp":77 #3 0x1200d4fbc in boost::serialization::detail::extended_type_info_typeid_1<constboost::multi_index::detail::index_node_base<int> ::get_instance() "../../../boost/serialization/extended_type_info_typeid.hpp":96 #4 0x1200d8884 in ((pointer_oserializer<boost::multi_index::detail::index_node_base<int>,boost::archive::text_oarchive>*)0x1400500d0)->boost::archive::detail::pointer_oserializer<boost::multi_index::detail::index_node_base<int>,boost::archive::text_oarchive>::pointer_oserializer() "../../../boost/archive/detail/oserializer.hpp":220 #5 0x1200e1058 in __init_sti__test_serialization1_cpp_dadc3ca5() "../../../boost/archive/detail/oserializer.hpp":197 #6 0x120160fa8 in ../../../bin.v2/libs/multi_index/test/test_serialization.test/hp_cxx-71_006_tru64/debug/test_serialization #7 0x3ff800069b0 #8 0x3ff800100b0 #9 0x3ff80010220 #10 0x120092adc in __start(...) in ../../../bin.v2/libs/multi_index/test/test_serialization.test/hp_cxx-71_006_tru64/debug/test_serialization
(ladebug) print *eti class boost::serialization::extended_type_info { m_type_info_key = 0x3ffbfd890a8="extended_type_info_typeid"; m_self_registered = '\000'; m_key_registered = '\000'; m_is_destructing = '\000'; m_key = 0x0; } (ladebug) cont [2] stopped at [void boost::serialization::detail::tkmap::insert(const class boost::serialization::extended_type_info*):71 0x3ffbfdf4980] 71 std::cerr << eti->get_key() << '\n'; (ladebug) where
0 0x3ffbfdf4980 in boost::serialization::detail::tkmap::insert(eti=0x1400503e8) "../../../libs/serialization/src/extended_type_info.cpp":71 #1 0x3ffbfdf53ec in ((extended_type_info*)0x1400503e8)->boost::serialization::extended_type_info::self_register() "../../../libs/serialization/src/extended_type_info.cpp":230 #2 0x12010bf90 in ((extended_type_info_typeid_1<constboost::multi_index::detail::index_node_base<int> *)0x1400503e8)->boost::serialization::detail::extended_type_info_typeid_1<constboost::multi_index::detail::index_node_base<int> ::extended_type_info_typeid_1() "../../../boost/serialization/extended_type_info_typeid.hpp":77 #3 0x12010c99c in boost::serialization::detail::extended_type_info_typeid_1<constboost::multi_index::detail::index_node_base<int> ::get_instance() "../../../boost/serialization/extended_type_info_typeid.hpp":96 #4 0x120113664 in ((pointer_oserializer<boost::multi_index::detail::index_node_base<int>,boost::archive::text_oarchive>*)0x1400502a0)->boost::archive::detail::pointer_oserializer<boost::multi_index::detail::index_node_base<int>,boost::archive::text_oarchive>::pointer_oserializer() "../../../boost/archive/detail/oserializer.hpp":220 #5 0x120120b98 in __init_sti__test_serialization2_cpp_dadc3ca5() "../../../boost/archive/detail/oserializer.hpp":197 #6 0x120160fb8 in ../../../bin.v2/libs/multi_index/test/test_serialization.test/hp_cxx-71_006_tru64/debug/test_serialization #7 0x3ff800069b0 #8 0x3ff800100b0 #9 0x3ff80010220 #10 0x120092adc in __start(...) in ../../../bin.v2/libs/multi_index/test/test_serialization.test/hp_cxx-71_006_tru64/debug/test_serialization
(ladebug) print *eti class boost::serialization::extended_type_info { m_type_info_key = 0x3ffbfd890a8="extended_type_info_typeid"; m_self_registered = '\000'; m_key_registered = '\000'; m_is_destructing = '\000'; m_key = 0x0; } Markus
Markus Schöpflin <markus.schoepflin <at> comsoft.de> writes:
Joaquín Mª López Muñoz wrote:
Markus Schöpflin ha escrito:
Joaquín Mª López Muñoz wrote:
Hello Markus
Markus Schöpflin ha escrito:
JOAQUIN LOPEZ MU?Z wrote:
[...]
The test used to work, but has hundergone a significant change that I've got the hunch might be related to its currently failing: previously all serialization tests were performed in a single translation unit named test_serialization.cpp, while now the code has been split (for reasons irrelevant to this discussion) into two files test_serialization1.cpp and test_serialization2.cpp. Does this ring some bell? [...]
This is most probably caused by having multiple instances of some static object, which in turn is caused by a limitation of the template instantiation model used. (All automatically instantiated templates are placed in the output object and given internal linkage.)
If you can identify the static object in question, adding a manual instantiation of the enclosing template will work around this, because those will be placed in an external template repository with external
That's precisely what I'd like to ask you :) Could you trap the assertion and dump the stack trace? Hopefully, that'll reveal the type of the object which is causing the problem.
[...]
I had a look at extended_type_info_typeid_1::get_instance::instance and oserializer::instantiate::instance but those look correct. Hmmm...
I think I know what's going on: the calls to tkmap::insert are generated fon the constructors of automatically generated extended_type_info_typeid<> instantiations. For the test program we're dealing with, the complete list of instantiation arguments of extended_type_info_typeid<> is:
[...]
12 types in total. Of these, only the first one, boost::multi_index::detail::index_node_base<int>, is shared between test_serialization1.cpp and test_serialization2.cpp. This sharing, according to your reasoning about automatically instantiated templates being given internal linakge treatment, is what is causing the duplicate call to tkmap::insert making the assert trigger. The stack trace you've provided corroborates this.
You said in a previous mail:
If you can identify the static object in question, adding a manual instantiation of the enclosing template will work around this, because those will be placed in an external template repository with external
linkage. linkage.
The enclosing template is then, if I'm not wrong, the following:
boost::serialization::extended_type_info_typeid< boost::multi_index::detail::index_node_base<int> >
Could you add a manual instantiation of that to your local copy of the test and check? Also, I'm not entirely sure by you mean by "manual instantiation", but once you've done the test I hope you can refer me to your code.
Seems we're on the right track, but unfortunately adding the manual instantiations to the files in question didn't help.
I did some further debugging; here is what I got. Maybe you can spot something that will help.
[...] This is more of the same: two distincts objects of the same type extended_type_info_typeid< boost::multi_index::detail::index_node_base<int> > are trying to self-register into tkmap, which is asserted. The problem can be traced down to the following member function of extended_type_info_typeid_1 (lines 94-98 of extended_type_info_typeid.hpp): static extended_type_info * get_instance(){ static extended_type_info_typeid_1<T> instance; return & instance; } Two static "instance" objects are created in each translation unit, which is obviously a bug in the compiler. I've been reading the following: http://nf.apac.edu.au/facilities/software/CXX/ugutmpl.htm and looks like the bizarre template instantiation model of Compaq C++ would allow us to: 1. leave only the declaration of get_instance() in boost/serialization/extended_type_info_typeid.hpp. 2. Move the definition of get_instance() to libs/serialization/extended_type_info_typeid.cpp Is this correct? If so, seems like the duplicate "instance" object should disappear this way. Can you give this a try?
Markus
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Hi again Markus, Joaquin M Lopez Munoz ha escrito:
Two static "instance" objects are created in each translation unit, which is obviously a bug in the compiler. I've been reading the following:
http://nf.apac.edu.au/facilities/software/CXX/ugutmpl.htm
and looks like the bizarre template instantiation model of Compaq C++ would allow us to:
[...] Now, rereading the document above, I realize that you're using the -timplicit_local template instantiation option, which "instantiate templates automatically, placing them in the output object with internal linkage", except for manually instantiated templates. My question is, why are you using such an option? Seems like the default -pt, as well as other options which guarantee external linkage, like -tused, -tall, etc. should work equally well. If you need to retain -timplicit_local for some reason, I can try to adjust the Jamfile for test_serialization so as to inhibit that option in this particular case. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
Hi again Markus,
Joaquin M Lopez Munoz ha escrito:
Two static "instance" objects are created in each translation unit, which is obviously a bug in the compiler. I've been reading the following:
http://nf.apac.edu.au/facilities/software/CXX/ugutmpl.htm
and looks like the bizarre template instantiation model of Compaq C++ would allow us to:
[...]
Now, rereading the document above, I realize that you're using the -timplicit_local template instantiation option, which "instantiate templates automatically, placing them in the output object with internal linkage", except for manually instantiated templates. My question is, why are you using such an option? Seems like the default -pt, as well as other options which guarantee external linkage, like -tused, -tall, etc. should work equally well. If you need to retain -timplicit_local for some reason, I can try to adjust the Jamfile for test_serialization so as to inhibit that option in this particular case.
Yes, I am aware that the current template instantiation model is not a good choice, but IMO it's the best of the worst. :-( Let me explain. 1. We need automatic instantiation. This rules out -nopt. 2. All instantiation models that somehow end up with placing automatically instantiated templates into the output object with external linkage are basically broken because you will get multiple defined symbols when linking. (Well, they work as advertised, but are broken for our purpose.) So this rules out -tused, -define_templates, and -tall. 3. We are now left with -pt, -tused_repository, -tall_repository, -tlocal, -timplicit_local, and -tweak. 4. The first three (basically variations of -pt) sound just like what we need. Except that compilation and link times explode. (You can use -ttimestamp to tackle the compilation time issue, but this has its own issues.) Except that storage usage explodes. Except that you have that accursed template repository to take care off. (This can be done by fiddling with boost.build and adding -ptr to the right spots, but every time I tried this, as soon as static libraries are involved, the whole thing just falls down in shambles. (You have to include the contents of the repository into the static archive which easily busts every reasonable command line length limit. And there were problems with updating the right things in the archive, IIRC.) 5. So for all practical purposes we are left with -tlocal, -timplicit_local, and -tweak. 6. -tlocal cannot be used because you end up with multiple instances of static objects. 7. -tweak sounds like The Right Thing, but one it was broken before V7.1 (and V6.5 is still mostly used), two it basically issues a warning for every(!!!) weak symbol which can only be worked around and not really fixed unless the Tru64 linker is fixed, three it forces you to used full symbol preemption, and four it is not really tested. 8. So we have -timplicit_local left, which so far has been Good Enough. Up to now I always have been able to add an explicit instantiation in the right spot to fix the issue at hand, but this seems not to work now. To make a long story short, I maybe should reconsider -pt or -tweak regardless of what I wrote above, because the test passes with both instantiation models. Markus
Markus Schöpflin ha escrito:
Joaquín Mª López Muñoz wrote:
Now, rereading the document above, I realize that you're using the -timplicit_local template instantiation option, which "instantiate templates automatically, placing them in the output object with internal linkage", except for manually instantiated templates. My question is, why are you using such an option? Seems like the default -pt, as well as other options which guarantee external linkage, like -tused, -tall, etc. should work equally well. If you need to retain -timplicit_local for some reason, I can try to adjust the Jamfile for test_serialization so as to inhibit that option in this particular case.
Yes, I am aware that the current template instantiation model is not a good choice, but IMO it's the best of the worst. :-(
Let me explain.
[very precise explanation of the different instantiation options] OK, you obvioualy know the stuff :) Thanks for the explanation.
To make a long story short, I maybe should reconsider -pt or -tweak regardless of what I wrote above, because the test passes with both instantiation models.
I think globally changing to -pt is not worth the potential hassle: after all, it's just one test that's having problems. What I can do is tweak my Jamfile (you're using v1, right?) so as to use -pt in this particular case, only. Would you be available to locally test such a Jamfile? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
Markus Schöpflin ha escrito:
Joaquín Mª López Muñoz wrote:
Now, rereading the document above, I realize that you're using the -timplicit_local template instantiation option, which "instantiate templates automatically, placing them in the output object with internal linkage", except for manually instantiated templates. My question is, why are you using such an option? Seems like the default -pt, as well as other options which guarantee external linkage, like -tused, -tall, etc. should work equally well. If you need to retain -timplicit_local for some reason, I can try to adjust the Jamfile for test_serialization so as to inhibit that option in this particular case. Yes, I am aware that the current template instantiation model is not a good choice, but IMO it's the best of the worst. :-(
Let me explain.
[very precise explanation of the different instantiation options]
OK, you obvioualy know the stuff :) Thanks for the explanation.
Sometimes I think I must be missing something really important, because basically the whole thing is pretty unusable, IMHO.
To make a long story short, I maybe should reconsider -pt or -tweak regardless of what I wrote above, because the test passes with both instantiation models.
I think globally changing to -pt is not worth the potential hassle: after all, it's just one test that's having problems. What I can do is tweak my Jamfile (you're using v1, right?) so as to use -pt in this particular case, only. Would you be available to locally test such a Jamfile?
I'm using both V1 and V2, but the release will be done with V2 I believe. But I'm not sure if changing the instantiation model for just one test is a good choice. Let me try the global switch to -pt first, maybe it will look better this time... Markus
Markus Schöpflin wrote:
Joaquín Mª López Muñoz wrote:
[...]
I think globally changing to -pt is not worth the potential hassle: after all, it's just one test that's having problems. What I can do is tweak my Jamfile (you're using v1, right?) so as to use -pt in this particular case, only. Would you be available to locally test such a Jamfile?
I'm using both V1 and V2, but the release will be done with V2 I believe.
But I'm not sure if changing the instantiation model for just one test is a good choice. Let me try the global switch to -pt first, maybe it will look better this time...
Joaquín, currently I think the most viable solution is to mark the failure as expected. I'm still in the progress of evaluating a switch to -pt, but this will take more time. Maybe you can put an explanation into the markup, something like: "This test fails because of limitations in the template instantiation model of the compiler used (-timplicit_local), which causes two static objects of the type extended_type_info_typeid<boost::multi_index::detail::index_node_base<int>
to be created. It could be made to pass by using another template instantiation model, but this is currently not feasible."
Feel free to reword it to suit your taste... :-) Markus
Markus Schöpflin ha escrito:
Joaquín,
currently I think the most viable solution is to mark the failure as expected. I'm still in the progress of evaluating a switch to -pt, but this will take more time.
Maybe you can put an explanation into the markup, something like: "This test fails because of limitations in the template instantiation model of the compiler used (-timplicit_local), which causes two static objects of the type extended_type_info_typeid<boost::multi_index::detail::index_node_base<int>
to be created. It could be made to pass by using another template instantiation model, but this is currently not feasible."
Feel free to reword it to suit your taste... :-)
I've followed your advice and added an entry to the markup --tweaking the Jamfile is probably beyond my bjam skills and, well, the markup note really gives the user info about the problem rather than ducking it. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (4)
-
JOAQUIN LOPEZ MU?Z -
Joaquin M Lopez Munoz
-
Joaquín Mª López Muñoz
-
Markus Schöpflin