On 04/15/13 09:35, Jim Jagielski wrote:
Just a quick Email... the list has been pretty quiet
lately and just pinging to see who's still watching
and reading :)
Still here.
() followed by wstring::compare(), but it would
make sense to confirm the hypothesis before implementing the
optimization.
Alright, same files, two more patches.
2012-10-28 Liviu Nicoara lnico...@apache.org
Fixes to collate facet and test enhancements:
* src/collate.cpp (__rw_strnxfrm
On 10/26/12 18:50, Martin Sebor wrote:
On 10/26/2012 06:50 AM, Liviu Nicoara wrote:
[...]
tl;dr: removing the facet data cache is a priority. All else can be put
on the back-burner.
[...]
// facet data accessor
...
if (0 == _C_impsize) { // 1
mutex_lock ();
if (_C_impsize
On 10/03/12 11:10, Martin Sebor wrote:
[...]
I was just thinking of a few simple loops along the lines of:
void* thread_func (void*) {
for (int i = 0; i N; ++)
test 1: do some simple stuff inline
test 2: call a virtual function to do the same stuff
On 10/03/12 11:10, Martin Sebor wrote:
[...]
I was just thinking of a few simple loops along the lines of:
tl;dr: I consider the results of the multi-threaded performance tests (12S,
Intel/AMD multicores) as coming from heavy contention in copying of
reference-counted std::string objects.
On 10/21/12 19:08, Martin Sebor wrote:
There's no requirement that embedded NULs must be preserved
(that's just how it happens to be implemented). I find it best
to avoid relying on the knowledge of implementation details
when exercising the library so that tests don't start failing
after a
Hi all,
I ran the attached test case, s.cpp, and timed it:
* Deep copy
$ for f in 16 8 6 4 2 1; do time ./s $f 1; done
16 0m39.292s 2m34.381s 0m0.035s
8 0m20.573s 1m18.131s 0m0.025s
6 0m15.037s 0m58.269s 0m0.009s
4 0m9.973s
On 10/21/12 21:11, Liviu Nicoara wrote:
Hi all,
I ran the attached test case, s.cpp, and timed it:
Gosh darn it, attached the wrong files. Here are the right ones.
Liviu
* Deep-copy
$ for f in 16 8 6 4 2 1; do time ./s $f 1; done
16 0m39.292s 2m34.381s 0m0.035s
8
On 10/21/12 21:44, Liviu Nicoara wrote:
On 10/21/12 21:11, Liviu Nicoara wrote:
Hi all,
I ran the attached test case, s.cpp, and timed it:
Gosh darn it, attached the wrong files. Here are the right ones.
Made the same mistake twice. My apologies for the clutter. Here are the
right ones
On 10/18/12 10:49, Martin Sebor wrote:
On 10/16/2012 10:45 AM, Liviu Nicoara wrote:
Are there any performance tests (and measurements) of STDCXX features
against similar features in libc?
I don't think so. A long time ago I benchmarked stdcxx iostreams
and stdio on a variety of operating
On 10/18/12 11:02, Martin Sebor wrote:
On 10/16/2012 10:38 AM, Liviu Nicoara wrote:
I have enhanced the collation test, 22.locale.collate.cpp with a bunch
of cases that deal with embedded strings, inside the input strings as
well as at the edges. More defects became apparent, and they have been
.
All collation tests (old and new) pass. If there are no objections, I
will check it in later in the week.
Thanks,
Liviu
On 10/13/12 11:16, Liviu Nicoara wrote:
The initial patch does not pass the following test case. Have re-worked
the patch and attached it to the incident, and I am also
Are there any performance tests (and measurements) of STDCXX features
against similar features in libc?
Thanks,
Liviu
On 10/10/12 07:40, Liviu Nicoara wrote:
The following patch cleans up most of the failures seen in the collation
test. It does not fix the transform failures and libstd tests.
2012-10-10 Liviu Nicoara lnico...@apache.org
Various fixes:
* tests/localization/22.locale.collate.cpp
);
size_t i = 0;
for (; i s.size () 0 == s [i]; ++i) ;
return !(i == 2);
}
1
On 10/10/12 08:25, Liviu Nicoara wrote:
2012-10-10 Liviu Nicoara lnico...@apache.org
* src/collate.cpp (__rw_strnxfrm): preserved embedded NULs
Index: src/collate.cpp
] 140 %
I also tested with POSIX mutexes and saw the same behavior.
Travis
From: Liviu Nicoara
Sent: Thursday, October 11, 2012 5:28 AM
To: dev@stdcxx.apache.org
Subject: Re: [PATCH] Re: STDCXX-1072 SPARC V8 mutex alignment requirements
I applied the patch on 4.2.x. If someone with access
On 10/04/12 22:41, Liviu Nicoara wrote:
On 10/4/12 10:10 PM, Liviu Nicoara wrote:
On 10/3/12 11:10 AM, Martin Sebor wrote:
On 10/03/2012 07:01 AM, Liviu Nicoara wrote:
void* thread_func (void*) {
for (int i = 0; i N; ++)
test 1: do some simple stuff inline
I applied the patch on 4.2.x. If someone with access to a SPARC machine
could give it a runall and post the results here it would be awesome. I
will postpone closing the incident until then.
Thanks!
Liviu
On 10/06/12 16:56, Liviu Nicoara wrote:
On 09/29/12 15:33, Liviu Nicoara wrote:
On 9
The following patch cleans up most of the failures seen in the collation
test. It does not fix the transform failures and libstd tests.
2012-10-10 Liviu Nicoara lnico...@apache.org
Various fixes:
* tests/localization/22.locale.collate.cpp: removed unused
macros, corrected
2012-10-10 Liviu Nicoara lnico...@apache.org
* src/collate.cpp (__rw_strnxfrm): preserved embedded NULs
Index: src/collate.cpp
===
--- src/collate.cpp (revision 1392832)
+++ src/collate.cpp (working copy)
@@ -547,7
On 10/3/12 11:10 AM, Martin Sebor wrote:
On 10/03/2012 07:01 AM, Liviu Nicoara wrote:
I am gathering some more measurements along these lines but it's time
consuming. I estimate I will have some ready for review later today or
tomorrow. In the meantime could you please post your kernel, glibc
On 10/4/12 10:10 PM, Liviu Nicoara wrote:
On 10/3/12 11:10 AM, Martin Sebor wrote:
On 10/03/2012 07:01 AM, Liviu Nicoara wrote:
I am gathering some more measurements along these lines but it's time
consuming. I estimate I will have some ready for review later today or
tomorrow
today or
tomorrow. In the meantime could you please post your kernel, glibc and
compiler versions?
Liviu
Martin
On 10/02/2012 06:22 AM, Liviu Nicoara wrote:
On 09/30/12 18:18, Martin Sebor wrote:
I see you did a 64-bit build while I did a 32-bit one. so
I tried 64-bits. The cached version
On 09/30/12 18:18, Martin Sebor wrote:
I see you did a 64-bit build while I did a 32-bit one. so
I tried 64-bits. The cached version (i.e., the one compiled
with -UNO_USE_NUMPUNCT_CACHE) is still about twice as fast
as the non-cached one (compiled with -DNO_USE_NUMPUNCT_CACHE).
I had made one
Forwarding with the attachment.
Original Message
Subject: Re: STDCXX-1071 numpunct facet defect
Date: Sun, 30 Sep 2012 12:09:10 -0600
From: Martin Sebor mse...@gmail.com
To: Liviu Nicoara nikko...@hates.ms
On 09/27/2012 06:36 PM, Liviu Nicoara wrote:
On 9/27/12 8:27 PM
On 9/30/12 2:21 PM, Liviu Nicoara wrote:
Forwarding with the attachment.
Original Message
Subject: Re: STDCXX-1071 numpunct facet defect
Date: Sun, 30 Sep 2012 12:09:10 -0600
From: Martin Sebor mse...@gmail.com
To: Liviu Nicoara nikko...@hates.ms
On 9/27/12 8:27 PM, Martin
Forwarding to the list. Duh.
Original Message
Subject: Re: Fwd: Re: STDCXX-1071 numpunct facet defect
Date: Sun, 30 Sep 2012 19:02:27 -0400
From: Liviu Nicoara nikko...@hates.ms
To: Martin Sebor mse...@gmail.com
On 9/30/12 6:18 PM, Martin Sebor wrote:
I see you did a 64-bit
On 9/28/12 11:32 AM, Travis Vitek wrote:
-Original Message-
From: Liviu Nicoara
Sent: Friday, September 28, 2012 5:29 AM
[...]
The patch assumes the type `long double' exists on every platform. While I do
believe that it is available everywhere, we have lots of conditional code
While checking for fallout from 1072 I stumbled upon the collate test and its
numerous (unrelated to 1072) failures. While I am looking at it I have a
question: it seems to me that the locale tests do not test against STDCXX locale
database. Is that right? So, all locale tests are supposed to
I thought I replied but I see no trace of my post:
On 09/27/12 20:27, Martin Sebor wrote:
On 09/27/2012 06:41 AM, Liviu Nicoara wrote:
On 09/26/12 20:12, Liviu Nicoara wrote:
I have created STDCXX-1071 and linked to STDCXX-1056. [...]
I am open to all questions, the more the better. Most
I have created the above and linked it to the closed STDCXX-1066.
In short, my reading about this issue is that the kernel patch changed the
alignment of the userland mutex objects from a machine word to a double-word
boundary. No changes are required of the users who use such objects in their
On 09/28/12 08:29, Liviu Nicoara wrote:
I have created the above and linked it to the closed STDCXX-1066.
[...]
IMO, the patch I attached does not break binary compatibility.
Scratch this, I haven't thought it through.
Thanks,
Liviu
On 09/28/12 08:45, Liviu Nicoara wrote:
On 09/28/12 08:29, Liviu Nicoara wrote:
I have created the above and linked it to the closed STDCXX-1066.
[...]
IMO, the patch I attached does not break binary compatibility.
Scratch this, I haven't thought it through.
Actually, after more thought, I
On 09/28/12 11:01, Travis Vitek wrote:
Only major versions can break binary. The versioning policy for stdcxx can be
found here..
http://stdcxx.apache.org/versions.html
Thanks, that clarifies things.
Liviu
On 09/28/12 11:45, Travis Vitek wrote:
Liviu,
Sorry I didn't look until just now, but it appears that I could have re-opened
STDCXX-1066. I only see the 'Reopen Issue' button for STDCXX issues, but it is
most definitely there. Perhaps there is some sort of permission issue for you?
It's ok,
On 09/28/12 11:32, Travis Vitek wrote:
-Original Message-
From: Liviu Nicoara
Sent: Friday, September 28, 2012 5:29 AM
In short, my reading about this issue is that the kernel patch changed
the alignment of the userland mutex objects from a machine word to a
double-word boundary
On 09/28/12 13:51, Martin Sebor wrote:
[...]
One other comment: I would suggest choosing subjects for bug
reports that reflect the problem rather than a fix for it or
a rationale for it. For STDCXX-1066 I think something like
Library mutex objects misaligned on SPARCV8 would better
capture the
-
From: Liviu Nicoara [mailto:nikko...@hates.ms]
Sent: Friday, September 28, 2012 3:52 AM
To: dev@stdcxx.apache.org
Subject: Re: STDCXX-1071 numpunct facet defect
I thought I replied but I see no trace of my post:
On 09/27/12 20:27, Martin Sebor wrote:
On 09/27/2012 06:41 AM, Liviu Nicoara wrote
On 09/27/12 07:15, Pavel Heimlich, a.k.a. hajma wrote:
2012/9/26 Liviu Nicoara nikko...@hates.ms:
On 09/26/12 05:49, Pavel Heimlich, a.k.a. hajma wrote:
2012/9/26 Liviu Nicoara nikko...@hates.ms:
On 9/25/12 7:56 PM, Stefan Teleman (JIRA) wrote:
[
https://issues.apache.org/jira
On 09/23/12 12:15, Liviu Nicoara wrote:
On 09/22/12 00:51, Liviu Nicoara wrote:
Optimized (but not debug) builds fail to compile setlocale.cpp with the error:
A patch and a comment have been attached to the issue.
I am posting it here to save a trip to the JIRA issue. Any feed-back
On 09/22/12 16:22, Stefan Teleman wrote:
On Sat, Sep 22, 2012 at 4:07 PM, Liviu Nicoara nikko...@hates.ms wrote:
Stefan, could you please elaborate on the misaligned reads/writes that you
observed on those platforms? What was failing?
Several tests from the test harness were failing because
On 09/26/12 20:12, Liviu Nicoara wrote:
I have created STDCXX-1071 and linked to STDCXX-1056. [...]
I am open to all questions, the more the better. Most of my opinions have been
expressed earlier, but please ask if you want to know more.
I am attaching here the proposed (4.3.x) patch
On 09/25/12 23:20, Martin Sebor wrote:
On 09/24/2012 06:38 AM, lnico...@apache.org wrote:
Author: lnicoara
Date: Mon Sep 24 12:38:17 2012
New Revision: 1389337
URL: http://svn.apache.org/viewvc?rev=1389337view=rev
Log:
2012-09-24 Liviu Nicoara nikko...@hates.ms
* tests/support
I want to reopen the closed incidents, esp. 1056. On a second thought it might
be more useful to open new ones and link the old ones so that we don't mess
with ownership, etc. If nobody objects to this I will go forward with the
latter.
Thanks.
I have created STDCXX-1071 and linked to STDCXX-1056. I have reduced the scope
to numpunct because moneypunct is not failing for me. If someone has a
moneypunct failure listing I want to see it.
I have reduced the library code to a failing test case. I have attached there
the reduced program.
On 09/24/12 22:28, Martin Sebor wrote:
On 09/20/2012 06:46 PM, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 8:39 PM, Liviu Nicoaranikko...@hates.ms wrote:
I have not created this requirement out of thin air. STDCXX development has
functioned in this manner for as long as I remember. If it
On 09/24/12 23:50, Stefan Teleman wrote:
On Mon, Sep 24, 2012 at 10:03 PM, Martin Sebor mse...@gmail.com wrote:
FWIW, there are race conditions in stdcxx. Some of them are by
design and benign on the systems the library runs on (although
I acknowledge that some others may be bugs). One such
I filed 1070, failure to build 22.locale.collate.cpp on Linux with gcc 4.7.1.
Gcc, Comeau and Clang fail to compile it, Intel and Sun are fine. It looks to
me like Intel and Sun compilers are not doing the right thing. A small test
case and a patch have been attached. The failing code has been
On 9/25/12 7:56 PM, Stefan Teleman (JIRA) wrote:
[
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan,
I don't think it's ok to close this bug. The race conditions are there and we
have not come to a
On 9/25/12 7:56 PM, Stefan Teleman (JIRA) wrote:
[
https://issues.apache.org/jira/browse/STDCXX-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anybody around here, except Stefan, who has access to a SPARC V8 machine updated
to the specified kernel update or
On 9/24/12 11:06 PM, Stefan Teleman wrote:
On Mon, Sep 24, 2012 at 7:48 PM, Liviu Nicoara nikko...@hates.ms wrote:
Stefan, was it your intention to completely eliminate all the race
conditions with this last patch? Is this what the tools showed in your
environment?
https://issues.apache.org
___
From: Liviu Nicoara
Sent: Sunday, September 23, 2012 8:34 AM
To: dev@stdcxx.apache.org
Subject: [PATCH] STDCXX-853
Umm, I didn't think to search for a corresponding incident and I considered the
defect to be so minor as to not warrant an issue. The following patch has been
applied
On 9/24/12 12:06 AM, Stefan Teleman wrote:
On Fri, Sep 21, 2012 at 9:10 AM, Liviu Nicoara nikko...@hates.ms wrote:
On 09/21/12 05:13, Stefan Teleman wrote:
On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
travis.vi...@roguewave.com wrote:
I have provided this list with test results showing
On 09/16/12 12:03, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 5:47 PM, Liviu Nicoara nikko...@hates.ms wrote:
I merely wanted to point out that restoring the default packing is not the
same as restoring the packing to the previous value in effect.
Given this, I thought about an alternative
Umm, I didn't think to search for a corresponding incident and I considered the
defect to be so minor as to not warrant an issue. The following patch has been
applied already on 4.2.x:
Index: tests/support/atomic_xchg.cpp
===
---
On 09/22/12 00:51, Liviu Nicoara wrote:
Optimized (but not debug) builds fail to compile setlocale.cpp with the error:
A patch and a comment have been attached to the issue.
Thanks,
Liviu
On 9/23/12 3:48 PM, Stefan Teleman wrote:
On Sun, Sep 23, 2012 at 3:26 PM, Liviu Nicoara nikko...@hates.ms wrote:
To be honest it's quite bizarre that you cannot share that with us. Is it
really a trade secret? How can that be the case if Oracle customers are also
required to perform the same
On 9/23/12 5:50 PM, Stefan Teleman wrote:
On Sun, Sep 23, 2012 at 5:23 PM, Stefan Teleman
stefan.tele...@gmail.com wrote:
The second URL says this:
QUOTE
Due to a change in the implementation of the userland mutexes
introduced by CR 6296770 in KU 137111-01, objects of type mutex_t and
On 9/17/12 5:42 PM, Liviu Nicoara wrote:
[...]
However, after more careful thought, I think there is a problem there even
though we don't have an objective proof for it, yet.
The writes are not atomic and they function just like DCII, being subject to
both compiler reordering and out of order
Stefan, could you please elaborate on the misaligned reads/writes that you
observed on those platforms? What was failing?
Thanks,
Liviu
On 09/21/12 05:13, Stefan Teleman wrote:
On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
travis.vi...@roguewave.com wrote:
I have provided this list with test results showing that my patch
*does* fix the race condition problems identified by all the tools at
my disposal. I'm willing to bet you
Optimized (but not debug) builds fail to compile setlocale.cpp with the error:
$ cat t.cpp; CC -c t.cpp
#define _XOPEN_SOURCE
#include cwchar
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 90: Error: tm is not defined.
/opt/sunpro/12_3/prod/include/cc/wchar.h, line 92: Error: fgetwc is not
Thanks for the feed-back. Please see below.
On Sep 19, 2012, at 10:02 PM, Stefan Teleman wrote:
On Wed, Sep 19, 2012 at 8:51 PM, Liviu Nicoara nikko...@hates.ms wrote:
I think you are referring to `live' cache objects and the code which
specifically adjusts the size of the buffer according
On 09/20/12 13:11, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 8:07 AM, Liviu Nicoara nikko...@hates.ms wrote:
But have you measured the amount of memory consumed by all STDCXX locale data
loaded in one process? How much absolute time is spent in resizing the locale
and facet buffers? What
On Sep 20, 2012, at 5:31 PM, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 5:07 PM, Liviu Nicoara nikko...@hates.ms wrote:
To answer your question [...]:
yes, the MT failures occur on SPARC as well, on both SPARCV8 and
SPARCV9, and the race conditions are reported on *ALL* plaforms
On Sep 20, 2012, at 7:37 PM, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 7:34 PM, Wojciech Meyer
wojciech.me...@googlemail.com wrote:
Hi,
My perceptions is by reading through the whole thread - we should not
trust 100% external tools to asses the safety of the code. I don't think
there
On Sep 20, 2012, at 5:23 PM, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 4:45 PM, Travis Vitek
travis.vi...@roguewave.com wrote:
I'll let you in on a little secret: once you call setlocale(3C) and
localeconv(3C), the Standard C Library doesn't release its own locale
handles until
On Sep 20, 2012, at 7:45 PM, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 7:22 PM, Liviu Nicoara nikko...@hates.ms wrote:
Stefan, I want to be clear. You are talking about a patch identical in
nature to the one I have attached now. Just want to be 100% sure we are
talking about the same
On Sep 20, 2012, at 8:02 PM, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 7:52 PM, Liviu Nicoara nikko...@hates.ms wrote:
On Sep 20, 2012, at 7:49 PM, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 7:40 PM, Liviu Nicoara nikko...@hates.ms wrote:
The only gold currency that anyone
On Sep 20, 2012, at 8:59 PM, Stefan Teleman wrote:
On Thu, Sep 20, 2012 at 8:44 PM, C. Bergström
cbergst...@pathscale.com wrote:
fencepost comment - The results are based on tools and I don't think he has
a large program which actually triggers the conditions. (Creating one may
take
On 09/18/12 08:55, Stefan Teleman wrote:
On Mon, Sep 17, 2012 at 11:17 AM, Liviu Nicoara nikko...@hates.ms wrote:
I hope you agree that this synchronization is sufficient for the facet
initialization and reading of facet data.
I have reduced the number of reported race conditions in
22
On 09/18/12 13:21, Stefan Teleman wrote:
On Tue, Sep 18, 2012 at 12:43 PM, Liviu Nicoara nikko...@hates.ms wrote:
I am attaching a test program which, while 100% MT-safe, is flagged by
the Solaris thread analyzer.
The program as written is not thread safe. It is reading the value
On 09/18/12 18:24, Stefan Teleman wrote:
On Tue, Sep 18, 2012 at 4:35 PM, Liviu Nicoara nikko...@hates.ms wrote:
I will concede that I might be wrong and I am open to arguments. I would
accept as a counter-argument this program if you can show a runtime failure.
The the first read
On 9/18/12 7:04 PM, Stefan Teleman wrote:
On Tue, Sep 18, 2012 at 6:42 PM, Liviu Nicoara nikko...@hates.ms wrote:
The first check is indeed an optimization. It is the point of this exercise
to show that the unguarded reads in the localization library are not defects
and the code, simplified
On 09/17/12 09:51, Stefan Teleman wrote:
On Mon, Sep 17, 2012 at 8:46 AM, Liviu Nicoara nikko...@hates.ms wrote:
In the meantime I would like to stress again that __rw_get_numpunct is
perfectly thread-safe and does not need extra locking for perfect
forwarding.
So, by removing the test
On 09/17/12 11:21, Stefan Teleman wrote:
On Mon, Sep 17, 2012 at 11:17 AM, Liviu Nicoara nikko...@hates.ms wrote:
I hope you agree that this synchronization is sufficient for the facet
initialization and reading of facet data.
Sorry, I do not agree. Two different thread analyzers from two
Hi all,
I need a reference manual for the fbe assembler. I am interested in the syntax
of the `.type' directive. Do you know where such a manual would be located? The
Solaris assembler manual I found on Oracle's website does not mention the .type
directive.
Thanks!
Liviu
On 9/16/12 3:20 AM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 4:53 PM, Liviu Nicoara nikko...@hates.ms wrote:
Now, to clear the confusion I created: the timing numbers I posted in the
attachment stdcxx-1056-timings.tgz to STDCXX-1066 (09/11/2012) showed that a
perfectly forwarding
On 9/16/12 11:21 AM, Liviu Nicoara wrote:
On 9/16/12 3:20 AM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 4:53 PM, Liviu Nicoara nikko...@hates.ms wrote:
Now, to clear the confusion I created: the timing numbers I posted in the
attachment stdcxx-1056-timings.tgz to STDCXX-1066 (09/11/2012
On 9/1/12 1:52 PM, Stefan Teleman wrote: On Sat, Sep 1, 2012 at 12:15 PM,
I opened yesterday STDCXX-1066:
https://issues.apache.org/jira/browse/STDCXX-1056
about the pthread_mutex_t/pthread_cond_t alignment on SPARCV8. I'll
have patches done this weekend. Achtung: the patchset is very
On 9/15/12 1:51 PM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 9:01 AM, Liviu Nicoara nikko...@hates.ms wrote:
That is funny. What compiler are you using? What does the following test
case return for you?
It's the Intel compiler with the patched stdcxx for the wrong case
and GCC 4.7.1
On 9/15/12 2:57 PM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 1:02 PM, Liviu Nicoara nikko...@hates.ms wrote:
I have read through the patches attached to the incident, then I briefly
read about the SunPro pragma align and pack. Two questions:
1. AFAICT, the use of the packing pragma may
On 9/15/12 5:19 PM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 4:57 PM, Liviu Nicoara nikko...@hates.ms wrote:
Yes, but it restores the default packing, not an arbitrary one, potentially
set by the user prior to including our headers. Say, the user sets 2, the
default is 4 and we set 8
On 09/12/12 00:21, Stefan Teleman wrote:
On Tue, Sep 11, 2012 at 10:18 PM, Liviu Nicoara nikko...@hates.ms wrote:
AFAICT, there are two cases to consider:
1. Using STDCXX locale database initializes the __rw_punct_t data in the
first, properly synchronized pass through __rw_get_numpunct. All
On 09/11/12 08:15, Jim Jagielski wrote:
It's time for our report to the board...
what would we like to share?
I see:
o renewed discussion on health/viability of pmc
o increased development being done
o PMC expressing interest in moving to git
This sounds about right. It should also
On 9/11/12 9:40 PM, Martin Sebor wrote:
On 09/11/2012 04:15 PM, Stefan Teleman wrote:
On Mon, Sep 10, 2012 at 4:24 PM, Stefan Teleman
I think I have something which doesn't break BC - stay tuned because
I'm testing it now.
OK.
So, here's a possible implementation of __rw_get_numpunct() with
On 09/10/12 15:01, Stefan Teleman wrote:
On Mon, Sep 10, 2012 at 2:21 PM, Liviu Nicoara nikko...@hates.ms wrote:
4. Without caching of grouping values, grouping() delegates always to
do_grouping():
real0m5.668s
user1m11.389s
sys 0m3.952s
FWIW, 22.2.3.1.1 explicitly states
The default compiler on recent Apple Macs is LLVM with Clang and gcc C++
front-ends. The compiler does not come with a C++ language support library.
However, gcc Mac builds are fine with GNU stock compilers, modulo the issues for
which I attach the patch below, for review.
I built
On 9/9/12 7:07 PM, Wojciech Meyer wrote:
Hi Liviu,
I don't use Mac OS X at all but:
Liviu Nicoara nikko...@hates.ms writes:
The default compiler on recent Apple Macs is LLVM with Clang and gcc
C++ front-ends. The compiler does not come with a C++ language support
library. However, gcc Mac
On 09/06/12 19:54, Martin Sebor wrote:
I'm not sure how easily we can do that. Almost all of locale
is initialized lazily. Some of the layers might depend on the
facets being initialized lazily as well. This was a deliberate
design choice. One of the constraints was to avoid dynamic
On 09/06/12 23:00, Martin Sebor wrote:
Every project has certain branch strategy, I'm not sure about this so
maybe Martin can advice. I prefer to develop on trunk and cherry pick
to the other branches avoiding bulk merges (and that's in both
directions).
We've done most work on 4.2.x for
On 09/06/12 22:58, Stefan Teleman wrote:
On Thu, Sep 6, 2012 at 7:31 PM, Liviu Nicoara nikko...@hates.ms wrote:
There would be a performance degradation. IMHO, it would be minor and would
simplify the code considerably.
After finally being able to reproduce the defect with SunPro 12.3
On 09/07/12 10:54, Martin Sebor wrote:
We should remember that there are a number of Jira issues that
we fixed on 4.2.x but haven't merged out to 4.3.x or trunk. The
idea behind the current process (4.2.x - 4.3.x - trunk) was
to be able to simply merge the branches in bulk, as opposed to
an fix
On 09/07/12 11:58, Stefan Teleman wrote:
On Fri, Sep 7, 2012 at 8:52 AM, Liviu Nicoara nikko...@hates.ms wrote:
On 09/06/12 19:54, Martin Sebor wrote:
Also, does the 27.objects test pass with this patch?
No, it does not. It hangs at the first insertion, line 227. Unfortunately, I
cannot
On 09/05/12 23:51, Martin Sebor wrote:
On 09/05/2012 09:03 PM, Stefan Teleman wrote:
[...]
Agreed.
But: if the choice is between an implementation which [1] breaks ABI
and [2] performs 20% worse -- even in contrived test cases -- than
another implementation [2] which doesn't break ABI, and
What is the latest policy in what regards trivial fixes, e.g., the volatile
qualifier for the max var in LIMITS.cpp we discussed earlier, etc.? It seems
excessive to create a bug report for such issues.
Also, IIUC from reading previous discussions, forward and backward binary
compatible
On 09/06/12 14:37, Wojciech Meyer wrote:
Liviu Nicoara nikko...@hates.ms writes:
What is the latest policy in what regards trivial fixes, e.g., the
volatile qualifier for the max var in LIMITS.cpp we discussed earlier,
etc.? It seems excessive to create a bug report for such issues.
[...]
So
On Sep 5, 2012, at 4:03 PM, Martin Sebor wrote:
On 09/05/2012 01:33 PM, Liviu Nicoara wrote:
On 09/05/12 15:17, Martin Sebor wrote:
On 09/05/2012 12:40 PM, Liviu Nicoara wrote:
On 09/05/12 14:09, Stefan Teleman wrote:
On Wed, Sep 5, 2012 at 10:52 AM, Martin Sebor mse...@gmail.com wrote
On 09/05/12 00:51, Stefan Teleman wrote:
On Tue, Sep 4, 2012 at 10:49 PM, Martin Sebor mse...@gmail.com wrote:
template class _CharT
inline string numpunct_CharT::grouping () const
{
if (!(_C_flags _RW::__rw_gr)) {
numpunct* const __self = _RWSTD_CONST_CAST
On 09/05/12 14:09, Stefan Teleman wrote:
On Wed, Sep 5, 2012 at 10:52 AM, Martin Sebor mse...@gmail.com wrote:
[...]
OK so I did a little bit of testing, after looking at the *right*
__rw_guard class. :-)
I changed the std::numpunct class thusly:
[...]
And then:
template class _CharT
inline
1 - 100 of 122 matches
Mail list logo
