--- Comment #18 from davids at webmaster dot com 2009-02-25 16:06 ---
This is a real bug. There is simply no way to write correct threaded code if
the compiler is free to read a variable and write it back when the code didn't
specifically tell it to.
Optimizations on threaded code
--- Comment #20 from davids at webmaster dot com 2009-02-25 17:53 ---
I don't like this either:
tmp = var;
modified = false;
for (i = 0; i 100; i++)
{
if (i x)
tmp = i, modified = true;
}
if (modified)
var = tmp;
This can be a pessimization as well
--- Comment #23 from davids at webmaster dot com 2009-02-25 18:35 ---
Really to me this is still a valid transformation even in the inside threads.
If you want to be able to access via different threads, use locks, heavy or
light weight ones.
Absolutely, you do use locks everywhere
: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davids at webmaster dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla
--- Comment #1 from davids at webmaster dot com 2008-03-28 09:24 ---
#include string.h
int moo(void)
{
unsigned char msg1[] = { 0, 0 };
unsigned char msg2[] = { 0, 0 };
memcpy(msg1, msg2, 2);
return memcmp(msg1, msg2, 2) != 0;
}
With this code, changing the sizes in both memcpy
--- Comment #17 from davids at webmaster dot com 2008-03-26 22:56 ---
I wonder why -Wcast-align doesn't generate a warning in this case. It would
seem that would be what it's for. I get a segfault in the reduced test case and
no warning from -Wcast-align. The documentation seems
--- Comment #9 from davids at webmaster dot com 2007-06-26 03:42 ---
This should be marked as a 4.2.0 regression.
--
davids at webmaster dot com changed:
What|Removed |Added
--- Additional Comments From davids at webmaster dot com 2005-02-24 20:42
---
The only thing which would change when you remove the automatically
inserted locking is that some programs which used to work are now
broken, and that some other programs which used to deadlock now
invoke
--- Additional Comments From davids at webmaster dot com 2005-02-24 22:22
---
They are non-portable no matter how static initializers are done:
C++ doesn't include threads and POSIX doesn't include C++.
That's a bogus argument. There are no conflicts between the two standards
--- Additional Comments From davids at webmaster dot com 2005-02-24 23:45
---
The difference is that almost all uses of strchr are done on data
which is not shared between threads, while many static local
initializers are used on objects which are accessed from multiple
threads
--- Additional Comments From davids at webmaster dot com 2005-02-23 01:30
---
The '-pthreads' flag should imply '-fno-threadsafe-statics'. For every other
similar flag I can find, the default is to permit the compiler to make the
optimizations that standard allows and specific flags
--- Additional Comments From davids at webmaster dot com 2005-02-23 02:19
---
It's not the question of optimization but correctness.
Exactly, and not locking objects that may be modified from another thread is
not correct. Only the programmer knows whether an object may be modified
--- Additional Comments From davids at webmaster dot com 2005-02-20 10:48
---
There is certainly the eternal argument whether a class should implement its own
locks internally or whether the caller should implement them. The first case
simplifies calling at the expense of overhead when
--- Additional Comments From davids at webmaster dot com 2005-02-20 19:43
---
The reasoning is that dynamically created objects are often used locally in one
thread, in which case locking would be unnecessary, while a singleton is always
accessible to all threads.
Accessible
--- Additional Comments From davids at webmaster dot com 2005-02-20 23:59
---
What you keep ignoring is that the POSIX standard explicitly declares it a bug
to access data in one thread while it may be modified in another. It's not
unfortunate timing, it's failure to use the proper
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davids at webmaster dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet
--- Additional Comments From davids at webmaster dot com 2005-02-20 01:09
---
Do we agree that this is a pure pessimization for POSIX-compliant code? Do we
agree that POSIX already requires a mutex to protect code that might modify an
object?
--
What|Removed
--- Additional Comments From davids at webmaster dot com 2005-02-20 02:46
---
In your example:
class A
{
A();
int t;
};
void f()
{
static A a;
}
I don't get it. What's the problem with this? Obviously, if you plan to call
'f()' from multiple threads, you must do it while
--- Additional Comments From davids at webmaster dot com 2005-02-20 02:50
---
You say, how can someone know that A will modify memory? The answer is, the
C++ standard says so, section 7.1.2. They simply read that section of the
standard, and they know that the function might modify
--- Additional Comments From davids at webmaster dot com 2005-02-02 23:22
---
This is not a GCC bug and should not be fixed in GCC. The bug is in the test
code which accesses an object that is shared by multiple threads without proper
mutexes. Period. End of story.
The correct fix
20 matches
Mail list logo
