This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: proposed Opengroup action for c99 command (XCU ERN 76)
- From: "Zack Weinberg" <zackw at panix dot com>
- To: joseph at codesourcery dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 16 Sep 2005 12:42:15 -0700 (PDT)
- Subject: Re: proposed Opengroup action for c99 command (XCU ERN 76)
[I apologize for breaking the thread; I am currently stuck using a web-mail
client that does not permit manual insertion of References: headers. Please
don't take this comment as a sign that I am resuming participation in GCC
development in general.]
Joseph Myers:
> There are plenty of spare bits in cpp_token to flag extended identifiers
> and handle them specially (as a slow path, marked as such with
> __builtin_expect). There's one bit in the flags byte, two unused bytes
> after it and a whole word not used in the case of identifiers (identifiers
> use a cpp_hashnode * where strings and numbers use a struct cpp_string
> which is bigger)
Especially for C++ which constructs a cpp_token array (sort of) representing
the entire translation unit, it is desirable to make cpp_token *smaller* --
and it would be relatively easy to win back that 'whole word not used in the
case of identifiers', so I do not like a solution which starts using that word
for identifiers. Note that identifiers and punctuators are vastly more common
than numbers or strings, in all C-family languages.
Geoff Keating:
> > Adding salt to the wound, of course, is that for C the only difference
> > between an (A) or (B) and a (C) implementation is that a (C)
> > implementation is less expressive: there are some programs, all of
> > which are erroneous and require a diagnostic, that can't be written.
> > So you lose compiler performance just so users have another bullet
> > to shoot their feet with.
Joseph:
> C++ requires (A) and provides examples of valid programs where it can be
> told whether a normalisation of UCNs is part of the implementation-defined
> phase 1 transformation.
I am with Joe Buck in the opinion that even a 1% performance penalty for
implementing (A) [or (B)] would be too much -- I suggest this be fixed by
convincing the C++ committee to allow (C) and not just by phase 1
transformations, thus allowing the existing implementation to conform.
zw