From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18424 invoked by alias); 5 Feb 2008 02:24:03 -0000 Received: (qmail 18257 invoked by uid 48); 5 Feb 2008 02:23:19 -0000 Date: Tue, 05 Feb 2008 02:24:00 -0000 Message-ID: <20080205022319.18256.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/34526] no-altivec ABI should be fixed or no longer be the default In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "janis at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-02/txt/msg00479.txt.bz2 ------- Comment #6 from janis at gcc dot gnu dot org 2008-02-05 02:23 ------- There's another mess hiding under the ABI change, which is that synthetic vectors of the same size as AltiVec vectors are passed differently for -mabi=altivec than for -mabi=no-altivec. There are warnings for synthetic vectors passed by reference with "-mno-altivec -mabi=no-altivec" (currently the -m32 default) but no warning for "-mno-altivec -mabi=altivec" (the planned -m32 default). Varargs are apparently broken for "-mno-altivec -mabi=altivec", or at least test gcc.c-torture/execute/va-arg-25.c fails with those options as the default. I wonder if anything actually uses synthetic vectors and if so, whether they are ever passed as arguments or return values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526