[Test] Intel 8 seems to need workaround
Linux regression tests seem to indicate that the workaround for Intel in class_properties.hpp should be extended to cover ICC 8.0 as well: 146c146 < #if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND( __COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 700 ) ---
#if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND( __COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 800 ) 160c160 < #if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND( __COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 700 )
#if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND( __COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 800 )
Warning: this diff has not actually been checked with ICC 8.0, but I'm confident it'll work as the problem looks exactly the same as with ICC 7.0: /boost/head-regression/boost/libs/test/src/unit_test_suite.cpp(224): error #453: protected member "boost::unit_test::class_property<PropertyType>::value [with PropertyType=boost::unit_test::unit_test_counter={unsigned long}]" is not accessible through a "boost::unit_test::readwrite_property<boost::unit_test::unit_test_counter={unsigned long}>" pointer or object p_stages_amount.value = p_stages_amount + 1; ^ Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Ok. Done. Gennadiy. P.S. BTW could anybody give some hint on "very short" error message by Intel compiler here: http://tinyurl.com/2c2zy
Gennadiy Rozental ha escrito:
Ok. Done.
Thanx!
Gennadiy.
P.S. BTW could anybody give some hint on "very short" error message by Intel compiler here: http://tinyurl.com/2c2zy
The problem seems to lie in that basic_cstring<>::npos is an unnamed enum, and ICC does not like it to be passed as a template arg (I don't actually know if this is a conformant diagnostic.) Anyway, the problem goes away (confirmed in ICC 7.1) with the folowing patch in basic_cstring.hpp: 58c58 < enum { npos = -1 }; ---
enum npos_type_ { npos = -1 };
Also, I have checked the patch does not break MSVC 6.5, and I don't think other compilers will have problems with it (it's perfectly legal and innocent C++). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
P.S. BTW could anybody give some hint on "very short" error message by Intel compiler here: http://tinyurl.com/2c2zy
The problem seems to lie in that basic_cstring<>::npos is an unnamed enum, and ICC does not like it to be passed as a template arg (I don't actually know if this is a conformant diagnostic.) Anyway, the problem goes away (confirmed in ICC 7.1) with the folowing patch in basic_cstring.hpp:
Thanks, Joaquín Applied. Is it indeed invalid? Gennadiy.
Gennadiy Rozental ha escrito:
P.S. BTW could anybody give some hint on "very short" error message by Intel compiler here: http://tinyurl.com/2c2zy
The problem seems to lie in that basic_cstring<>::npos is an unnamed enum, and ICC does not like it to be passed as a template arg (I don't actually know if this is a conformant diagnostic.) Anyway, the problem goes away (confirmed in ICC 7.1) with the folowing patch in basic_cstring.hpp:
Thanks, Joaquín
Applied. Is it indeed invalid?
I've investigated a little, and seems like it is really invalid. Comeau online yields the following: template<typename T> void foo(const T& t) { } enum{bar=0}; int main() { foo(bar); } Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1 Copyright 1988-2003 Comeau Computing. All rights reserved. MODE:strict errors C++ "ComeauTest.c", line 10: error: a template argument may not reference an unnamed type foo(bar); ^ So the patch puts you on the safe side. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
Linux regression tests seem to indicate that the workaround for Intel in class_properties.hpp should be extended to cover ICC 8.0 as well:
146c146 < #if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND( __COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 700 ) ---
#if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND(
__COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 800 ) 160c160 < #if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND( __COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 700 ) ---
#if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND(
__COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 800 )
Warning: this diff has not actually been checked with ICC 8.0, but I'm confident it'll work as the problem looks exactly the same as with ICC 7.0:
I've just tested with ICC 8.0 and this patch surely works. - Volodya
Warning: this diff has not actually been checked with ICC 8.0, but I'm confident it'll work as the problem looks exactly the same as with ICC 7.0:
I've just tested with ICC 8.0 and this patch surely works.
Well it solves the problem, but the EDG based compilers are amongst the most conforming compilers we have access to, are we sure that this is a compiler bug, rather than a code bug? If yes, do you have a test case: as I can pass it on to Intel. John.
John Maddock wrote:
Warning: this diff has not actually been checked with ICC 8.0, but I'm confident it'll work as the problem looks exactly the same as with ICC 7.0:
I've just tested with ICC 8.0 and this patch surely works.
Well it solves the problem, but the EDG based compilers are amongst the most conforming compilers we have access to, are we sure that this is a compiler bug, rather than a code bug? If yes, do you have a test case: as I can pass it on to Intel.
No, I don't have an easy test case: the snippet class B { protected: int i; }; class D : private B { public: using B::i; }; that Gennadiy referred to (IIRC) compiles without errors. - Volodya
Vladimir Prus <ghost@cs.msu.su> writes:
No, I don't have an easy test case: the snippet
class B { protected: int i; };
class D : private B { public: using B::i; };
that Gennadiy referred to (IIRC) compiles without errors.
The error occurs at the point of access. Try doing something that uses D::i. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
John Maddock ha escrito:
Warning: this diff has not actually been checked with ICC 8.0, but I'm confident it'll work as the problem looks exactly the same as with ICC 7.0:
I've just tested with ICC 8.0 and this patch surely works.
Well it solves the problem, but the EDG based compilers are amongst the most conforming compilers we have access to, are we sure that this is a compiler bug, rather than a code bug? If yes, do you have a test case: as I can pass it on to Intel.
Hi John, I think I have reduced the problem to an actual bug in EDG: class A { protected: int x; }; class AA:public A { public: using A::x; }; class TT; class T { public: class foo:public A // <<-- foo is the culprit! { friend class TT; }; protected: AA aa; }; class TT:public T { public: void foo(){aa.x=0;} }; int main() { } This fails with "ComeauTest.c", line 29: error: protected member "A::x" is not accessible through a "AA" pointer or object void foo(){aa.x=0;} ^ The error does not show if one of the two conditions hold (or both): 1. foo does not derive from A nor AA. 2. foo does not include the friend decl. Seems like a genuine bug to me. Comments welcome. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Hi John, I think I have reduced the problem to an actual bug in EDG:
class A { protected: int x; };
class AA:public A { public: using A::x; };
class TT;
class T { public: class foo:public A // <<-- foo is the culprit! { friend class TT; }; protected: AA aa; };
class TT:public T { public: void foo(){aa.x=0;} };
int main() { }
How presence of unrelated class foo affects access in class AA? Is it important that method is called foo also? Gennadiy.
Joaquín Mª López Muñoz ha escrito:
John Maddock ha escrito:
Warning: this diff has not actually been checked with ICC 8.0, but I'm confident it'll work as the problem looks exactly the same as with ICC 7.0:
I've just tested with ICC 8.0 and this patch surely works.
Well it solves the problem, but the EDG based compilers are amongst the most conforming compilers we have access to, are we sure that this is a compiler bug, rather than a code bug? If yes, do you have a test case: as I can pass it on to Intel.
Hi John, I think I have reduced the problem to an actual bug in EDG:
The bug demo can be reduced a little further: class A { protected: int x; }; class AA:public A { public: using A::x; }; class foo:public A // <<-- foo is the culprit! { friend class T; }; class T { public: AA aa; void foo(){aa.x=0;} }; int main() { } Same behavior and conditions for the error as before. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
John Maddock ha escrito:
Hi John, I think I have reduced the problem to an actual bug in EDG:
The bug demo can be reduced a little further:
That's really weird, the class that causes the error isn't even used !
Anyway it's been submitted to Intel as report number 247431.
Is there any way to track that issue? I've got a Premier account at Intel, but seems like it only displays the issues submitted by me. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (5)
-
David Abrahams -
Gennadiy Rozental -
Joaquín Mª López Muñoz -
John Maddock -
Vladimir Prus