This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
C++ and pedantic-errors for gcc extensions.
- To: gcc at gcc dot gnu dot org
- Subject: C++ and pedantic-errors for gcc extensions.
- From: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>
- Date: Fri, 04 May 2001 20:41:27 +0200
It looks like (on the trunk) that pedwarn with g++ are always turned
into errors...
>From cp/decl.c in function init_decl_processing:
/* Adjust various flags based on command-line settings. */
if (! flag_permissive && ! pedantic)
flag_pedantic_errors = 1;
Surprisingly, it looks like asking for -pedantic will
be more permissive than not specifying it !!!
I have not been able to test that on my test case (I have to reduce
it first, because -pedantic asks me to introduce a lot of typenames
everywhere to get to the point where the problem appears).
With g++ from April, 5th, I get:
mururoa->g++ -DHAVE_CONFIG_H -I. -I../../../../Robotvis++/Libs/Maths/tests -I../../.. -I../../../../Robotvis++/Libs/Maths/src -I../../../../Robotvis++/include -I../../../../Robotvis++/Libs/Utils/src -I../../../../Robotvis++/Contrib/blitz++ -I../../../Contrib/blitz++ -DNO_TRANSPOSE_WARNINGS -DSCOPEREF_BUG -ftemplate-depth-30 -g -DBZ_DEBUG -c ../../../../Robotvis++/Libs/Maths/tests/MeshRead.C | & more
../../../../Robotvis++/Libs/Maths/tests/MeshRead.C: In function `int main(int,
char**)':
../../../../Robotvis++/Libs/Maths/tests/MeshRead.C:54: choosing `typename
ITERATOR::Info<Geometry::Mesh<FACE> >::const_type
Geometry::Mesh<FACE>::begin(typename
Geometry::Mesh<FACE>::Categories::const_iterator&) const [with ITERATOR =
Geometry::face, FACE = Geometry::Face<3, Geometry::RealPoint3D>]' over
`typename ITERATOR::Info<Geometry::Mesh<FACE> >::type
Geometry::Mesh<FACE>::begin(typename
Geometry::Mesh<FACE>::Categories::iterator&) [with ITERATOR =
Geometry::face, FACE = Geometry::Face<3, Geometry::RealPoint3D>]'
../../../../Robotvis++/Libs/Maths/tests/MeshRead.C:54: because worst
conversion for the former is better than worst conversion for the latter
[Repeated 4 times with slight variations (begin,end) ]
And then it exits with code 1 (because errorcount==8) without
printing anything else nor producing the .o.
If this is confirmed as a bug and not a feature, I'll fill a gnats
report. I just wanted to be sure that it's not a feature....
By the way, I believe the message is wrong in this case as I pass the
exact type Geometry::Mesh<FACE>::Categories::const_iterator& to the
begin function, but I have hard time to reduce the test case to something
compact (at which point I may notice that it is my bug and not a compiler
one), but that's another story....
Is there anything, I should check ?? I already saw in function call.c:joust
after label tweak that the ranks for the two functions are 5 (USER_RANK)
and 1 (EXACT_RANK) respectively. Is EXACT_RANK is meaning no
conversion ?
--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
--------------------------------------------------------------------
PGP signature