--- Comment #16 from bkoz at gcc dot gnu dot org 2006-08-31 09:08 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #17 from bkoz at gcc dot gnu dot org 2006-08-31 10:46 ---
Subject: Bug 28671
Author: bkoz
Date: Thu Aug 31 10:45:59 2006
New Revision: 116601
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116601
Log:
2006-08-31 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-08-31 16:59
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from bkoz at gcc dot gnu dot org 2006-08-31 22:20 ---
Subject: Bug 28671
Author: bkoz
Date: Thu Aug 31 22:20:09 2006
New Revision: 116608
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116608
Log:
2006-08-31 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #13 from bkoz at gcc dot gnu dot org 2006-08-28 09:49 ---
Just a note.
The current behavior is as intended, although perhaps not documented. I'll be
fixing that later today.
Here's a message from last month detailing in advance this exact bug report:
--- Comment #14 from pcarlini at suse dot de 2006-08-28 09:58 ---
(In reply to comment #13)
The real issue is: code independent from the atomicity model. The only way
to have this is to not inline the atomic helper functions in atomicity.h. I am
willing to revert that part of my
--- Comment #15 from pcarlini at suse dot de 2006-08-28 10:02 ---
(In reply to comment #14)
Sorry about my crazy english today, I'm concentrated on something else...
Unfortunately, for targets like ?386 and Sparc I'm afraid it's the only
option, at the moment. For ia64, powerpc,
--- Comment #11 from bonzini at gnu dot org 2006-08-25 07:09 ---
Hmm, the test in GLIBCXX_ENABLE_ATOMIC_BUILTINS seems simple enough (testing
for __sync_fetch_and_add support) that the compiler should provide it as a
preprocessor symbol.
If you move
--- Comment #12 from pcarlini at suse dot de 2006-08-25 08:08 ---
(In reply to comment #11)
Hmm, the test in GLIBCXX_ENABLE_ATOMIC_BUILTINS seems simple enough (testing
for __sync_fetch_and_add support) that the compiler should provide it as a
preprocessor symbol.
Yes, and a patch
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
--- Comment #9 from tim at klingt dot org 2006-08-17 09:43 ---
i have the same problem on my machine, using the latest snapshot.
i'm not sure, if the following information is helpful, but gcc -v gives me:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
--- Comment #10 from pcarlini at suse dot de 2006-08-17 18:40 ---
Don't worry, the problem will be *certainly* resolved in time for the release:
the issue is clear, we know in detail what's going wrong and how to fix it.
Benjamin will.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 22:51 ---
What options are being used to compile the software with?
if -march=i386, then this is not a bug with the compiler.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from bero at arklinux dot org 2006-08-09 22:54 ---
-O2 -march=i586 -mcpu=i686 -fomit-frame-pointer
--
bero at arklinux dot org changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2006-08-09 23:08 ---
First, a general remark: this kind of error must never happen, irrespective of
the options used to build user code and/or GCC.
Then, it looks like _GLIBCXX_ATOMIC_BUILTINS is defined for that installation
of GCC. In turn,
--- Comment #4 from pcarlini at suse dot de 2006-08-09 23:30 ---
One additional remark: if the entire software package is really built with
-march=i586, then, in any case, the __sync_fetch_and_add call at line 47 of
atomicity.h is expanded in line and the link problem cannot occur as
--- Comment #5 from pcarlini at suse dot de 2006-08-09 23:48 ---
Benjamin, in case this problem is confirmed (and some strange details of the PR
are sorted out), can you please double check that we are not incurring in the
issue I was fearing here:
--- Comment #6 from bero at arklinux dot org 2006-08-09 23:55 ---
Ok, misunderstanding about the compiler flags -- -march=i586 was used to build
the compiler, strigi was built without any -march= tags (making the default
i386, I guess).
Using -march=i586 in strigi makes the problem go
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-09 23:58 ---
Can you give your exact commands use to build GCC?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pcarlini at suse dot de 2006-08-10 00:05 ---
(In reply to comment #6)
Ok, misunderstanding about the compiler flags -- -march=i586 was used to build
the compiler, strigi was built without any -march= tags (making the default
i386, I guess).
Using -march=i586 in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
21 matches
Mail list logo
