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]
Other format: [Raw text]

gcc-in-cxx update


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


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