It was about time.
+1
Tim Adams wrote:
Our experience with our customer base indicates that MSVC 7.0 was
abandoned quickly in favor of 7.1.
So my vote is also +1 in favor of dropping 7.0.
-- Tim
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin
Hi,
I need assistance with the resetting of my account, lnicoara at apache.
I cannot reset my password via https://id.apache.org because I do not have the
backup email account anymore, where the reset information is sent.
Thanks in advance.
Liviu Nicoara
On 08/29/12 10:54, Jim Jagielski wrote:
Looking over the lack of activity within this project, it's
obvious (at least to me), that maybe its day is done.
Should I call a vote to move C++ to the Attic? Or is there someone
who feels that the project should still exist *and* is willing
to stand as
On 08/30/12 06:38, Jim Jagielski wrote:
On Aug 29, 2012, at 1:12 PM, Liviu Nicoaranikko...@hates.ms wrote:
The discussion back in February showed that, even though committers have not
spent much time lately contributing new code to it, there is an active review
of the activity occurring on
On 08/30/12 06:48, C. Bergström wrote:
I'm sincerely sorry to ask this and I have my own answers, but why continue
STDCXX when such negativity from Apache is apparent..
AFAICT, the Apache Foundation has been a good host for STDCXX during these
years. They have provided a framework for STDCXX
On 08/30/12 08:56, C. Bergström wrote:
On 08/30/12 07:29 PM, Liviu Nicoara wrote:
AFAICT, the Apache Foundation has been a good host for STDCXX during these
years. They have provided a framework [...] in accordance to their principles
about what constitutes a healthy software project.
I
I see in the February report (http://stdcxx.apache.org/status/2012-02.txt) that
three new committers have been added to the project. Congratulations! Could one
of you please update the stdcxx list of committers?
Thanks.
L
On 08/30/12 11:17, Stefan Teleman wrote:
[...]
I don't mean to punt but I think Jim Jagielski maintains a separate
link with the correct list of committers:
I don't see any difference between the two, either. I'll leave it at that.
L
On Aug 30, 2012, at 5:45 PM, C. Bergström cbergst...@pathscale.com wrote:
On 08/31/12 03:10 AM, Pavel Heimlich, a.k.a. hajma wrote:
2) Posting the project is dead on a public list certainly doesn't help grow
a community
well, it's half year since revival of the project was announced and
On Aug 30, 2012, at 8:00 PM, C. Bergström wrote:
On 08/31/12 06:43 AM, Liviu Nicoara wrote:
While I recognize the value of each one of the points you make, I am puzzled
as to why you are not going forward on your way with your fork? How is the
Apache Foundation keeping you from making
Please correct me if I am wrong.
I have seen two forks on github, one belonging to C. Bergstrom/Pathscale and
the other to Stefan Teleman.
The first one contains a number of genuine code changes outside the Apache
repository, but without canonical and meaningful commit comments, and without
On 08/31/12 08:18, Jim Jagielski wrote:
On Aug 30, 2012, at 5:45 PM, C. Bergströmcbergst...@pathscale.com wrote:
[...]
STDCXX isn't some stupid ass java framework or widget - It's a *critical* part
of a C++ stack and the cost of leaving it out of the attic is negligible -
What's the benefit
On 08/31/12 08:58, C. Bergström wrote:
On 08/31/12 07:40 PM, Liviu Nicoara wrote:
Please correct me if I am wrong.
I have seen two forks on github, one belonging to C. Bergstrom/Pathscale and
the other to Stefan Teleman.
The first one contains a number of genuine code changes outside
On 08/31/12 13:14, Stefan Teleman wrote:
In June this year I committed r1353821 to trunk which fixes stdcxx-1058.
I have the patches for 1058 ready to commit to branches (4.2.x and 4.3.x).
OK to go?
The patch looks ok to me. What seems to be the problem? +1
L
The branching policy [1] in effect looks very much like the Rogue Wave release
process: branch at the beginning of each release cycle, work on the release
branch, merge changes back into the trunk at release time (and in between as
needed). Did I get that right?
From what I gather 4.2.x has
My input below.
On 08/31/12 09:42, Wojciech Meyer wrote:
The two significant ones (as far as I can understand):
- as I heard from Christopher Bergström that it's hard to push the
stdcxx to FreeBSD ports repository (I can understand it and that
sounds pretty bad, if that's the case then
Would someone please apply the patch on 4.2.x branch? (I have not yet regained
access to my Apache account.)
2012-09-01 Liviu Nicoara nikko...@hates.ms
* tests/containers/23.bitset.cpp: swapped lines to avoid compiler bug
(see http://gcc.gnu.org/bugzilla/show_bug.cgi?id
On 08/31/12 12:20, Stefan Teleman wrote:
On Fri, Aug 31, 2012 at 8:40 AM, Liviu Nicoara nikko...@hates.ms wrote:
Stefan's seem like a complete git-ification of the whole Apache repository
but with no changes I could detect.
Not quite. :-)
[...]
The official Oracle port for Solaris 10 and 11
On 08/31/12 08:58, C. Bergström wrote:
On 08/31/12 07:40 PM, Liviu Nicoara wrote:
Please correct me if I am wrong.
I have seen two forks on github, one belonging to C. Bergstrom/Pathscale and
the other to Stefan Teleman.
The first one contains a number of genuine code changes outside
On Sep 1, 2012, at 1:52 PM, Stefan Teleman wrote:
On Sat, Sep 1, 2012 at 12:15 PM, Liviu Nicoara nikko...@hates.ms wrote:
[...]
This pretty much sums up my first impression.
[...]
To begin with: the compiler flags/GNUmakefile changes are very
specific to the SunPro compilers and to our
On Sep 2, 2012, at 12:16 PM, Wojciech Meyer wrote:
According to the wikipedia we are dead?
http://en.wikipedia.org/wiki/Apache_C%2B%2B_Standard_Library
are we? :-)
It's hard to argue against, at this point. But I hope we'll soon be able to
justify changing it.
L
On Sep 4, 2012, at 10:34 AM, Stefan Teleman wrote:
On Tue, Sep 4, 2012 at 7:35 AM, Liviu Nicoara nikko...@hates.ms wrote:
By no means I am dismissing it. It is at the very least an issue of
efficiency. I will try an Intel C++ build on x86_64 at some point today.
What build type was that? I
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
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/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
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/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
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/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 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 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 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 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
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/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
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/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
___
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/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
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/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
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 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
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 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
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
1 - 100 of 122 matches
Mail list logo
