t;< "sizeof(x) = " << sizeof(x) << " sizeof(y) = " <<
sizeof(y) << endl;
std::cerr << "sizeof(x) == sizeof(y): " << ((sizeof(x) ==
sizeof(y)) ? "TRUE" : "FALSE") << endl;
return 0;
}
//
>> CC -V
CC: Sun C++ 5.9 SunOS_i386 Patch 124864-01 2007/07/25
>> ./testlongdouble
x = 0.396465 y = 0.840485
sizeof(x) = 12 sizeof(y) = 12
sizeof(x) == sizeof(y): TRUE
x = 0 y = 0
sizeof(x) = 12 sizeof(y) = 12
sizeof(x) == sizeof(y): TRUE
http://developers.sun.com/sunstudio/downloads/patches/ss12_patches.jsp
There are more recent patches than my own installation.
--Stefan
--
Stefan Teleman
KDE e.V.
[EMAIL PROTECTED]
ches, all the tests perform as expected.
The patch 22.locale.numpunct.cpp.43.diff is not related to the SPARCV8
ABI change -- it is simply an avoidance of a SEGV in case the variable
first_non_c == NULL [ Solaris sprintf(3C) SEGV's on NULL char*
arguments ].
--Stefan
--
Stefan Teleman
stefan.tele...@gmail.com
other platforms besides Solaris/SPARC: i tried not to disturb any
other ISA's/compiler combinations. If you'd like i can re-write the
patches for 4.2.2 using the more generic approach you described.
--Stefan
--
Stefan Teleman
stefan.tele...@gmail.com
Hi.
This is a bite-size patch for driver.cpp for Solaris -- it adds
support for the next Solaris version (SunOS 5.11).
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
):
http://wikis.sun.com/display/SolarisStudio/Compilers
(somewhat down the page)
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
piler, when 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.
--Stef
2010/6/4 "C. Bergström" :
> 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
would be appreciated.
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
(the
sunpro.config patches, the GNUmakefile* patches and the patches for
the Standard C Library forwarding header files (cstdio, cstdlib,
cstring, clocale, etc ...).
I will start submitting patches here (at Apache) soon.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
ct 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
.peren.com/pages/cppvs_set.htm
Yes we do have reduced test cases for the violations, but we cannot
publish them because Perennial CPPVS must be licensed.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
hub 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
ou have not, I have verified 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
n 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
much guarantees
that it will never be brought back all together.
2. Someone with stdcxx commit privileges should be part of this
reunification (for obvious reasons). It is very 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
about why they are broken would be appreciated.
> * Changes destined 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/20
On Tue, May 1, 2012 at 09:14, Jim Jagielski wrote:
> is this thing on?
>
> Just checking :)
Yes, it works! :-)
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
in February have stopped.
I attached a proposed patch for stdcxx-1058 but I 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
wrote:
> On Tue, May 15, 2012 at 9:33 AM, Jim Jagielski 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 o
On Wed, May 16, 2012 at 12:15 PM, Travis Vitek
wrote:
>
> On Wed, May 16, 2012 at 5:47 AM, Stefan Teleman
> wrote:
>>
>> I am going to ask the following questions in the open. Perhaps this
>> way I will get an answer:
>>
>> 1. Apparently, "Bill'
058.cpp, and decorated with the ASF
> license header).
I attached 27.ios_base.event_callback.stdcxx-1058.cpp to stdcxx-1058,
which will go in ${TOPDIR}/test/regress/.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Thu, May 17, 2012 at 11:58 AM, Martin Sebor wrote:
> On 05/16/2012 09:23 PM, Stefan Teleman wrote:
>>
>> On Wed, May 16, 2012 at 2:58 PM, Martin Sebor wrote:
>>>
>>> On 05/16/2012 11:55 AM, Travis Vitek wrote:
>>>>
>>>>
>>>&g
t; fixes formatting -- please use 4 space indents and a space before
> each open paren; curly brace goes on the same line as the statement
> except for namespace 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 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/s
he
> changes in forks elsewhere, but I am currently looking at that, too.
>
> Thanks.
>
> Liviu
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
compile with clang 3.1 -
it currently doesn't.
Perhaps we could also start discussing C++2011 - at a convenient pace,
since only clang currently supports it.
0.02.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
x's Committers list.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
ntributed a
single line of code or bug fixes to stdcxx is tenuous at best.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
tdcxx for C++2011, and I think that one pre-requisite from
doing that is asking for Howard Hinnant's involvement and help. It
only seems fair to me to do so, since he is the author of libc++.
But it's going to be quite difficult to convince Howard to participate
in stdcxx if the dev mailing list is peppered with threats of
impending shutdown, every other month, or with unhelpful comments
about the project being in a "koma".
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
o at Oracle 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
gt; Can you help clear this roadblock, yes or no?
>
My 0.02 of observations about FOSS licenses in general, based on my
direct experience:
For any FOSS component M, licensed under an Open Source License N,
there will always exist a person P, 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
anding 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
actly is APLv2 different from 2-clause BSD or 3-clause BSD in
this respect? The BSD licenses are just as incompatible with GPLv2 as
APLv2 is.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Fri, Aug 31, 2012 at 1:29 PM, Liviu Nicoara 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).
&g
On Fri, Aug 31, 2012 at 2:46 PM, Liviu Nicoara wrote:
> On 08/31/12 14:15, Stefan Teleman wrote:
>>
>>
>> My understanding is that 4.2.x and 4.3.x are bugfix/rfe releases while
>> 5.x would become C++2011.
>
>
> There is an implicitly stated binary incompatib
and supported version of stdcxx.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
size_t) const);
> +MEMFUN (Bitset::reference, operator[], (std::size_t));
> MEMFUN (unsigned long, to_ulong, () const);
Done - revision 1379813.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
p of linking with stdcxx), and that just bad.
And then I'll have to cross reference the patches which refer to our
internal bug 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
x27;t look as closely now.
I'll create a Solaris build without my patches tomorrow and send the output.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Mon, Sep 3, 2012 at 11:57 PM, Stefan Teleman
wrote:
> On Mon, Sep 3, 2012 at 3:19 PM, Liviu Nicoara wrote:
>>
>> I tried, unsuccessfully, to reproduce the failure observed by Martin in
>> 22.locale.moneypunct.mt, in both debug and optimized, wide and narrow builds
On Mon, Sep 3, 2012 at 11:57 PM, Stefan Teleman
wrote:
> http://old.nabble.com/22.locale.numpunct.mt-run-hangs-td20133013.html
Also see this thread:
http://www.mail-archive.com/issues@stdcxx.apache.org/msg01182.html
and this:
https://issues.apache.org/jira/browse/STDCXX-839
--Ste
RAM, FSB
1066. The compiler is Intel 12.10 (free for non-commercial use,
downloadable from Intel).
The timeouts can also be a symptom of race conditions/deadlocks or
attempting to access invalid thread stacks, or partially written data.
It's very platform specific. On Solaris SPARC (either 32-bit or
64-bit) I never get timeouts, I always get either SEGV or SIGBUS. On
Intel it appears that timeouts are the prevailing symptom.
I am not sure what an explicit run timeout would add, except hiding
the hang/deadlock/memory corruption problem behind a timeout.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
copy of
_C_grouping, but a shared handle to its underlying _CharT buffer. Nor
was the initialization of _C_grouping mutex-protected inside the
member function
template
inline string numpunct<_CharT>::grouping () const.
This shared buffer was subsequently modified by another thread, in
another locale, while this thread was convinced, all along, that it
was holding a deep copy of the variable std::string grp, in the locale
it wanted. Hence, the assertion on the strcmp(3C) mismatch.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
laced into the
cache, the caller of any specfic locale gets a copy from the cache,
fully instantiated 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
_AE"
"ar_AE.iso88596" "ar_AE.utf8" "ar_BH" "ar_BH.iso88596" "ar_BH.utf8"
"ar_DZ" "ar_DZ.iso88596" "ar_DZ.utf8" "ar_EG" "ar_EG.iso88596"
"ar_EG.utf8" "ar_IN" "ar_IN.utf8" }
# CLAUSE: lib.locale.numpunct
[ ... ]
# +---+--+--+--+
# | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE |
# +---+--+--+--+
# | (S1) INFO | 11 | 11 | 0% |
# | (S2) NOTE |1 |1 | 0% |
# | (S8) ERROR|0 |3 | 100% |
# | (S9) FATAL|0 |1 | 100% |
# +---+--+--+--+
real 2416.75
user 2694.64
sys 159.49
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
ntation:
real 2416.75
user 2694.64
sys 159.49
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Wed, Sep 5, 2012 at 4:20 PM, Stefan Teleman 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 im
aks ABI
and [2] performs 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
his is the mutex already locked by
std::numpunct::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
locale -a > /tmp/tmpfile-YzXcb9"
# CLAUSE: lib.locale.numpunct
# FILE: process.cpp
# LINE: 276
grouping: _RWSTD_MT_GUARD (__self->_C_mutex): 0xf774913c
_C_get_data: _RWSTD_MT_GUARD (&_C_mutex): 0xf774913c
[ ... deadlock ... ]
Looks like the same mutex to me ...
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Thu, Sep 6, 2012 at 2:46 PM, Stefan Teleman 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
ign the initial values
> to the members. Would that work?
I haven't looked at them in detail (yet) but a cursory look shows that
they're both recursive for the successful case.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
% |
# | (S8) ERROR|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
1 |1 | 0% |
# | (S7) ASSERTION|0 | 22 | 100% |
# +---+--+--+------+
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
een fixed yet in 12.3. But I will ask 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 wrote:
> On Thu, Sep 6, 2012 at 4:02 PM, Martin Sebor 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
ouping(), truename(), falsename() must return their do_*()
counterparts.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
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
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
minimal locking, which passes the MT tests and does not b
gree with Martin that breaking ABI in a minor release is really
not an option. 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
much better with your
_numpunct.h patch:
real 668.93
user 804.00
sys 34.24
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
rder 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
aris at all.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Thu, Sep 13, 2012 at 1:40 AM, Stefan Teleman
wrote:
> The performance of 22.locale.numpunct.mt is also much better with your
> _numpunct.h patch:
>
> real 668.93
> user 804.00
> sys 34.24
Unfortunately, the resulting facet is non-conformant. For this simple test case:
#
d, 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
g side-effects in user programs.
> 2. The patches are against 4.2.1, but the change would be binary
> incompatible with the already released 4.2.1 branch. Do you plan to have
> this fix in 4.3.x?
Yes, definitely for 4.2.x and 4.3.x. I sent them for 4.2.1 just
because that's what I have handy.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Sat, Sep 15, 2012 at 2:57 PM, Stefan Teleman
wrote:
> #pragma pack(0) restores the default alignment.
s/alignment/packing/g
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
emails. I didn't get an email about stdcxx-1066 either,
not even when I initially opened it, and that is also strange.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
ram needs to pack something in a
certain specific way, it need to do so for that specific something
only. Otherwise the side-effects of globally setting a non-default
packing will destroy the program anyway.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
experiment 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 Telem
ation on any operating system
that I know of, not just on SPARCV8.
In order to make any change to the packing/alignment patches now I
would have to re-run _all_ the validation tests for stdcxx on SPARC,
on Solaris 10 and Solaris 11. I'm pretty sure that is not workable at
this point.
nts is to identify those spots in the program
where a race condition exists, and will cause synchronization problems
and run-time errors.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
(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 Te
mpiler writers tell me
not to.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
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
ep 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.
stefa
// counter value is safe to use here
}
}
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
o do 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
ems in Apache stdcxx.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
alyzers contradict to all of your
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
.us/stdcxx-1056-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
above also timing the changes?
Nah, I didn't bother with the timings - yet - for a very simple
reason: in order to use instrumentation, both with SunPro and with
Intel compilers, optimization of any kind must be disabled. 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
.
The patch is in scope for the issue at hand. The issue is that
std::numpunct and std::moneypunct are not thread safe. This has been
confirmed by 4 different thread analyzers, even after applying your
_numpunct.h patch.
You are more than welcome to submit your own patch which eliminates
100% of the race conditions.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
obvious facts, your credibility is quite a bit under question at this
point.
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
esult showing more than 12000 race conditions in
22.locale.numpunct.mt *AFTER* having applied your patch.
--
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
ults, today
being September 20, 2012.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
On Thu, Sep 20, 2012 at 7:52 PM, Liviu Nicoara wrote:
>
> On Sep 20, 2012, at 7:49 PM, Stefan Teleman wrote:
>
>> On Thu, Sep 20, 2012 at 7:40 PM, Liviu Nicoara wrote:
>>
>>> The only gold currency that anyone in here accepts without reservations are
>>&g
d 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
detected 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 n
he 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
) is considered an
acceptable method of debugging thread-safety problems.
You are correct: I did not, and will not, waste my time writing *any*
program which attempts to debug thread-safety problems with
fprintf(3C).
But I am very glad this is on a public mailing list, so everyone can
read what's going on here.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
ide an alternative patch which
demonstrably eliminates 100% 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
through my stuff at work and look at the test reports
from the Compiler Guys, we were testing these back in March 2011, and
right now I can't remember exactly which tests were failing. I'll have
the details in a few days.
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
that the pragma must use the mangled variables names but
> I don't see that in the patch.
Yes, a few things are a bit different. ;-) I wish I didn't have to be
as vague and secretive about these things as I have to be.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
e it or not, I had to get 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...@gmail.com
On Sun, Sep 23, 2012 at 5:23 PM, Stefan Teleman
wrote:
> The second URL says this:
>
>
> 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 wrote:
> On 09/21/12 05:13, Stefan Teleman wrote:
>>
>> On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
>> wrote:
>>
>> I have provided this list with test results showing that my patch
>> *does* fix the race c
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
1 - 100 of 110 matches
Mail list logo
