On 06/12/2015 01:11 PM, Richard Biener wrote:
By the way, I think we should apply this fix to the GCC 5 branch as
well. May I?
Yes
Done. Thanks again!
--
Pierre-Marie de Rodat
On June 12, 2015 12:31:02 PM GMT+02:00, Pierre-Marie de Rodat
wrote:
>On 06/12/2015 07:41 AM, Richard Biener wrote:
>> On June 12, 2015 2:30:36 AM GMT+02:00, David Edelsohn
> wrote:
>>> This patch broke AIX bootstrap because dbxout.c was not updated for
>>> the XCOFF_DEBUGGING_INFO case.
>>
>> OK
On 06/12/2015 07:41 AM, Richard Biener wrote:
On June 12, 2015 2:30:36 AM GMT+02:00, David Edelsohn wrote:
This patch broke AIX bootstrap because dbxout.c was not updated for
the XCOFF_DEBUGGING_INFO case.
OK.
Thanks
Richard.
By the way, I think we should apply this fix to the GCC 5 branch
On 06/12/2015 07:41 AM, Richard Biener wrote:
On June 12, 2015 2:30:36 AM GMT+02:00, David Edelsohn wrote:
This patch broke AIX bootstrap because dbxout.c was not updated for
the XCOFF_DEBUGGING_INFO case.
OK.
Thanks
Richard.
Sorry about that and thank you for the fix!
--
Pierre-Marie de R
On June 12, 2015 2:30:36 AM GMT+02:00, David Edelsohn wrote:
>This patch broke AIX bootstrap because dbxout.c was not updated for
>the XCOFF_DEBUGGING_INFO case.
OK.
Thanks
Richard.
>- David
>
>* dbxout.c (xcoff_debug_hooks): Provide a function for
>register_main_translation_unit hook.
>
>Index:
This patch broke AIX bootstrap because dbxout.c was not updated for
the XCOFF_DEBUGGING_INFO case.
- David
* dbxout.c (xcoff_debug_hooks): Provide a function for
register_main_translation_unit hook.
Index: dbxout.c
===
--- dbxout.c
On 06/11/2015 11:21 AM, Richard Biener wrote:
That sounds perfect: thank you Richard! I am about to commit the original fix
on mainline: should I still open a bugreport before commiting it to the GCC 5
branch?
Yes please.
For the record, as you already noticed, I opened PR debug/66503.
Origi
On Thu, 11 Jun 2015, Pierre-Marie de Rodat wrote:
> On 06/11/2015 11:06 AM, Richard Biener wrote:
> > FYI, I decided to backport the fix causing this regression to the
> > 4.8 branch today, guarded with in_lto_p, thus eliminating the effect
> > on non-LTO links. The adjusted patch looks like the
On 06/11/2015 11:06 AM, Richard Biener wrote:
FYI, I decided to backport the fix causing this regression to the
4.8 branch today, guarded with in_lto_p, thus eliminating the effect
on non-LTO links. The adjusted patch looks like the following and
I'll also adjust the 4.9 branch accordingly, leav
On Wed, 10 Jun 2015, Pierre-Marie de Rodat wrote:
> On 06/10/2015 03:36 PM, Richard Biener wrote:
> > Hmm, yes. It meant to break after the first ;) (without LTO
> > there usually is only one TU decl, apart from Java I think).
> > The hunk isn't in mainline because it was part of an experimental
On Wed, 10 Jun 2015, Pierre-Marie de Rodat wrote:
> On 06/10/2015 03:36 PM, Richard Biener wrote:
> > Hmm, yes. It meant to break after the first ;) (without LTO
> > there usually is only one TU decl, apart from Java I think).
> > The hunk isn't in mainline because it was part of an experimental
On 06/10/2015 03:36 PM, Richard Biener wrote:
Hmm, yes. It meant to break after the first ;) (without LTO
there usually is only one TU decl, apart from Java I think).
The hunk isn't in mainline because it was part of an experimental patch I
did on the early-debug branch.
Understood, thanks!
On Wed, 10 Jun 2015, Pierre-Marie de Rodat wrote:
> Thank you for your answer, Richard!
>
> On 06/10/2015 08:58 AM, Richard Biener wrote:
> > Hmm, so the underlying issue is that we don't associate comp_unit_die ()
> > with any TRANSLATION_UNIT_DECL.
>
> Indeed.
>
> > For the LTO early debug wo
Thank you for your answer, Richard!
On 06/10/2015 08:58 AM, Richard Biener wrote:
Hmm, so the underlying issue is that we don't associate comp_unit_die ()
with any TRANSLATION_UNIT_DECL.
Indeed.
For the LTO early debug work I did the following at the very
beginning of dwarf2out_early_finish:
On Tue, 9 Jun 2015, Pierre-Marie de Rodat wrote:
> Hello,
>
> With the recent work for PR debug/65549, we observed a regression in the
> generated debugging information. Take the attached reproducer, build it and
> look at the output DWARF:
>
> $ gcc -c -O1 -g foo.c
> $ objdump --dwarf
Hello,
With the recent work for PR debug/65549, we observed a regression in the
generated debugging information. Take the attached reproducer, build it
and look at the output DWARF:
$ gcc -c -O1 -g foo.c
$ objdump --dwarf=info foo.o
[...]
<2><4e>: Abbrev Number: 3 (DW_TAG
16 matches
Mail list logo
