This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

C++ and pedantic-errors for gcc extensions.



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]