This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
- From: Alan Modra <amodra at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>, Jakub Jelinek <jakub at redhat dot com>, gcc-patches at gcc dot gnu dot org, dje dot gcc at gmail dot com, rguenther at suse dot de, ulrich dot weigand at de dot ibm dot com, bergner at vnet dot ibm dot com
- Date: Thu, 20 Mar 2014 13:48:55 +1030
- Subject: Re: [4.8, PATCH 0/26] Backport Power8 and LE support
- Authentication-results: sourceware.org; auth=none
- References: <1395257038 dot 17148 dot 2 dot camel at gnopaine> <20140319200518 dot GD1817 at tucnak dot redhat dot com> <1395262998 dot 3599 dot 7 dot camel at gnopaine> <532A0DBF dot 202 at redhat dot com>
On Wed, Mar 19, 2014 at 03:35:59PM -0600, Jeff Law wrote:
> On 03/19/14 15:03, Bill Schmidt wrote:
> >On Wed, 2014-03-19 at 21:05 +0100, Jakub Jelinek wrote:
> >
> >>I guess the most important question is what guarantees there are that it
> >>won't affect non-powerpc* ports too much (my main concern is the 9/26 patch,
> >>plus the C++ FE / libstdc++ changes), and how much does this affect
> >>code generation and overall stability of the PowerPC big endian existing
> >>targets.
> >>
> >> Jakub
> >>
> >
> >The three pieces that are somewhat controversial for non-powerpc targets
> >are 9/26, 10/26, 15/26.
> >
> > * Uli and Alan, can you speak to any concerns for 9/26?
> I've got no concerns about 9/26. Uli, Alan and myself worked
> through this pretty thoroughly. I've had those in the back of my
> mind as something we're going to want to make sure to pull in.
Thanks Jeff. I don't have any concern over 9/26, it's quite
conservative like most of the ELFv2 implementation. When we were
looking at parameter passing changes we didn't go as far as we could.
For example, we still pass fp to varargs functions in both fp regs and
on the stack, when only the stack will be used by a callee correctly
implementing either ELFv2 or ELFv1 ABIs. Another thing that we didn't
change is that sibcalls can be allowed in more cases than the current
code allows.
--
Alan Modra
Australia Development Lab, IBM