I've finished my set of patches which fix -Wc++-compat to check for enum
conversions which are valid in C++. Adding those checks forced a lot of
changes in mainline to compile cleanly with -Wc++-compat. I have merged
those changes over to the gcc-in-cxx branch. In the gcc directory
itself, excluding changes to configure and Makefile, the gcc-in-cxx
branch compared to mainline is now
113 files changed, 1558 insertions(+), 1241 deletions(-)
Some of the remaining issues:
* C permits using the ++ and -- operators with a variable of enum type.
C++ does not (unless you explicit declare the operators, which for
purposes of -Wc++-compat I think we can assume to not occur).
* C permits defining a struct/enum/union within a struct/union and then
referring to the inner struct/enum/union outside of the enclosing
struct/union. C++ does not permit this--in C++ it has to be public
and you have to use a scope qualifier.
* C permits "struct s { }; typedef int s;". That is, you may reuse a
name as both a struct/enum/union tag and as a type. C++ does not
permit this.
* The C++ frontend warns about "while (true);" when there is no
whitespace between the ')' and the ';'. The C frontend does not. I'm
not sure how to best handle this. It doesn't make much sense to warn
about this with -Wc++-compat. Should the C frontend warn about this?
Should the C++ frontend not warn about this? Any opinions?
* In C an externally visible "inline" function (i.e., not "extern", not
"static") is assumed to be accessible outside of the current
translation unit (e.g., vn_nary_op_compute_hash in
gcc/tree-ssa-sccvn.c). In C++ this is not the case. It is also not
the case in C99, so this should be addressed anyhow, somehow, although
it doesn't seem to be a good fit for -Wc++-compat.
* In C a const variable which is neither "extern" nor "static" is
visible outside of the current translation unit. In C++ it is not,
without an explicit "extern" declaration. I'm not sure how best to
handle this with -Wc++-compat, since C does not permit initializing an
"extern const" variable.
* The C++ frontend does not support __attribute__ ((unused)) on labels.
The generator programs produce a lot of unused labels. Fixing this in
the C++ frontend may be awkward because C++ syntax permits a
declaration to follow a label, so it may not be clear which one gets
the attribute.
* The C++ frontend emits some warnings on code which is known to be
never executed, which the C frontend does not. This leads to some
warnings compiling code in gcc. I think it is reasonable to fix this
in the C++ frontend.
Ian
