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 altivec)


Mark Mitchell wrote:
> 
> I think the fundamental question is not what to do about vector;
> it's whether or not we're going to try to implement the Altivec
> syntax or just its semantics.

Yep.

> It seems that most people would prefer the latter, but that the folks
> at Apple would prefer the former.  Apple would like to stop having
> to merge the Altivec patches, and they do not seem to believe that
> users will be willing to change their code.  Is that right?

More or less.  I don't consider merging to be a big issue; it's a
cost of doing business, and I'm prepared to maintain a set of
frontend hacks forever if necessary.

It's a more important problem that if we do nothing, PowerPC
developers will see three different versions of GCC; an FSF release,
a Red Hat release, and an Apple release, each with different forms
of support for AltiVec programming.  It's already the case that
some versions of PowerPC Linux ship with two compilers, one with
Motorola patches and one without, and each based on a different
release of GCC.  If AltiVec developers have to write three-way ifdefs
for every single source construct because we haven't been able to
come to some sort of agreement on what to support, they're not going
to praise some GCC maintainers and criticize others; we're all going
to come in for criticism, because users are not really interested in
our little internal disputes.

Now I believe that we do have some leeway to update the AltiVec
extension syntax, based on what I know of the size of our installed
base and how the code is written.  If there is a compromise that
allows us to have one version of GCC instead of three, and requires
only minor edits of source (such as {} instead of () for constants),
I think we will be able to get our users to adopt it.

Stan


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