Some warning options trigger warnings in standard C++ headers, rendering -Werror unusable. This can be seen with a simple example: #include <list> int main() { std::list<int> foo; } When compiling with g++ -Weffc++ -Werror foo.cpp a lot of warnings about STL classes are emitted. While the gcc manual already mentions that -Weffc++ could produce spurious warnings, the same problems occurs with -Winline (I can try to produce a minimal test case if required). I think the compiler should ignore warnings in these files, as the user cannot fix them.
-Winline was fix for 3.3.1 with the fix for PR 10888. -Weffc++ most likely will not be fixed as it is useful to see the warnings sometimes.
Useful? For the user? I don't see how. I'm inclined to accept this as an enhancement request. It's a one liner for each -Weffc++ entry.
Created attachment 6642 [details] uses !DECL_IN_SYSTEM_HEADER to suppress warnings This suppresses the majority of warnings. However, there are 2 instances in class.c (lines 1234 & 3150) that I couldn't seem to pass the correct node to DECL_IN_SYSTEM_HEADER() from. In both cases I get the following error: "expected class 'd', have 't' (record_type) in check_field_decls" when I pass in 'basetype' and 't' respectively. Any pointers would be greatly appreciated. Cheers, Matt.
Putting trivial test cases together, both with and without #pragma GCC system_header in them, the compiler behaves correctly. Compiling the test case in comment 1 shows results in 24 lines of warnings, none of which the user can do anything about, as they all relate to the _internal_ headers in /usr/include/c++/${gcc-version}/bits. So, system headers appear to be treated correctly (e.g. <list> has the #pragma GCC system_header), but why are the headers in bits/ not treated as system headers? Neither adding the pragma to those headers, nor adding "-isystem /usr/include/c++/${gcc-version}/bits" to the command line appeared to have any effect.
Would someone mind commenting on what needs to happen with this bug please? My testing has shown that the behaviour of -Weffc++ is correct with regard to system headers. The problem is that some of the headers in /usr/include/c++/$gcc-version/bits aren't treated as system headers. This doesn't just affect -Weffc++, it actually affects *all* warning options (e.g. -Wunreachable-code is often triggered by such headers IIRC). Does the bug summary need changing? What about the component? (I suspect this is now in the realm of libstdc++). It seems closely related to bug 12854. Thanks, Matt
(In reply to comment #0) > Some warning options trigger warnings in standard C++ headers, rendering > -Werror > unusable. This can be seen with a simple example: > > #include <list> > int main() > { > std::list<int> foo; > } > > > When compiling with g++ -Weffc++ -Werror foo.cpp a lot of warnings about STL > classes are emitted. > While the gcc manual already mentions that -Weffc++ could produce spurious > warnings, the same problems occurs with -Winline (I can try to produce a > minimal > test case if required). I think the compiler should ignore warnings in these > files, as the user cannot fix them. > The real problem, as I understand it, is that we used to forget to copy the in_system_header marker from templates when doing instantiations. I think Mark Mitchell fixed that behaviour recently. At any case, mainline GCC (4.2.x) issues no warning with your testcase. -- Gaby