[fusion][IBM xlc] TR1 tests and others failing.
Joel, Fusion's tuple tests are passing with IBM xlc, but the TR1 tuple tests are failing with problems with std::pair, which in turn causes all the Boost.Math tests to fail: it appears that just including the header ../boost/fusion/adapted/std_pair.hpp is enough to trigger the issue :-( See http://tinyurl.com/3cfz2n for a typical error message. Is this fixable, or should I degrade TR1 to the old tuples implementation for this compiler? BTW the old spirit-fusion code did work with xlc I believe. Chris: the code that's failing looks so innocuous it's hard to see how it could fail: there's nothing odd in xlc's headers like an extra defaulted template argument for std::pair is there? Thanks, John Maddock.
John Maddock wrote:
Joel,
Fusion's tuple tests are passing with IBM xlc, but the TR1 tuple tests are failing with problems with std::pair, which in turn causes all the Boost.Math tests to fail: it appears that just including the header ../boost/fusion/adapted/std_pair.hpp is enough to trigger the issue :-(
See http://tinyurl.com/3cfz2n for a typical error message.
Is this fixable, or should I degrade TR1 to the old tuples implementation for this compiler? BTW the old spirit-fusion code did work with xlc I believe.
Chris: the code that's failing looks so innocuous it's hard to see how it could fail: there's nothing odd in xlc's headers like an extra defaulted template argument for std::pair is there?
Just a quick question: did this happen with the recent header changes this week? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"John Maddock" <john@johnmaddock.co.uk> wrote on 10/26/2007 03:28:05 AM:
Joel,
Fusion's tuple tests are passing with IBM xlc, but the TR1 tuple tests are failing with problems with std::pair, which in turn causes all the Boost.Math tests to fail: it appears that just including the header ../boost/fusion/adapted/std_pair.hpp is enough to trigger the issue :-(
See http://tinyurl.com/3cfz2n for a typical error message.
Is this fixable, or should I degrade TR1 to the old tuples implementation
for this compiler? BTW the old spirit-fusion code did work with xlc I believe.
Chris: the code that's failing looks so innocuous it's hard to see how it
could fail: there's nothing odd in xlc's headers like an extra defaulted template argument for std::pair is there?
Thanks, John Maddock.
I believe I have a fix for this in the compiler. I ran a large batch of tests last night but have not checked the results, however the smoke tests I did run seemed ok. This compiler change will likely take some time to make it into a production driver (on the order of a month or two if I can sneak it in). The problem with boost::fusion:traits::tag_of<>, and make_vector<> is that we are not considering default arguments for partial specializations. The code sequence is a forward declaration using default arguments followed by a partial specialization definition. Our compiler explicitly disallowed the checking of default arguments for partial specilizations. Most likely this was just an oversight on our part, but I will need to clarify with the standard. Here is a small test-case that causes the error message as well show the problem: //Begin t.C template <typename T0 = void, typename T1 = void> struct make_vector; template <typename T0> struct make_vector<T0> { }; //End t.C The workaround in the Boost source code would be to specify the default argument explicitly. I tried the following change for boost/fusion/adapter/std_pair.hpp and the error message disappeared. --- boost/fusion/adapted/std_pair.hpp.orig 2007-10-26 11:31:11.276781194 -0400 +++ boost/fusion/adapted/std_pair.hpp 2007-10-26 11:31:32.676781424 -0400 @@ -20,7 +20,7 @@ namespace traits { template <typename T1, typename T2> - struct tag_of<std::pair<T1, T2> > + struct tag_of<std::pair<T1, T2>, void > { typedef struct_tag type; } Not an ideal fix, but illustrates where the change for our compiler is necessary in the Boost source. The changes would need to be made in fusion/adapter/std_pair.hpp, fusion/sequence/generation/make_vector.hpp, fusion/sequence/generation/make_list.hpp to name a few :-( So there is a source work around as well as a compiler fix. Like I mentioned earlier it will be some time before the compiler change is reflected into a production compiler. One of our internal requirements that we have for publishing results is that the compiler used to publish results has to be available to customers therefore I cannot use a pre-release compiler for nightly Boost runs. How would you like to proceed? Chris Cambly XL C++ Compiler Development
Christopher Cambly wrote:
The problem with boost::fusion:traits::tag_of<>, and make_vector<> is that we are not considering default arguments for partial specializations. The code sequence is a forward declaration using default arguments followed by a partial specialization definition.
Our compiler explicitly disallowed the checking of default arguments for partial specilizations. Most likely this was just an oversight on our part, but I will need to clarify with the standard.
Here is a small test-case that causes the error message as well show the problem:
//Begin t.C template <typename T0 = void, typename T1 = void> struct make_vector; template <typename T0> struct make_vector<T0> { }; //End t.C
Does it only happen if make_vector is forward declared?
The workaround in the Boost source code would be to specify the default argument explicitly. I tried the following change for boost/fusion/adapter/std_pair.hpp and the error message disappeared.
--- boost/fusion/adapted/std_pair.hpp.orig 2007-10-26 11:31:11.276781194 -0400 +++ boost/fusion/adapted/std_pair.hpp 2007-10-26 11:31:32.676781424 -0400 @@ -20,7 +20,7 @@ namespace traits { template <typename T1, typename T2> - struct tag_of<std::pair<T1, T2> > + struct tag_of<std::pair<T1, T2>, void > { typedef struct_tag type; }
Not an ideal fix, but illustrates where the change for our compiler is necessary in the Boost source. The changes would need to be made in fusion/adapter/std_pair.hpp, fusion/sequence/generation/make_vector.hpp, fusion/sequence/generation/make_list.hpp to name a few :-(
Quite a lot. Fusion relies on it for, e.g. enable_if specialized classes. I'm curious though why all fusion::tuple tests run ok while the fusion::vector tests fail. The former is built using the latter (http://beta.boost.org/development/tests/trunk/developer/fusion.html)
So there is a source work around as well as a compiler fix. Like I mentioned earlier it will be some time before the compiler change is reflected into a production compiler. One of our internal requirements that we have for publishing results is that the compiler used to publish results has to be available to customers therefore I cannot use a pre-release compiler for nightly Boost runs.
How would you like to proceed?
I'd be willing to put in workarounds (ifdefs). Alas, I do not have access to this compiler. I'd appreciate help from you or someone else. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Not an ideal fix, but illustrates where the change for our compiler is necessary in the Boost source. The changes would need to be made in fusion/adapter/std_pair.hpp, fusion/sequence/generation/make_vector.hpp, fusion/sequence/generation/make_list.hpp to name a few :-(
Quite a lot. Fusion relies on it for, e.g. enable_if specialized classes. I'm curious though why all fusion::tuple tests run ok while the fusion::vector tests fail. The former is built using the latter (http://beta.boost.org/development/tests/trunk/developer/fusion.html)
So there is a source work around as well as a compiler fix. Like I mentioned earlier it will be some time before the compiler change is reflected into a production compiler. One of our internal requirements that we have for publishing results is that the compiler used to publish results has to be available to customers therefore I cannot use a pre-release compiler for nightly Boost runs.
How would you like to proceed?
I'd be willing to put in workarounds (ifdefs). Alas, I do not have access to this compiler. I'd appreciate help from you or someone else.
Since I've been the one pushing you fix this... I don't mind spending some time on this, but I don't have access to this platform/compiler either. Even if we could just get the TR1 tuples working that would be a big start. John.
"John Maddock" <john@johnmaddock.co.uk> wrote on 10/27/2007 12:40:06 PM:
Joel de Guzman wrote:
Not an ideal fix, but illustrates where the change for our compiler is necessary in the Boost source. The changes would need to be made in fusion/adapter/std_pair.hpp, fusion/sequence/generation/make_vector.hpp, fusion/sequence/generation/make_list.hpp to name a few :-(
Quite a lot. Fusion relies on it for, e.g. enable_if specialized classes. I'm curious though why all fusion::tuple tests run ok while the fusion::vector tests fail. The former is built using the latter (http://beta.boost.org/development/tests/trunk/developer/fusion.html)
So there is a source work around as well as a compiler fix. Like I mentioned earlier it will be some time before the compiler change is reflected into a production compiler. One of our internal requirements that we have for publishing results is that the compiler used to publish results has to be available to customers therefore I cannot use a pre-release compiler for nightly Boost runs.
How would you like to proceed?
I'd be willing to put in workarounds (ifdefs). Alas, I do not have access to this compiler. I'd appreciate help from you or someone else.
Since I've been the one pushing you fix this... I don't mind spending some time on this, but I don't have access to this platform/compiler either. Even if we could just get the TR1 tuples working that would be a big start.
John.
I can certainly help since I have access to the compiler:-) If I understand correctly what is meant by getting TR1 tuples working, making the change to std_pair.hpp will clean up TR1 tuple test problems. To help explain the compiler problem we can look at the small example: template <typename T0 = void, typename T1 = void> struct make_vector; template <typename T0> struct make_vector<T0> { }; The compiler is analyzing the partial specialization make_vector<T0> when the error message is emitted. The compiler has the partial specialization, and would like to find the primary class template. We find a candidate primary class template in "template <typename T0 = void, typename T1 = void> struct make_vector;". In the process of matching the partial specialization arguments to the primary class template parameters, we think that partial specializations are not allowed to use default parameters from the primary class template. Since the primary template class has two parameters, and the partial specialization explicitly specifies only one argument (ignoring the defaulted argument) we issues the error message: (S) Too few template arguments specified. The work around I suggested is to have the number of arguments on the partial specialization the same as the number of arguments on the primary class template. Chris Cambly XL C++ Compiler Development
Christopher Cambly wrote:
"John Maddock" <john@johnmaddock.co.uk> wrote on 10/27/2007 12:40:06 PM:
How would you like to proceed? I'd be willing to put in workarounds (ifdefs). Alas, I do not have access to this compiler. I'd appreciate help from you or someone else. Since I've been the one pushing you fix this... I don't mind spending some time on this, but I don't have access to this platform/compiler either. Even if we could just get the TR1 tuples working that would be a big start. John.
I can certainly help since I have access to the compiler:-) If I understand correctly what is meant by getting TR1 tuples working, making the change to std_pair.hpp will clean up TR1 tuple test problems.
Well, I was hoping for a fusion-wide fix: http://beta.boost.org/development/tests/trunk/developer/fusion.html
To help explain the compiler problem we can look at the small example:
template <typename T0 = void, typename T1 = void> struct make_vector; template <typename T0> struct make_vector<T0> { };
The compiler is analyzing the partial specialization make_vector<T0> when the error message is emitted.
The compiler has the partial specialization, and would like to find the primary class template. We find a candidate primary class template in "template <typename T0 = void, typename T1 = void> struct make_vector;". In the process of matching the partial specialization arguments to the primary class template parameters, we think that partial specializations are not allowed to use default parameters from the primary class template. Since the primary template class has two parameters, and the partial specialization explicitly specifies only one argument (ignoring the defaulted argument) we issues the error message: (S) Too few template arguments specified.
The work around I suggested is to have the number of arguments on the partial specialization the same as the number of arguments on the primary class template.
I understand the issue involved, but I'd really appreciate a patch. I can't just go on and tweak the whole library without any testing. I don't think I have the guts to submit any code to SVN without testing, especially at this point when we are just about to branch for release. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (3)
-
Christopher Cambly -
Joel de Guzman -
John Maddock