On Wed, Apr 29, 2009 at 9:39 AM, Ian Lance Taylor <i...@google.com> wrote:
> 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?
The C frontend should warn about this as well.
> * 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.
Right. Just fix it.
> * 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.
Does putting an extern const declaration in addition to the const
definition work in C and C++? If so you could warn about a
missing declaration just like we do for missing prototypes.
> * 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.
Or just amend the C frontend to also warn in these cases?
Richard.
> Ian
>
