Jan Hubicka writes:
> The problem is that GCC produce constructors/destructors at various places
> and they all used to be called GLOBAL__I
> and GLOBAL__D. Then in some cases (on targets that don't have global
> ctors/dtors or with LTO and ctor/dtor merging)
> it actually collect them into si
> I don't understand this at all.
>
> I thought you were saying that these are static functions, and that gcc
> gathers them all together into a single global constructor. Are there
> cases where gcc does not gather them together? Why would that be?
At the moment we don't gather when there is o
Jan Hubicka writes:
> 2) Do the actual renaming of _GLOBAL__I into something else (fully local
> name like static_ctor.1234 at a time it is being inserted
> into merged ctor.
>
> We can't avoid producing these names early since on target that havecdtors
> we avoid producing merged c
> Jan Hubicka writes:
>
> > The problem is that GCC produce constructors/destructors at various places
> > and they all used to be called GLOBAL__I
> > and GLOBAL__D. Then in some cases (on targets that don't have global
> > ctors/dtors or with LTO and ctor/dtor merging)
> > it actually collec
Jan Hubicka writes:
>> Jan Hubicka writes:
>>
>> > I think bootstrap with C++ or GO is broken for a while on targets not
>> > having ctor support, but now it broke
>> > on targets with ctor support as a result of my patch renaming some of the
>> > ctors from GLOBAL__I into GLOBAL__sub_I.
>>
> Now if this breaks other logic in ld & friends on have_cdtor targets, I guess
> we could
0) return to always inlining on non_have_cdtors targets and hope for the
best :)
> 1) du _sub_I/sub_D mangling only on targets not having ctors/dtors where
> merged constructor is always produced
>
> > Jan Hubicka writes:
> >
> > > I think bootstrap with C++ or GO is broken for a while on targets not
> > > having ctor support, but now it broke
> > > on targets with ctor support as a result of my patch renaming some of the
> > > ctors from GLOBAL__I into GLOBAL__sub_I.
> >
> > I didn't kn
> Jan Hubicka writes:
>
> > I think bootstrap with C++ or GO is broken for a while on targets not
> > having ctor support, but now it broke
> > on targets with ctor support as a result of my patch renaming some of the
> > ctors from GLOBAL__I into GLOBAL__sub_I.
>
> I didn't know you were maki
Jan Hubicka writes:
> I think bootstrap with C++ or GO is broken for a while on targets not having
> ctor support, but now it broke
> on targets with ctor support as a result of my patch renaming some of the
> ctors from GLOBAL__I into GLOBAL__sub_I.
I didn't know you were making that change.
On Wed, 2010-12-15 at 13:57 +0100, Jan Hubicka wrote:
> Hi,
> the problem is that we special case constructors and avoid random seed on
> them on targets that have global ctors.
> I think bootstrap with C++ or GO is broken for a while on targets not having
> ctor support, but now it broke
> on ta
Hi,
the problem is that we special case constructors and avoid random seed on them
on targets that have global ctors.
I think bootstrap with C++ or GO is broken for a while on targets not having
ctor support, but now it broke
on targets with ctor support as a result of my patch renaming some of t
> -696
> .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_14146711
> 00b6 00011580 2**4
> +696
> .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_EB7C2B89
> 00b6
I believe, something broke the trunk tip build recently:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/wlocale-inst.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/s
13 matches
Mail list logo
