On Wed, Aug 20, 2014 at 6:18 PM, Jan Hubicka wrote:
>> On August 18, 2014 8:46:00 PM CEST, Jan Hubicka wrote:
>> >>
>> >> The following seems to fix it. In testing now.
>> >
>> >Will streaming as non-reference prevent DECL from being merged and
>> >tails of BLOCK_VAR chains
>> >to be corrupted?
> On August 18, 2014 8:46:00 PM CEST, Jan Hubicka wrote:
> >>
> >> The following seems to fix it. In testing now.
> >
> >Will streaming as non-reference prevent DECL from being merged and
> >tails of BLOCK_VAR chains
> >to be corrupted?
>
> Yes, the decl ends up in the function section then, no
On Mon, Aug 18, 2014 at 11:26 PM, Aldy Hernandez wrote:
> On 08/18/14 07:31, Richard Biener wrote:
>>
>> On Mon, Aug 18, 2014 at 12:46 PM, Richard Biener
>> wrote:
>>>
>>> On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
>
>
>>> For the rest them on the floor instead of ICEing in dwa
On 08/18/14 07:31, Richard Biener wrote:
On Mon, Aug 18, 2014 at 12:46 PM, Richard Biener
wrote:
On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
For the rest them on the floor instead of ICEing in dwarf2out.c. */
Should that read "For the rest, drop them on the floor..."???
On August 18, 2014 8:46:00 PM CEST, Jan Hubicka wrote:
>>
>> The following seems to fix it. In testing now.
>
>Will streaming as non-reference prevent DECL from being merged and
>tails of BLOCK_VAR chains
>to be corrupted?
Yes, the decl ends up in the function section then, not the global types
>
> The following seems to fix it. In testing now.
Will streaming as non-reference prevent DECL from being merged and tails of
BLOCK_VAR chains
to be corrupted?
Honza
>
> Richard.
>
> > Richard.
> >
> >> Thanks.
> >> Aldy
On Mon, Aug 18, 2014 at 12:46 PM, Richard Biener
wrote:
> On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
>> So... I've been getting my feet wet with LTO and debugging and I noticed a
>> seemingly unrelated yet annoying problem. On x86-64,
>> gcc.dg/guality/pr48437.c fails when run in LTO
On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
> So... I've been getting my feet wet with LTO and debugging and I noticed a
> seemingly unrelated yet annoying problem. On x86-64,
> gcc.dg/guality/pr48437.c fails when run in LTO mode.
>
> I've compared the dwarf output with and without LTO
> On Fri, Aug 15, 2014 at 10:08:38PM +0200, Steven Bosscher wrote:
> > On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
> > > So... I've been getting my feet wet with LTO and debugging and I noticed a
> > > seemingly unrelated yet annoying problem. On x86-64,
> > > gcc.dg/guality/pr48437.c f
> So... I've been getting my feet wet with LTO and debugging and I
> noticed a seemingly unrelated yet annoying problem. On x86-64,
> gcc.dg/guality/pr48437.c fails when run in LTO mode.
>
> I've compared the dwarf output with and without LTO, and I noticed
> that the DW_TAG_lexical_block is miss
On Fri, Aug 15, 2014 at 10:08:38PM +0200, Steven Bosscher wrote:
> On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
> > So... I've been getting my feet wet with LTO and debugging and I noticed a
> > seemingly unrelated yet annoying problem. On x86-64,
> > gcc.dg/guality/pr48437.c fails when
Isn't the only real solution: to generate this kind of DIEs earlier
(maybe already immediately after parsing) and stream them?
Ultimately yes, and that's what I hope to work on, but I was mostly
curious because at stream out time, the information *is* there, and we
silently dropped it.
Ald
On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
> So... I've been getting my feet wet with LTO and debugging and I noticed a
> seemingly unrelated yet annoying problem. On x86-64,
> gcc.dg/guality/pr48437.c fails when run in LTO mode.
Eh, sorry I can't actually answer your question but, e
So... I've been getting my feet wet with LTO and debugging and I noticed
a seemingly unrelated yet annoying problem. On x86-64,
gcc.dg/guality/pr48437.c fails when run in LTO mode.
I've compared the dwarf output with and without LTO, and I noticed that
the DW_TAG_lexical_block is missing from
14 matches
Mail list logo
