Re: gcc-in-cxx update

[Richard Guenther <richard dot guenther at gmail dot com>]

On Wed, Apr 29, 2009 at 9:39 AM, Ian Lance Taylor <iant@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
>