This is the mail archive of the 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: A Far Less Ambitous AltiVec patch

> >There is no documentation for mangle_vendor_type.
> You mean in mangle.c itself?  OK, I'll put it in.

No doc/tm.texi

When y'all come to a consensus on this, you need to submit the vendor
mangling part (if it's agreed that it is the way to go) as a separate

> >You never reported regression results.  Segher also said he would test
> >on ppc64-linux, but I haven't heard from him either.
> Well, no, I didn't bother, suspecting that some time will elapse between
> my posting of the patch and another human reviewing it.  I have, of 

You didn't BOTHER?  Oh please, you _have_ read the patch submission
guidelines, have you?  That's not a good attitude to take if you want

Having said that, I do apologize for taking so long in reviewing your
(and everybody else's AltiVec) patches.  But that's no excuse for not

> >>+ /* The "-faltivec" option should have been called "-maltivec" all 
> >>along.  */
> >>+   { "-faltivec", "-maltivec -include altivec.h" },	\
> >>+   { "-fno-altivec", "-mno-altivec" },	\
> >
> >Do we really need another option (even if just for Darwin)?  This is
> >just plain sick.  Can't you make -maltivec include altivec.h just for
> >darwin?
> The '-faltivec' option is part of Apple AltiVec folklore as much as the
> C++ mangling.

I really dislike this, but I'm going to withdraw my objection seeing
that this is only for darwin.  And folklore is _such_ a convincing
argument ;-).

> >>        else
> >>! 	fprintf (file, "%d", REGNO (XEXP (x, 0)));
> >>        return;
> >
> >>      case 'q':
> >>--- 8960,8966 ----
> >>  	  || REGNO (XEXP (x, 0)) >= 32)
> >>  	output_operand_lossage ("invalid %%P value");
> >>        else
> >>! 	fprintf (file, "%s", reg_names[REGNO (XEXP (x, 0))]);
> >
> >Uhh, what in the world is this?  I thought all assemblers were
> >supposed to support plain reg numbers.
> Obviously then, you did not even go near Darwin when testing your

Of course not; did I ever claim I did?  Apple had it's own thing, I
had no darwin box, and no one using darwin seem to care enough to give

> original AldyVec work. :-)  The Darwin assembler requires register
> operands to be encoded as such (and for a very good reason, IMHO).

You need to ok this part with David or Geoff.  It's not altivec

> I'll check if we have YDL installed somewhere, but I'm assuming that
> _you_ do? :-)

Well since you asked... My G5 was DOA and the new one is in transit.
If you repost with the suggestions, only leave the altivec stuff, and
test...I'll scrounge around for a G4 and test on linux.

> Our internal testsuite utilizes Motorola syntax, so that's a no-go
> and you know it. :-)

Uh, it only took me 10-15 minutes to change the entire Moto testsuite
to work with FSF gcc.  Sed and emacs macros are your friends.


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