On Mon, Oct 13, 2014 at 9:20 AM, Ulrich Weigand wrote:
> Maciej W. Rozycki wrote:
>> On Thu, 9 Oct 2014, Maciej W. Rozycki wrote:
>>
>> > Seeing Rohit got good results it has struck me that perhaps one of the
>> > patches I had previously reverted, to be able to compile GCC in the first
>> > plac
Maciej W. Rozycki wrote:
> On Thu, 9 Oct 2014, Maciej W. Rozycki wrote:
>
> > Seeing Rohit got good results it has struck me that perhaps one of the
> > patches I had previously reverted, to be able to compile GCC in the first
> > place, interfered with this fix -- I backed out all the subseque
On Thu, 9 Oct 2014, Maciej W. Rozycki wrote:
> Seeing Rohit got good results it has struck me that perhaps one of the
> patches I had previously reverted, to be able to compile GCC in the first
> place, interfered with this fix -- I backed out all the subsequent patches
> to test yours and Roh
On Thu, 9 Oct 2014, Ulrich Weigand wrote:
> > The patch works for me.
> > Tested with GCC v4.9 branch rev 216036 and GCC trunk rev 216027.
>
> Thanks for testing! Can you work with Maciej to find out why he's
> seeing different results?
Seeing Rohit got good results it has struck me that perha
t; > Subject: Re: [RFC: Patch, PR 60102] [4.9/4.10 Regression] powerpc fp-bit
> > ices@dwf_regno
> [snip]
> > >
> > > Rohit, could you verify whether this fixes the SPE problem?
> >=20
> > Thanks for your work, I have applied your change to my 4.9 setup, rebu
> -Original Message-
> From: Maciej W. Rozycki [mailto:ma...@codesourcery.com]
> To: Ulrich Weigand
> Cc: Dharmakan Rohit-B30502; Wienskoski Edmar-RA8797; David Edelsohn; gcc-
> patc...@gcc.gnu.org; Alan Modra; Jakub Jelinek
> Subject: Re: [RFC: Patch, PR 60102] [4
Ulrich,
> > While emitting the location descriptors of multiple registers (SPE high/low
> > part) individually, the GCC hard register number is converted in to DWARF
> > register number using "dbx_reg_number" [Statement "A", "B" & "C" below].
>
> > But statement "C" macro "DBX_REGISTER_NUMBER" g
On Wed, Oct 8, 2014 at 2:09 PM, Ulrich Weigand wrote:
> rohitarulraj wrote:
>
>> I was able to narrow down the issue.
> [snip]
>> While emitting the location descriptors of multiple registers (SPE high/low
>> part) individually, the GCC hard register number is converted in to DWARF
>> register num
rohitarulraj wrote:
> I was able to narrow down the issue.
[snip]
> While emitting the location descriptors of multiple registers (SPE high/low
> part) individually, the GCC hard register number is converted in to DWARF
> register number using "dbx_reg_number" [Statement "A", "B" & "C" below].
>
> From: Dharmakan Rohit-B30502
> Sent: Monday, September 29, 2014 3:54 PM
>
> > From: Ulrich Weigand [mailto:uweig...@de.ibm.com] Maciej W. Rozycki
> > wrote:
> > > On Mon, 4 Aug 2014, Edmar wrote:
> > >
> > > > Committed on trunk, revision 213596 Committed on 4.9 branch,
> > > > revision 213597
>
On Mon, 29 Sep 2014, rohitarul...@freescale.com wrote:
> > As I understand it, the change was supposed to only affect GCC internals,
> > all
> > externally generated debug info was supposed to remain unchanged.
> >
> > If there are changes in debug info, something must have gone wrong.
>
> Let
> From: Ulrich Weigand [mailto:uweig...@de.ibm.com]
> Maciej W. Rozycki wrote:
> > On Mon, 4 Aug 2014, Edmar wrote:
> >
> > > Committed on trunk, revision 213596
> > > Committed on 4.9 branch, revision 213597
> >
> > This change regressed GDB for e500v2 multilibs, presumably because it
> > does
Maciej W. Rozycki wrote:
> On Mon, 4 Aug 2014, Edmar wrote:
>
> > Committed on trunk, revision 213596
> > Committed on 4.9 branch, revision 213597
>
> This change regressed GDB for e500v2 multilibs, presumably because it
> does not understand the new DWARF register numbers and does not know how
On Mon, 4 Aug 2014, Edmar wrote:
> Committed on trunk, revision 213596
> Committed on 4.9 branch, revision 213597
This change regressed GDB for e500v2 multilibs, presumably because it
does not understand the new DWARF register numbers and does not know how
to map them to hardware registers. H
Jackub,
Thanks for point this up.
I apologize for the sloppiness.
I fixed and committed the ChangeLogs on the branch, revision 213639
Also fixed the libgcc ChangeLog on trunk. Revision 213640
Edmar
On 08/05/2014 03:11 AM, Jakub Jelinek wrote:
On Mon, Aug 04, 2014 at 11:51:34AM -0500, Edmar w
Jakub,
> On Mon, Aug 04, 2014 at 11:51:34AM -0500, Edmar wrote:
> > Committed on trunk, revision 213596
> > Committed on 4.9 branch, revision 213597
>
> Note the ChangeLog entry was grossly misformated.
> I've fixed it up in gcc/ChangeLog on the trunk, but not on the branch
> nor in libgcc. The
On Mon, Aug 04, 2014 at 11:51:34AM -0500, Edmar wrote:
> Committed on trunk, revision 213596
> Committed on 4.9 branch, revision 213597
Note the ChangeLog entry was grossly misformated.
I've fixed it up in gcc/ChangeLog on the trunk, but not on the branch
nor in libgcc. There should be no space b
Committed on trunk, revision 213596
Committed on 4.9 branch, revision 213597
I made an omission on the first commit. I did not add
the test case and corresponding ChangeLog entry.
Committed as obvious on trunk, revision 213598
Thanks
Edmar
On 08/04/2014 05:25 AM, Ulrich Weigand wrote:
David E
David Edelsohn wrote:
> On Fri, Aug 1, 2014 at 2:03 PM, rohitarul...@freescale.com
> wrote:
> > [libgcc]
> > 2014-07-31 Rohit
> > * config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Update
> > based on change in SPE high register numbers and 3 HTM registers.
> >
> > [gc
On Fri, Aug 1, 2014 at 2:03 PM, rohitarul...@freescale.com
wrote:
> Hello Ulrich,
>
> Thanks.
>
>> > /* Use gcc hard register numbering for eh_frame. */ -#define
>> >DWARF_FRAME_REGNUM(REGNO) (REGNO)
>> >+#define DWARF_FRAME_REGNUM(REGNO) \
>> >+ ((REGNO) >= FIRST_SPE_HIGH_REGNO ? ((REGNO) -
>>
Jakub,
> On Fri, Aug 01, 2014 at 06:03:56PM +, rohitarul...@freescale.com wrote:
> > PR target/60102
>
> --- libgcc/config/rs6000/linux-unwind.h (revision 213110)
> +++ libgcc/config/rs6000/linux-unwind.h (working copy)
> @@ -274,8 +274,8 @@ ppc_fallback_frame_state (struct _Unwind
> #if
On Fri, Aug 01, 2014 at 06:03:56PM +, rohitarul...@freescale.com wrote:
> PR target/60102
--- libgcc/config/rs6000/linux-unwind.h (revision 213110)
+++ libgcc/config/rs6000/linux-unwind.h (working
Hello Ulrich,
Thanks.
> > /* Use gcc hard register numbering for eh_frame. */ -#define
> >DWARF_FRAME_REGNUM(REGNO) (REGNO)
> >+#define DWARF_FRAME_REGNUM(REGNO) \
> >+ ((REGNO) >= FIRST_SPE_HIGH_REGNO ? ((REGNO) -
> FIRST_SPE_HIGH_REGNO +
> >+1200) : (REGNO))
>
> Any reason for not using SPE_
Rohit,
> #define DWARF_REG_TO_UNWIND_COLUMN(r) \
>- ((r) > 1200 ? ((r) - 1200 + (DWARF_FRAME_REGISTERS - 32)) : (r))
>+ ((r) >= 1200 ? ((r) - 1200 + (DWARF_FRAME_REGISTERS - 32)) : (r))
OK, makes sense.
> /* Use gcc hard register numbering for eh_frame. */
>-#define DWARF_FRAME_REGNUM(REGNO)
Ulrich,
Thanks for your comments, I have updated the patch accordingly.
> > /* The SPE has an additional 32 synthetic registers, with DWARF debug
> > info numbering for these registers starting at 1200. While
> > eh_frame @@ -951,13 +952,14 @@ enum data_align { align_abi, align_opt,
> >
Rohit wrote:
> This is related to the following bug:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60102
>
> I have tried to fix the e500v2 build on GCC v4.9.0 with the attached patch.
> Can you please review and comment on the changes especially DWARF_FRAME_REG=
> NUM, DWARF_REG_TO_UNWIND_COLU
26 matches
Mail list logo
