This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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: [commit] Use -mabi=altivec for AltiVec tests


Daniel Jacobowitz wrote:

> I think I will check in my patch, but reduce the number of test
> cases a bit.  I'd like to test only two: -mabi=altivec + "set powerpc
> vector-abi altivec", and -mabi=altivec + "set powerpc vector-abi
> auto".  The former should always pass.  The latter will pass if GCC
> and LD are new enough.  Sound OK?
> 
> I don't want to test the non-AltiVec-ABI bits because they do not seem
> to be sensibly defined.  I filed PR 33899 last week, which shows
> the -mabi=no-altivec ABI changing based on -maltivec.  We can't and
> shouldn't detect that.

I'm not sure the situation is actually that bad; see the other mail
I just sent ...

I think we *should* have -mabi=no-altivec test, and treat vector
returns always as the -maltivec -mabi=no-altivec case in that
situation.

> Right.  I thought about this for a couple of days, and we should be
> able to save and restore them.  There's no reason it has to be
> predicated on -mabi=altivec.

Yes.  If you look at the comment in front of rs6000_stack_info,
saving Altivec registers for eabi targets should actually be
supported.  Not sure if that is actually implemented correctly
in the code ...  (For Linux there shouldn't be a problem anyway.)

> Of course, any existing -maltivec -mabi=no-altivec code will still
> have to be rebuilt.  It's terminally broken.

Maybe not completely; there are two failure modes: one, the caller
currently incorrectly assumes its callees save/restore vr0..vr19  --
this leads to a bug that is immediately detected, so there probably
isn't a lot of broken code out there;  and two, the callee currently
incorrectly does not even save vr20..vr31.  This second case could
cause silently broken code out there, but it is probably rare, as
GCC will start allocating registers from vr0 up, so you'd have to
have -maltivec -mabi=no-altivec code that uses more than 20 Altivec
registers in a single function ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


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