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
30 matches
Mail list logo
