Hi,
today I'm seeing an ABI check failure in mainline, x86_64-linux, 11
incompatible symbols: my preliminary analysis shows that the problem is
the recurring one, simple, but annoying: some small functions are not
inlined anymore, thus inadvertently exported (with an old version
number, because of
On Wed, Oct 7, 2009 at 12:24 PM, Paolo Carlini wrote:
> Hi,
>
> today I'm seeing an ABI check failure in mainline, x86_64-linux, 11
> incompatible symbols: my preliminary analysis shows that the problem is
> the recurring one, simple, but annoying: some small functions are not
> inlined anymore, t
Richard Guenther wrote:
> Yes.
>
Thanks ;) I'm going to tighten the patterns asap, cannot hurt. For the
record, on testresults there are no big traces of this issue, this is
puzzling, no idea why some people do not reproduce my problems...
Paolo.
> > 2
> > _ZNKSt8ios_base6getlocEv
> > std::ios_base::getloc() const
> > version status: incompatible
> > GLIBCXX_3.4
> > type: function
> > status: added
> >
> > Are there very recent inlining changes?
>
> Yes.
This might be patch I commited today morning. It would help if you
could just send m
Hi Honza,
>>> 2
>>> _ZNKSt8ios_base6getlocEv
>>> std::ios_base::getloc() const
>>> version status: incompatible
>>> GLIBCXX_3.4
>>> type: function
>>> status: added
>>>
>>> Are there very recent inlining changes?
>>>
>> Yes.
>>
> This might be patch I commited today morning. It would h
> Anyway, as regards *which* specific functions are not inlined, I would
> say all the functions which break the ABI test as newly exported symbols
> should be checked, like the above, 'std::ios_base::getloc() const'. I'm
> attaching below a complete list, from my libstdc++.log, but I would
> guess
On Wed, Oct 7, 2009 at 2:33 PM, Jan Hubicka wrote:
>> Anyway, as regards *which* specific functions are not inlined, I would
>> say all the functions which break the ABI test as newly exported symbols
>> should be checked, like the above, 'std::ios_base::getloc() const'. I'm
>> attaching below a c
> Btw, that new comdat behavior is very well reasonable. In
> whole-program mode it should be the old one though.
It is another effect of the patch that in whole-program we bring all
comdat functions static except for those having address taken (so the
address must be same from all modules)
I was
Richard, Jan,
I'm confused. Consider this symbol:
W
_ZN9__gnu_cxx8__detail9__find_ifIPSt4pairIPNS_16bitmap_allocatorIcE12_Alloc_blockES6_ENS0_12_Functor_RefINS0_12_Ffit_finderIS6_EET_SD_SD_T0_
version status: incompatible
GLIBCXX_3.4
type: function
status: added
I went multi
> Richard, Jan,
>
> I'm confused. Consider this symbol:
>
> W
> _ZN9__gnu_cxx8__detail9__find_ifIPSt4pairIPNS_16bitmap_allocatorIcE12_Alloc_blockES6_ENS0_12_Functor_RefINS0_12_Ffit_finderIS6_EET_SD_SD_T0_
> version status: incompatible
> GLIBCXX_3.4
> type: function
> status:
Hi Honza,
> There was bug causing some of abstract (unspecialized) methods to be
> mistakely output. I fixed it this morning, perhaps this is occurence of
> this problem?
>
Thanks for the hint, but I don't think it's that. The regression tester
results are just out for Revision: 152556 and the
Paolo Carlini wrote:
> Really, I have no idea what the heck is going on with those 4 symbols
> (probably the other are simpler), I cannot find where the first linker
> script part, for baseline (GLIBCXX_3.4), lets them through... This issue
> is making me crazy, it even persists if I change that fr
12 matches
Mail list logo
