On Thu, 2011-11-03 at 09:13 -0500, Peter Bergner wrote:
> On Thu, 2011-11-03 at 14:48 +0100, Rainer Orth wrote:
> > I sent a patch for that one:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00300.html
> >
> > plus Paolo's typo fix:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2011-1
Peter Bergner writes:
> On Thu, 2011-11-03 at 09:13 -0500, Peter Bergner wrote:
>> On Thu, 2011-11-03 at 14:48 +0100, Rainer Orth wrote:
>> > I sent a patch for that one:
>> >
>> >http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00300.html
>> >
>> > plus Paolo's typo fix:
>> >
>> >http://g
On Thu, 2011-11-03 at 14:48 +0100, Rainer Orth wrote:
> I sent a patch for that one:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00300.html
>
> plus Paolo's typo fix:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00302.html
Thanks, I kicked off a bootstrap with those changes
Peter Bergner writes:
> Hmmm, more fallout from the libgcc move. I think I'm just going to
> use an older checkout to test with until the libgcc fallout gets fixed.
>
> ...
> xgcc: error: ecrti.S: No such file or directory
> xgcc: fatal error: no input files
> compilation terminated.
> make[5]:
On Wed, 2011-11-02 at 22:02 +, Iain Sandoe wrote:
> On 2 Nov 2011, at 19:39, Peter Bergner wrote:
>
> > On Wed, 2011-11-02 at 19:33 +, Iain Sandoe wrote:
> >> I'm going to try this
> >> char name[32];
> >> - get_ppc64_thunk_name (name);
> >> + get
On 2 Nov 2011, at 19:39, Peter Bergner wrote:
On Wed, 2011-11-02 at 19:33 +, Iain Sandoe wrote:
I'm going to try this
char name[32];
- get_ppc64_thunk_name (name);
+ get_ppc476_thunk_name (name);
This (together with the changes for HAVE_GAS_HIDD
On Wed, 2011-11-02 at 14:05 -0500, Peter Bergner wrote:
> On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote:
> > Hmm .. I wonder if this is just a temporary glitch because of the move
> > of files to libgcc.
>
> Note that I just hit a problem with the libgcc move. We need:
>
> Index: libgcc
On Wed, 2011-11-02 at 19:33 +, Iain Sandoe wrote:
> I'm going to try this
>
> $ svn diff -x -p gcc/config/rs6000/rs6000.c
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c (revision 180788)
> +++ gcc
On 2 Nov 2011, at 19:05, Peter Bergner wrote:
On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote:
I'll investigate a bit further later...
So you didn't start your build from scratch? I'll keep my
fingers crossed that a fresh build fixing things for you.
Otherwise, let me know what you fin
On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote:
> Hmm .. I wonder if this is just a temporary glitch because of the move
> of files to libgcc.
Note that I just hit a problem with the libgcc move. We need:
Index: libgcc/config/rs6000/t-ppccomm
=
On 2 Nov 2011, at 18:34, Peter Bergner wrote:
On Wed, 2011-11-02 at 18:17 +, Iain Sandoe wrote:
also in macho_branch_islands () :
if (TARGET_LINK_STACK)
{
char name[32];
get_ppc64_thunk_name (name);
strcat (tmp_buf, ":\n\tmfl
On Wed, 2011-11-02 at 13:18 -0400, David Edelsohn wrote:
> The two new functions have mistakes because I did not realize the
> semantics of HAVE_GAS_HIDDEN. HAVE_GAS_HIDDEN is not a macro to be
> tested at runtime, but a macro tested at compile time.
I'm sorry, I didn't realize that either. Does
On Wed, 2011-11-02 at 18:17 +, Iain Sandoe wrote:
> also in macho_branch_islands () :
>
> if (TARGET_LINK_STACK)
> {
> char name[32];
> get_ppc64_thunk_name (name);
> strcat (tmp_buf, ":\n\tmflr r0\n\tbl ");
> strcat (tmp_buf, n
On 2 Nov 2011, at 17:18, David Edelsohn wrote:
On Tue, Nov 1, 2011 at 3:00 PM, Peter Bergner
wrote:
+/* Fills in the label name that should be used for a 476 link
stack thunk. */
+
+void
+get_ppc476_thunk_name (char name[32])
+{
+ gcc_assert (TARGET_LINK_STACK);
+
+ if (HAVE_GAS_HIDDE
On Tue, Nov 1, 2011 at 3:00 PM, Peter Bergner wrote:
> +/* Fills in the label name that should be used for a 476 link stack thunk.
> */
> +
> +void
> +get_ppc476_thunk_name (char name[32])
> +{
> + gcc_assert (TARGET_LINK_STACK);
> +
> + if (HAVE_GAS_HIDDEN)
> + sprintf (name, "__ppc476.ge
On Tue, Nov 01, 2011 at 02:00:25PM -0500, Peter Bergner wrote:
> (get_ppc476_thunk_name): New function.
> (rs6000_code_end): Likewise.
rs6000.c:27968:1: error: 'void rs6000_code_end()' defined but not used
[-Werror=unused-function]
cc1plus: all warnings being treated as errors
Bootst
On Mon, 2011-10-31 at 19:05 -0400, David Edelsohn wrote:
> Okay, go ahead with PPC64 support as well. Hopefully no one ever will
> have to use it. That implies the option should not explicitly
> reference ppc476.
Ok, for completeness, I attached what I committed below, which includes
the support
On Mon, Oct 31, 2011 at 5:32 PM, Peter Bergner wrote:
> Ok, attached below is the updated patch that passes bootstrap and regtesting
> that only enables the new link stack code for 32-bit compiles. However,
> talking with Alan, he mentioned we just have to mark the opd entry weak
> and that will
On Fri, 2011-10-28 at 15:37 -0400, David Edelsohn wrote:
> On Fri, Oct 28, 2011 at 12:36 PM, Peter Bergner wrote:
>
> > So David, do we even want to bother trying to support this on -m64
> > given the only cpu that needs this is a 32-bit only cpu? If so, I
> > can try and work with Alan to figur
On Fri, Oct 28, 2011 at 12:36 PM, Peter Bergner wrote:
> So David, do we even want to bother trying to support this on -m64
> given the only cpu that needs this is a 32-bit only cpu? If so, I
> can try and work with Alan to figure out how we can merge the
> function descriptors for the thunk rou
On 10/28/2011 11:35 AM, Peter Bergner wrote:
> On Fri, 2011-10-28 at 09:44 -0700, Richard Henderson wrote:
>> Not quite. You can't allow the user to set TARGET_LINK_STACK either,
>> for 64-bit. Because it won't work without further fixups. More like
>>
>> if (TARGET_POWERPC64)
>> SET_TARGE
On Fri, 2011-10-28 at 09:44 -0700, Richard Henderson wrote:
> Not quite. You can't allow the user to set TARGET_LINK_STACK either,
> for 64-bit. Because it won't work without further fixups. More like
>
> if (TARGET_POWERPC64)
> SET_TARGET_LINK_STACK (0);
> if (TARGET_LINK_STACK == -1)
On 10/28/2011 09:36 AM, Peter Bergner wrote:
> Oops, you're write. Had I compiled with -m64 -mcpu=power7 -mtune=476fp,
> I would have caught that. I guess (supposing we don't want to support
> 64-bit) I should have the following hunks instead, correct?
>
> + /* If not explicitly specified via o
On Fri, 2011-10-28 at 08:20 -0700, Richard Henderson wrote:
> On 10/27/2011 06:43 PM, Peter Bergner wrote:
> > Ok, here's a patch to implement that, and it passes bootstrap and
> > regtesting. Richard, is this what you had in mind? I'll note that
> > I disabled rs6000_code_end for TARGET_POWERPC6
On 10/27/2011 06:43 PM, Peter Bergner wrote:
> Ok, here's a patch to implement that, and it passes bootstrap and
> regtesting. Richard, is this what you had in mind? I'll note that
> I disabled rs6000_code_end for TARGET_POWERPC64, since I was running
> into linker errors when building libgcc. T
On Thu, 2011-10-27 at 20:43 -0500, Peter Bergner wrote:
> Index: gcc/config/rs6000/476.opt
[snip]
> +Target Var(rs6000_link_stack) Init(1) Save
Oops, this should actually be Init(-1). The hunk above was just my
way of testing the modified code more by enabling it by default.
Sorry about that.
Pe
On Thu, 2011-10-13 at 10:03 -0700, Richard Henderson wrote:
> On 10/13/2011 08:49 AM, Peter Bergner wrote:
> > + if (TARGET_LINK_STACK)
> > + asm_fprintf (file, "\tbl 1f\n\tb 2f\n1:\n\tblr\n2:\n");
> > + else
> > + asm_fprintf (file, "\tbcl 20,31,1f\n1:\n");
>
> Wouldn't it be
On 10/13/2011 08:49 AM, Peter Bergner wrote:
> + if (TARGET_LINK_STACK)
> + asm_fprintf (file, "\tbl 1f\n\tb 2f\n1:\n\tblr\n2:\n");
> + else
> + asm_fprintf (file, "\tbcl 20,31,1f\n1:\n");
Wouldn't it be better to set up an out-of-line "blr" insn that could
be shared by
On Mon, 2011-09-12 at 15:29 -0400, David Edelsohn wrote:
> First, please choose a more informative option name.
> -mpreserve-link-stack seems like something generally useful for all
> processors and someone may randomly add the option. It always is
> useful to preserve the link stack -- that's why
On Mon, Sep 12, 2011 at 12:07 PM, Peter Bergner wrote:
> The Power ISA declares the "bcl 20,31,..." instruction as the preferred
> idiom for obtaining the next instruction address (NIA), which we use for
> computing the address of the GOT. This special branch and link is *not*
> a subroutine call
The Power ISA declares the "bcl 20,31,..." instruction as the preferred
idiom for obtaining the next instruction address (NIA), which we use for
computing the address of the GOT. This special branch and link is *not*
a subroutine call, meaning it won't be paired with a blr (subroutine return).
P
31 matches
Mail list logo
