On 9/23/13 9:24 AM, Paolo Carlini wrote:
Does this look right?
Yes. Nit, in the comment I would also explicitly mention locale-inst.cc.
Done, submitted as r202836.
2013-09-23 Paul Pluzhnikov
* src/c++11/snprintf_lite.cc (__concat_size_t): Use
unsigned long long conditiona
Hi,
On 9/23/13 11:02 AM, Paul Pluzhnikov wrote:
On 9/23/13 7:54 AM, Paolo Carlini wrote:
Testing this patch:
In fact, however, that unsigned long long instantiation isn't
*unconditionally* available, see locale-inst.cc.
Thanks,
I think we have to use
unsigned long as a fall back controlle
On 9/23/13 7:54 AM, Paolo Carlini wrote:
Testing this patch:
In fact, however, that unsigned long long instantiation isn't
*unconditionally* available, see locale-inst.cc.
Thanks,
I think we have to use
unsigned long as a fall back controlled by the same macro. And please
add a comment expl
On 9/23/13 7:48 AM, Paul Pluzhnikov wrote:
Testing this patch:
libstdc++ tests finished with
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}'
Committed as r202832.
Sorry about the trouble.
--
2013-09-23 Paul Pluzhnikov
* src/c++11/snprintf_lite.cc (__concat_size_t): Use only
Hi,
On 9/23/13 9:48 AM, Paul Pluzhnikov wrote:
On 9/23/13 4:26 AM, Paolo Carlini wrote:
m68k-linux/./libstdc++-v3/src/.libs/libstdc++.so: undefined reference
to `int std::__int_to_char(char*, unsigned int,
char const*, std::_Ios_Fmtflags, bool)'
Reproduced on i686.
Sorry about the trouble ..
On 9/23/13 4:26 AM, Paolo Carlini wrote:
m68k-linux/./libstdc++-v3/src/.libs/libstdc++.so: undefined reference
to `int std::__int_to_char(char*, unsigned int,
char const*, std::_Ios_Fmtflags, bool)'
Reproduced on i686.
Sorry about the trouble ...
I would say, either make sure to use only tho
On 9/23/13 8:22 AM, Andreas Schwab wrote:
Paolo Carlini writes:
Hi
Andreas Schwab ha scritto:
What's wrong with always adding the instantiation?
That quite a few targets will not use it and will remain dead in the .so?
How many uses are there for the unsigned long version?
I would say *a
On Mon, Sep 23, 2013 at 03:55:26PM +0200, Marc Glisse wrote:
> On Mon, 23 Sep 2013, Paolo Carlini wrote:
>
> >>There are a lot of targets using unsigned int for size_t, which would
> >>have been uncovered by proper testing.
>
> We can't test all patches on 3-4 different targets... It wasn't
> obv
On Mon, 23 Sep 2013, Paolo Carlini wrote:
There are a lot of targets using unsigned int for size_t, which would
have been uncovered by proper testing.
We can't test all patches on 3-4 different targets... It wasn't obvious
this patch could be that sensitive to the target.
That's true, just
Paolo Carlini writes:
> Hi
>
> Andreas Schwab ha scritto:
>
>>What's wrong with always adding the instantiation?
>
> That quite a few targets will not use it and will remain dead in the .so?
How many uses are there for the unsigned long version?
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@
Hi
Andreas Schwab ha scritto:
>What's wrong with always adding the instantiation?
That quite a few targets will not use it and will remain dead in the .so? But I
agree that it's an option, that you can also pursue immediately if you like,
also preapproved (I'm traveling, either you or Paul
Paolo Carlini writes:
> Paul, the *.cc are built with implicit instantiations disabled and we are
> missing explicit instantiations of this function template. If I remember
> correctly, we normally instantiate it in locale-inst.cc only for unsigned
> long and unsigned long long as second template
On Mon, Sep 23, 2013 at 1:26 PM, Paolo Carlini wrote:
> Hi,
>
> thanks Andreas.
>
>
> On 9/23/13 3:53 AM, Andreas Schwab wrote:
>>
>> Paul Pluzhnikov writes:
>>
>>> Index: libstdc++-v3/src/c++11/snprintf_lite.cc
>>> ===
>>> --- libst
Hi,
thanks Andreas.
On 9/23/13 3:53 AM, Andreas Schwab wrote:
Paul Pluzhnikov writes:
Index: libstdc++-v3/src/c++11/snprintf_lite.cc
===
--- libstdc++-v3/src/c++11/snprintf_lite.cc (revision 0)
+++ libstdc++-v3/src/c++11/snp
Paul Pluzhnikov writes:
> Index: libstdc++-v3/src/c++11/snprintf_lite.cc
> ===
> --- libstdc++-v3/src/c++11/snprintf_lite.cc (revision 0)
> +++ libstdc++-v3/src/c++11/snprintf_lite.cc (revision 0)
> @@ -0,0 +1,152 @@
> +// Debugg
On Wed, Sep 18, 2013 at 3:00 PM, Paolo Carlini wrote:
> In the meanwhile, since you are also touching debug-mode and
> profile-mode, make sure to run check-debug and check-profile too.
Thanks for mentioning that. Several more tests needed line number
adjustments.
There are also tests that are f
Hi,
> Il giorno 18/set/2013, alle ore 21:38, Paul Pluzhnikov
> ha scritto:
>
>> On Fri, Sep 13, 2013 at 3:02 AM, Paolo Carlini
>> wrote:
>>
>> - The game with the variadic and the non-variadic __throw_out_of_range makes
>> me a little nervous. Let's just name the new one differently, like
>>
On Fri, Sep 13, 2013 at 3:02 AM, Paolo Carlini wrote:
> - The game with the variadic and the non-variadic __throw_out_of_range makes
> me a little nervous. Let's just name the new one differently, like
> __throw_out_of_range_var.
Replaced with __throw_out_of_range_fmt.
> - Please consistently u
Hi,
On 09/13/2013 02:01 AM, Paul Pluzhnikov wrote:
On Wed, Sep 4, 2013 at 9:55 PM, Daniel Krügler
wrote:
Did you mean "pessimises code size", or something else?
Yes.
Daniel's idea proved a good one, and I now have a patch that I am
happy with, and that will be easy to extend to string::at()
On Wed, Sep 4, 2013 at 9:55 PM, Daniel Krügler
wrote:
>> Did you mean "pessimises code size", or something else?
>
> Yes.
Daniel's idea proved a good one, and I now have a patch that I am
happy with, and that will be easy to extend to string::at(), and other
__throw_... functions.
I've added th
2013/9/5 Paul Pluzhnikov :
> On Wed, Sep 4, 2013 at 2:10 PM, Daniel Krügler
> wrote:
>
>> I expect that this kind of index violation is a rather often occurring
>> pattern and should be isolated. IMO the _M_range
>> _check now pessimisms the normal, non-violating case.
>
> Did you mean "pessimises
Hi,
On 09/05/2013 01:36 AM, Paul Pluzhnikov wrote:
On Wed, Sep 4, 2013 at 4:26 PM, Paolo Carlini wrote:
For sure concat_size would not be Ok, isn't uglified.
I didn't uglify it because it's inside __gnu_cxx namespace.
Does it still need uglification?
Yes.
snprintf_lite(__s, sizeof(__
On Wed, Sep 4, 2013 at 4:26 PM, Paolo Carlini wrote:
> For sure concat_size would not be Ok, isn't uglified.
I didn't uglify it because it's inside __gnu_cxx namespace.
Does it still need uglification?
>>snprintf_lite(__s, sizeof(__s),
>> _N("vector::_M_range_check: __n (wh
Hi,
On 09/04/2013 10:53 PM, Paul Pluzhnikov wrote:
I am not at all sure the names I choose here are good ones. Suggestions
welcome.
For sure concat_size would not be Ok, isn't uglified. Thanks for the
code, you understand isn't really something we can imagine committing.
I also shudder at the
On Wed, Sep 4, 2013 at 2:10 PM, Daniel Krügler
wrote:
> I expect that this kind of index violation is a rather often occurring
> pattern and should be isolated. IMO the _M_range
> _check now pessimisms the normal, non-violating case.
Did you mean "pessimises code size", or something else?
> Wh
2013/9/4 Paul Pluzhnikov :
> Greetings,
>
> This is a followup to:
> http://gcc.gnu.org/ml/libstdc++/2013-08/msg00096.html
>
> Without this patch, the user on vector::at out of bounds sees:
>
> terminate called after throwing an instance of 'std::out_of_range'
> what(): vector::_M_range_check
>
26 matches
Mail list logo