t;> This is to switch to the alternate LTO file (this process already exists
>>> for the actual LTO output)
>>
>> It took me a while to realize that you're talking about darwin here,
>> specifically the lto_start/end hooks.
>>
>>> before the earl
O output)
>
> It took me a while to realize that you're talking about darwin here,
> specifically the lto_start/end hooks.
>
> > before the early debug is started and switch back to the regular output
> > file after. Therefore both the LTO early debug and the LTO streamed data
>
early debug is started and switch back to the regular output file
> after. Therefore both the LTO early debug and the LTO streamed data end up
> in a separate file (this can be concatenated as we do now, guaranteeing that
> it appears after any referenced symbols, or could be handled in
ents on the central idea.
>
> This is to switch to the alternate LTO file (this process already exists for
> the actual LTO output) before the early debug is started and switch back to
> the regular output file after. Therefore both the LTO early debug and the
> LTO streamed data
exists for
the actual LTO output) before the early debug is started and switch back to the
regular output file after. Therefore both the LTO early debug and the LTO
streamed data end up in a separate file (this can be concatenated as we do now,
guaranteeing that it appears after any referenced
The following patch ontop of early LTO debug patches get us back to
LTO bootstrap (see also the DW_OP_GNU_variable_value fixes / tweaks mail).
With early LTO debug we have to resolve DW_OP_GNU_variable_value early
as we are going to output the DIEs early. The following patch always
does that con
The following makes sure the BLOCK_SUPERCONTEXT of DECL_INITIAL (decl)
is decl itself (I won't commit the assert in cfgexpand.c but
bootstrap/test passed with it). It also marks yet another global
initializer with DECL_IGNORED_P, in this case as it is emitted very
late after early debug is finis
On 2015.09.01 at 13:15 +0200, Jan Hubicka wrote:
> > > And it breaks quickly during Firefox build, e.g.:
> > >
> > > trippels@gcc2-power8 angle % cat glslang_lex.ii
> > > struct A;
> > > template class B {
> > > typedef A value_type;
> > > void m_fn1(const value_type &);
> > > };
> > > struct
> > And it breaks quickly during Firefox build, e.g.:
> >
> > trippels@gcc2-power8 angle % cat glslang_lex.ii
> > struct A;
> > template class B {
> > typedef A value_type;
> > void m_fn1(const value_type &);
> > };
> > struct A {
> > int staticUse;
> > B<> fields;
> > };
> >
> > trippels@
On Tue, 1 Sep 2015, Markus Trippelsdorf wrote:
> On 2015.09.01 at 10:00 +0200, Richard Biener wrote:
> > On Mon, 31 Aug 2015, Markus Trippelsdorf wrote:
> >
> > > On 2015.08.31 at 16:44 +0200, Richard Biener wrote:
> > > >
> > > > So the state below now will pass LTO bootstrap (fingers crossing,
On 2015.09.01 at 10:00 +0200, Richard Biener wrote:
> On Mon, 31 Aug 2015, Markus Trippelsdorf wrote:
>
> > On 2015.08.31 at 16:44 +0200, Richard Biener wrote:
> > >
> > > So the state below now will pass LTO bootstrap (fingers crossing,
> > > stage3 running) as well as regular bootstrap. Iff I
On Mon, 31 Aug 2015, Markus Trippelsdorf wrote:
> On 2015.08.31 at 16:44 +0200, Richard Biener wrote:
> >
> > So the state below now will pass LTO bootstrap (fingers crossing,
> > stage3 running) as well as regular bootstrap. Iff I didn't break
> > sth in the last minute. You need up-to-date tr
On 2015.08.31 at 16:44 +0200, Richard Biener wrote:
>
> So the state below now will pass LTO bootstrap (fingers crossing,
> stage3 running) as well as regular bootstrap. Iff I didn't break
> sth in the last minute. You need up-to-date trunk (watch out,
> fortran seems to be broken) to pull the f
On Fri, 28 Aug 2015, Richard Biener wrote:
>
> The following fixes
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00af8edd in lto_get_decl_name_mapping (decl_data=0x0,
> name=0x768dcbd0 "bar")
> at /space/rguenther/src/svn/trunk/gcc/lto-section-in.c:349
> 349
The following fixes
Program received signal SIGSEGV, Segmentation fault.
0x00af8edd in lto_get_decl_name_mapping (decl_data=0x0,
name=0x768dcbd0 "bar")
at /space/rguenther/src/svn/trunk/gcc/lto-section-in.c:349
349 htab_t renaming_hash_table = decl_data->renaming_hash_t
The LTO early debug info prototype project has been completed.
The provided patch against the debug-early branch shows that the
general idea is sound and works. Now on to the details.
What works?
---
Simple C and C++ testcases (didn't test more), esp. now libstdc++
pretty-pri
On April 14, 2015 6:27:14 PM GMT+02:00, Aldy Hernandez wrote:
>On 04/14/2015 06:35 AM, Richard Biener wrote:
>
>Richard, thank you so much for working on this. It's good to see your
>progress here.
>
>> the late dwarf generation is a bit awkward because it insists on
>creating
>> type DIEs for a
On 04/14/2015 06:35 AM, Richard Biener wrote:
Richard, thank you so much for working on this. It's good to see your
progress here.
the late dwarf generation is a bit awkward because it insists on creating
type DIEs for all sort of contexts when we process scope vars. The type
Types should
So I've been successful with funneling
class X { public: X(int r) : res(r) {} int get() { return res; }
private: int res; };
int main() { X x(0); return x.get (); }
all the way through LTO and gdb recognizing all the nice early debug info
for X:
> gdb ./a.out
(gdb) start
Temporary breakpoint 1 a
Hi,
this is a short progress report (with a current patch ontop of the
debug-early branch attached).
So I worked towards making regular non-LTO mode output DWARF in two stages,
early (before .text) and late (after .text). I've also prototyped the
LTO side (BLOCK support
still missing) to show wh
20 matches
Mail list logo
