this compiler does not currently support *any*
C++0X features, and support for these features will not be available
for quite some time. And the compiler is not open source.
So no, I am not hijacking threads. I am seeking some clarification
with respect to your own statements.
--Stefan
--
Stefan
2010/6/4 C. Bergström cbergst...@pathscale.com:
I checked my email and I think you just assumed sun cc..
Yes I assumed Sun CC when I read OpenSolaris, and I didn't quite see
any reference to PathScale.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
.
Thank you.
--Stefan
---
[1] Apache stdcxx will also become available in Solaris 10 starting
with Update 10, to be released sometime this year.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
conformance to the
2003 C++ Standard causes problems with Boost, then that's a Boost
problem and not a stdcxx problem.
There were indeed numerous deviations from the 2003 C++ Standard in
the original stdcxx implementation.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
code published by PathScale and it is obvious
to me that it has not been validated against *any* C++2003 validation
test harness.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
that
the violations are still there), several tests from the apache stdcxx
test harness would have failed, and these tests would have required
patches too. I do not see the necessary code changes, and I can tell
all this by looking at the PathScale stdcxx fork code.
--Stefan
--
Stefan Teleman
KDE e.V
in Solaris for a long time to come. It
would be very sad for such a nice implementation of C++2003 to be
retired and left to gather dust.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
discouraging to submit
patches knowing full well and ahead of time that they will never make
it anywhere. Perhaps the process of submitting patches could be
somewhat less of a process.
Just my 0.02.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
for the 4.2.x branch should have forwards and backwards
binary compatibility.
* Changes destined for the 4.3.x branch should have backwards source
compatibility.
--Andrew Black
On 02/03/2012 03:04 PM, Farid Zaripov wrote:
On 03.02.2012 1:52, Stefan Teleman wrote:
2. Someone with stdcxx
On Tue, May 1, 2012 at 09:14, Jim Jagielski j...@jagunet.com wrote:
is this thing on?
Just checking :)
Yes, it works! :-)
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
haven't received any comments.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Tue, May 15, 2012 at 10:15 AM, Stefan Teleman
stefan.tele...@gmail.com wrote:
On Tue, May 15, 2012 at 9:33 AM, Jim Jagielski j...@jagunet.com wrote:
Since being tasked as chair, I've seen no activity. There was
an email from Bill regarding 2 outstanding iCLAs, but the response
from one
On Thu, May 17, 2012 at 11:58 AM, Martin Sebor mse...@gmail.com wrote:
On 05/16/2012 09:23 PM, Stefan Teleman wrote:
On Wed, May 16, 2012 at 2:58 PM, Martin Sebormse...@gmail.com wrote:
On 05/16/2012 11:55 AM, Travis Vitek wrote:
I approve the change, but with one caveat. The branching
scope declarations).
Martin
Done - new attachment 27.basic_ios.copyfmt.stdcxx-1058.cpp
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Mon, Jun 11, 2012 at 12:22 PM, Martin Sebor se...@apache.org wrote:
On 06/11/2012 02:13 AM, Stefan Teleman wrote:
Hi!
Trying to commit my fix for STDCXX-1058 to trunk, I get the following:
[steleman@darthvader][/src/steleman/programming/stdcxx-svn/stdcxx-trunk][06/11/2012
4:05:37][1026
with the intention of being a constant
presence here, and I hope I will be able to contribute as well. I am not
sure if anyone reviewed the patches volunteered by Stefan yet, or the
changes in forks elsewhere, but I am currently looking at that, too.
Thanks.
Liviu
--
Stefan Teleman
KDE
currently supports it.
0.02.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
is constantly maintained at Oracle, and
we publish source code drops every two weeks there (I think).
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
, or a group of persons G[P] who
will declare that the current license N is
inappropriate/invalid/incompatible/etc, and will advocate a change to
another Open Source License Q.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
is that 4.2.x and 4.3.x are bugfix/rfe releases while
5.x would become C++2011.
Please correct me if i'm wrong
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Fri, Aug 31, 2012 at 1:29 PM, Liviu Nicoara nikko...@hates.ms wrote:
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
of stdcxx.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
::size_t));
MEMFUN (unsigned long, to_ulong, () const);
Done - revision 1379813.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
numbers because most of them are quite old and right now,
off the top of my head, I can't remember what they are. :-)
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Mon, Sep 3, 2012 at 11:57 PM, Stefan Teleman
stefan.tele...@gmail.com wrote:
On Mon, Sep 3, 2012 at 3:19 PM, Liviu Nicoara nikko...@hates.ms wrote:
I tried, unsuccessfully, to reproduce the failure observed by Martin in
22.locale.moneypunct.mt, in both debug and optimized, wide and narrow
and initialized. But this breaks ABI, so I'm
thinking it's for stdcxx 5.
Thoughts?
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
sys 159.49
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Wed, Sep 5, 2012 at 4:20 PM, Stefan Teleman stefan.tele...@gmail.com wrote:
But then there's another aspect -- which I probably failed to
highlight in my previous email: the per-object mutex implementation is
20% *slower* than the class-static mutex implementation.
class-static
20% worse -- even in contrived test cases -- than
another implementation [2] which doesn't break ABI, and performs
better than the first one, why would we even consider the first one?
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
::grouping().
I've already tested this with 3 compilers, and, it does indeed deadlock.
So yes, I did indeed mean something different. I meant adding another
mutex data member to the numpunct class.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Thu, Sep 6, 2012 at 2:46 PM, Stefan Teleman stefan.tele...@gmail.com wrote:
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][09/06/2012
14:40:11][1084] ./22.locale.numpunct.mt --nthreads=2 --nloops=100
# INFO (S1) (10 lines):
# TEXT:
# COMPILER
|0 |3 | 100% |
# | (S9) FATAL|0 |1 | 100% |
# +---+--+--+--+
real 1035.05
user 1191.76
sys 63.49
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
at work about 12.3/Linux.
Strangely enough, I don't get the error on Fedora 17 with 12.3.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Thu, Sep 6, 2012 at 6:43 PM, Stefan Teleman stefan.tele...@gmail.com wrote:
On Thu, Sep 6, 2012 at 4:02 PM, Martin Sebor mse...@gmail.com wrote:
Here's a thought: it's not pretty but how about having
the function initialize the facet? It already has a pointer
to the base class, so it could
(), truename(), falsename() must return their do_*()
counterparts.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
to the function (or
something like that). Unfortunately, it would break binary
compatibility.
I think I have something which doesn't break BC - stay tuned because
I'm testing it now.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
. I'm trying to find the best way of making these facets
thread-safe while inflicting the least horrible performance hit.
i will run your tests tomorrow and let you know. :-)
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
to best answer this questions, could one of the BSD Internet
Attorneys please provide the legal definitions for the following
terms:
1. system
2. libraries
3. are
4. usually
5. shipped
6. by
7. default
8. with
9. the
Thank you.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
proposed, which is indeed much better performing than using a mutex
lock. Unfortunately, in doing so, overriding the virtual functions in
a derived facet type becomes pointless.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
is with our (Solaris) patch applied.
Here are the results:
1. with your patch applied:
http://s247136804.onlinehome.us/22.locale.numpunct.mt.1.er.nts/
2. with our (Solaris) patch applied:
http://s247136804.onlinehome.us/22.locale.numpunct.mt.1.er.ts/
--Stefan
--
Stefan Teleman
KDE e.V
))
(or any other bitmask for that matter), the functions which were
thread-unsafe - and were exhibiting all the symptoms of a run-time
race condition -, magically became thread-safe?
I have looked *extensively* at the code in __rw_get_numpunct. It is
inherently thread-unsafe.
--Stefan
--
Stefan
compiler writers tell me
not to.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
show the same exact problems.
The Intel Compilers and the SunPro Compilers have nothing in common
with each other.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
. It is only
step one towards finding a real solution. But, at least for now, we
have pinpointed where the source of these race conditions is located,
and what causing it.
The test program was run as: ./22.locale.numpunct.mt --nthreads=8
--nloops=1.
More to follow.
--Stefan
--
Stefan Teleman
KDE e.V
value is safe to use here
}
}
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
with thread-safety, and everything to do with a minor
optimization: if the value stored in variable counter is already not
zero, then there's no point in locking the mutex or performing the
increment.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
assertions. If you firmly and strongly believe that you are always
right, and that the four thread analyzers are always wrong, that is
your choice.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
-20120919/locale_body.cpp
http://s247136804.onlinehome.us/stdcxx-1056-20120919/punct.cpp
These files are based on stdcxx 4.2.1.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
. On SunPro
you have to pass -xkeepframe=%all (which disables tail-call
optimization as well), in addition to passing -xO0 and -g. So the
timings for these unoptimized experiments would have been completely
irrelevant.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
.
This entire discussion has become a perfect illustration with what's
wrong with the ASF, as reported here:
http://www.mikealrogers.com/posts/apache-considered-harmful.html
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
.
That's said I admire Stefan's approach, but we should ask the question
are we MT safe enough? I would say from what I read here: yes.
Based on what objective metric?
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
being September 20, 2012.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
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 in here accepts without reservations are
failing test cases
condition and thread safety problem, it
needs to be investigated and fixed..
2. Bah, the tools are crap, nothing to see here, move along, declare victory.
I chose [1] because I am willing to accept my *own* limitations.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
by SunPro and Intel are,
in fact, real race conditions (as opposed to fake race
conditions)?
And the means of proving the existence of these real race conditions
is ... [ drum roll ] ... fprintf(3C)?
This is very funny. You made my day,
Have a nice evening.
--
Stefan Teleman
KDE e.V.
stefan.tele
in the first place.
If the official method of determining thread-safety here is
fprintf(3C), then we have a much bigger problem than
22.locale.numpunct.mt.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
% of the reported race conditions, this
entire back-and-forth about the existence of these race conditions,
the accuracy of the tools and what they are reporting is nothing but a
giant waste of time.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
written approval from the Legal
Counsel's Office in order to be able to share these patches. And that
in spite of the fact that these patches are published, and have
already been published for *years*.
IANAL and I don't want to play one on TV. ;-)
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele
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
pthread_mutex_t must start at 8-byte aligned
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 that my patch
*does* fix the race condition
, no.
This will not be another replay of the stdcxx-1056 email discussion,
which was a three week waste of my time.
The patch is provided AS IS. No further testing and no further
comments. I do have more important things to do.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
the instances in the library where
we might use mutex and condition objects that are misaligned wrt the
mentioned kernel update.
Yeah, why don't you go ahead and do that. Just like you fixed stdcxx-1056.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
and moneypunct on Linux/Intel 32/64,
Solaris SPARC 32/64 and Solaris Intel 32/64. The test results are in
the onlinehome.us directory URL i put in the comment.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
Analyzer.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Tue, Sep 25, 2012 at 8:05 PM, Liviu Nicoara nikko...@hates.ms wrote:
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
On Wed, May 29, 2013 at 5:55 PM, Martin Sebor mse...@gmail.com wrote:
On 05/29/2013 07:27 AM, Stefan Teleman wrote:
On Wed, May 29, 2013 at 7:33 AM, C. Bergström
cbergst...@pathscale.com wrote:
On 05/29/13 06:29 PM, Jim Jagielski wrote:
I am stepping down as Chair of the C++ StdLib PMC
66 matches
Mail list logo
