From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17172 invoked by alias); 29 Oct 2007 18:27:07 -0000 Received: (qmail 17159 invoked by uid 22791); 29 Oct 2007 18:27:06 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.29.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 29 Oct 2007 18:27:04 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9TIR1uj017630 for ; Mon, 29 Oct 2007 18:27:01 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9TIR1mk2318432 for ; Mon, 29 Oct 2007 19:27:01 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9TIR1pV004503 for ; Mon, 29 Oct 2007 19:27:01 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l9TIR1Vn004500; Mon, 29 Oct 2007 19:27:01 +0100 Message-Id: <200710291827.l9TIR1Vn004500@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 29 Oct 2007 19:27:01 +0100 Subject: Re: [commit] Use -mabi=altivec for AltiVec tests To: drow@false.org (Daniel Jacobowitz) Date: Mon, 29 Oct 2007 18:32:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20071029180441.GA7736@caradoc.them.org> from "Daniel Jacobowitz" at Oct 29, 2007 02:04:41 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00763.txt.bz2 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