--- Comment #15 from janis at gcc dot gnu dot org 2009-05-14 16:50 ---
Fixed by the patches shown in comments 12 and 13.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from bje at gcc dot gnu dot org 2009-05-14 05:34 ---
Can this PR be closed now, Janis?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526
--- Comment #13 from janis at gcc dot gnu dot org 2008-02-22 01:58 ---
Subject: Bug 34526
Author: janis
Date: Fri Feb 22 01:57:56 2008
New Revision: 132538
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132538
Log:
PR target/34526
* config/rs6000/rs6000.c (rs6000
--- Comment #12 from janis at gcc dot gnu dot org 2008-02-22 01:56 ---
Subject: Bug 34526
Author: janis
Date: Fri Feb 22 01:55:40 2008
New Revision: 132537
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132537
Log:
PR target/34526
* config/rs6000/rs6000.c (rs6000
--- Comment #11 from drow at gcc dot gnu dot org 2008-02-14 16:31 ---
Might want to try at least one SPE target, for completeness. I think
powerpc-*-eabispe is sim testable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526
--- Comment #10 from janis at gcc dot gnu dot org 2008-02-12 01:35 ---
I'm still plugging away at this since I keep thinking of more things I might
have broken. I've got some good new tests for the testsuite now that check how
arguments and return values are actually passed for powerpc6
--- Comment #9 from janis at gcc dot gnu dot org 2008-02-07 18:21 ---
I talked to Steve Munroe about the ABI issues. We determined that for
powerpc*-linux, vector types that cannot be passed in vector registers should
be passed as aggregates according to the relevant ABI (32-bit or 64-b
--- Comment #8 from janis at gcc dot gnu dot org 2008-02-07 02:04 ---
Some experimentation shows how GCC is passing and returning non-hardware
vectors for powerpc*-linux:
-m32 (for trunk and 4.0)
pass struct by reference (copy in caller's frame)
return struct in memory using address
--- Comment #7 from drow at gcc dot gnu dot org 2008-02-05 03:19 ---
Subject: Re: no-altivec ABI should be fixed or no longer
be the default
On Tue, Feb 05, 2008 at 02:23:20AM -, janis at gcc dot gnu dot org wrote:
> There's another mess hiding under the ABI change, which i
--- 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 syntheti
--- Comment #5 from janis at gcc dot gnu dot org 2008-02-04 21:28 ---
A prerequisite to changing the default to the AltiVec ABI is to fix
-mabi=no-altivec. A patch for that is at
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00094.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #4 from janis at gcc dot gnu dot org 2008-01-30 01:34 ---
TARGET_ALTIVEC_VRSAVE is also set to one in rs6000_override_options after
-mno-vrsave has been process, meaning that the option has no effect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526
--- Comment #3 from janis at gcc dot gnu dot org 2008-01-29 23:45 ---
While testing an extremely simple patch for this PR I discovered that
-mabi=no-altivec hasn't had an effect since r99284, which changed the way that
options are handled for the rs6000 back end. Before that change,
rs6
--- Comment #2 from janis at gcc dot gnu dot org 2008-01-25 23:19 ---
I'm planning to write and test a patch to change the default ABI to be the
AltiVec ABI. I don't anticipate, though, that any issues would be found with
the GCC testsuite; any problems would be due to compatibility iss
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org
|dot org
--- Comment #1 from janis at gcc dot gnu dot org 2007-12-19 18:50 ---
I'd like to see -mabi=altivec be the default for -m32, with -mabi=no-altivec
available for the rare cases when it's needed. Would changing the default
cause any problems?
--
http://gcc.gnu.org/bugzilla/show_bug.c
16 matches
Mail list logo
