This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [commit] Use -mabi=altivec for AltiVec tests
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 29 Oct 2007 19:27:01 +0100 (CET)
- Subject: 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