Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: webmaster at havogt dot de
Target Milestone: ---
vogt@fermi03:~/temp2> cat test_SFINAE_with_template_binding.ii
# 1 "test_SFINAE_with_template_binding.cc"
# 1 ""
# 1 &q
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52554
--- Comment #7 from openhardware 2012-03-29
13:40:14 UTC ---
"Alternatively, change the documentation to the effect that invalid assembly
code and valid (but semantically wrong) assembly code aren't necessarily
compiler bugs."
Its a "windows-app
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52554
webmaster at openhardware dot de changed:
What|Removed |Added
CC||webmaster at
--- 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
--- 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 pessi
--- 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
--- Comment #1 from davids at webmaster dot com 2008-03-28 09:24 ---
#include
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 and memcmp
Status: UNCONFIRMED
Severity: 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-p
--- 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 documentatio
--- 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
See attach.
--- Additional Comments From webmaster at toshsoft dot de 2005-06-21 15:02
---
Source of vf_hue.c :
#include
#include
#include
#include
#include
#include "../config.h"
#include "../mp_msg.h"
#include "../cpudetect.h"
#include "img_format.h&qu
--- Additional Comments From webmaster at toshsoft dot de 2005-06-21 14:59
---
cc -v output:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/gcc-4.1.0_beta20050604/work/gcc-4.1-20050604/configure
--enable-version-specific-runtime-libs --prefix=/usr
dot gnu dot org
ReportedBy: webmaster at toshsoft dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: 4.1.0
GCC host triplet: 4.1.0
GCC target triplet: 4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22134
Lese selbst:
http://brandenburg.rz.fhtw-berlin.de/poetschke.html
--- 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
--- 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 betw
--- 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 no
--- 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
--- 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 allow
--- 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 failu
--- 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.
Access
--- 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 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 mi
--- 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,
--- 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
Version: 3.4.2
Status: 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
--- 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 is
28 matches
Mail list logo
