This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for %E formatting for C
On Sun, 3 Oct 2004, Gabriel Dos Reis wrote:
> A label is a decl (LABEL_DECL) so it should have been used with %E,
> just like any other _DECL in such contexts. It seems that most of
This error is not where there is a DECL - it is where it makes no sense to
create a DECL. The C++ front end has much the same diagnostic, but it
uses `%E' on the IDENTIFIER_NODE (not on the DECL, which it does not
create). The code being diagnosed is of the form
void *p = &&q;
where q is a label, not an expression, being used in such a way that there
is no use in creating a LABEL_DECL. Indeed quite plausibly the compiler
might not handle LABEL_DECLs outside a function; they have no use in valid
code, so better to be sure that they are never created so they don't need
to be handled.
Many other errors and warnings are in parsing and while the information
about a declaration is being processed before the DECL is created,
possibly before it is known what kind of DECL should be created. Thus the
IDENTIFIER_NODE is what's available at diagnostic time; a DECL isn't, and
in future this means only something with static type other than "tree" is
available. (Identifiers ceasing to be trees is something that has been
proposed for years; it's not something new.) At present, in most such
cases the C front end uses %qs with IDENTIFIER_POINTER (which isn't
particularly clean, as a format for identifiers would be better, but could
continue to work unchanged when identifiers have a different static type)
and the C++ front end uses `%E'.
c-common.c, with the many diagnostics for warnings for attributes ignored,
which use %qs, is part of the C++ front end as well as part of the C front
end. An attribute name is neither an expression nor a declaration; it is
an identifier (possibly a keyword).
> those cases where " a clear use of %I" is advocated, there is a
> misuse of IDENTIFIER_POINTER in the first place; those should have
> referenced the real entity.
The real entity is in many such cases an identifier which might later
become a DECL, but is being diagnosed because of checks during the code to
determine information that will go in that DECL.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)