Hi,
The testcases are copies of corresponding moveable.cc tests, just
using the new class inheriting from std::basic_string resp.
std::basic_string and with -fno-inline.
Is that ok?
Minor nit: no 2010 among the Copyright years.
Paolo.
> Here is updated patch with testcases, tested with unpatched libstdc++
> where it failed to link and patched where it succeeded.
> The testcases are copies of corresponding moveable.cc tests, just
> using the new class inheriting from std::basic_string resp.
> std::basic_string and with -fno-inli
On Tue, Mar 22, 2011 at 03:26:21PM +0100, Benjamin Kosnik wrote:
>
> Thanks for reporting this issue Adam. Don't hesitate to file bug
> reports in gcc bugzilla category libstdc++ when you find problems like
> this in the future!
>
> > So, if Benjamin or other libstdc++ maintainers want it fixed f
Thanks for reporting this issue Adam. Don't hesitate to file bug
reports in gcc bugzilla category libstdc++ when you find problems like
this in the future!
> So, if Benjamin or other libstdc++ maintainers want it fixed for
> 4.6, you want a patch like attached, plus some testcases for both
> std:
On Tue, March 22, 2011 1:39 pm, Jakub Jelinek wrote:
> On Tue, Mar 22, 2011 at 01:10:14PM -, Adam Butcher wrote:
>> After a bit of poking around with nm in various objects I determined
>> that the baseline_symbols files define what should be exported. The
>> following grep+sed combo adds the n
Il 22/03/11 15.10, Jakub Jelinek ha scritto:
i.e. from ctors only the complete ctors and not the base ctors.
Probably the testcases use only complete ctors...
And I couldn't find other cases in gnu.ver that would only
export the complete ctor and not the base ctor at the same time,
these two were
On Tue, Mar 22, 2011 at 02:52:47PM +0100, Paolo Carlini wrote:
> >So, if Benjamin or other libstdc++ maintainers want it fixed for
> >4.6, you want a patch like attached, plus some testcases for both
> >std::string and std::wstring.
> Jakub, such a patch would be ok with me, if isn't too late, but,
Il 22/03/11 14.52, Paolo Carlini ha scritto:
Jakub, such a patch would be ok with me, if isn't too late, but,
frankly I don't see why we are not seeing the issue in the existing
cons/char/moveable.cc, maybe it's something sensitive to inlining
decisions (yes a testcase is welcome!), and then if
Hi,
On Tue, Mar 22, 2011 at 01:10:14PM -, Adam Butcher wrote:
After a bit of poking around with nm in various objects I determined
that the baseline_symbols files define what should be exported. The
following grep+sed combo adds the necessary export for any architecture
that exports the C1
Hi,
After a bit of poking around with nm in various objects I determined
that the baseline_symbols files define what should be exported. The
following grep+sed combo adds the necessary export for any architecture
that exports the C1 constructor symbol.
grep _ZNSsC1EOSs libstdc++-v3/config/ab
On Tue, Mar 22, 2011 at 01:10:14PM -, Adam Butcher wrote:
> After a bit of poking around with nm in various objects I determined
> that the baseline_symbols files define what should be exported. The
> following grep+sed combo adds the necessary export for any architecture
> that exports the C1
Hi,
I found that with the latest GCC 4.6.0 release candidate, dynamically
linking against libstdc++ fails for client code that expects to move an
object derived from std::string. The move constructor (either
explicitly specified or compiler generated) of such a class fails to
link in the std::str
12 matches
Mail list logo
