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]

Re: Target-specific Front-Ends? (Was: front end changes for


Ziemowit Laski writes:
> I'd like to have some sort of a statement from the SC specifying the
> technical parameters of an acceptable solution -- in other words, a
> guarantee that if a solution meeting those criteria is created, it will
> be accepted.  No more Pascal string work from me. :) :)

The SC generally works by consensus -- if there's a controversy we have
a problem because our rules require a 3/4 vote.  If people work something
acceptable out on this list, I am sure that it will be accepted.  But
the SC's job is not to do a technical design, and it would be difficult
to write a blank check in advance.  After all, if we forget something and
we are then presented with a patch that would damage gcc's maintainability
in some way we hadn't thought of, plus a copy of our signed guarantee,
what then?  So I'm afraid that all we can offer is good will and
willingness to work with you to find a solution, iterating until complete.
If we can't come to an agreement, at the very least the size of the
patches that you'd have to maintain separately should be substantially
reduced.

It seems that there is some convergence going on around the idea that GCC
would support a syntax similar to Altivec but in some senses more general,
but with at least one difference in that vector literals would be C99
style, plus possibly an optional alteration in preprocessing to allow
existing syntax to be handled.  I think that there's some jumping of the
gun going on: you're proposing solutions before the problem has been fully
defined.  What will the GCC syntax be (and what are the semantics)?  This
determines what kind of rewriting you have to do.  Also, is lexing alone
strong enough to do the conversion, or do you need parsing as well?  The
vector literals aren't regular expressions, since constant expressions are
allowed, but if all you need is the ability to count nesting depth in
parentheses this isn't so bad.


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