--- Comment #35 from schwab at suse dot de 2005-11-20 10:45 ---
Fixed.
--
schwab at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #34 from schwab at gcc dot gnu dot org 2005-11-20 10:44 ---
Subject: Bug 24757
Author: schwab
Date: Sun Nov 20 10:44:27 2005
New Revision: 107247
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107247
Log:
PR target/24757
* config/ia64/ia64.c (ia64_exp
--- Comment #33 from schwab at gcc dot gnu dot org 2005-11-20 10:43 ---
Subject: Bug 24757
Author: schwab
Date: Sun Nov 20 10:43:43 2005
New Revision: 107246
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107246
Log:
PR target/24757
* config/ia64/ia64.c (ia64_exp
--- Comment #32 from rth at gcc dot gnu dot org 2005-11-20 05:43 ---
Oh good grief. I can't see the forest for the trees. Andreas, I expect
that patch will work. If it tests ok, please commit it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
--- Comment #31 from schwab at suse dot de 2005-11-20 00:22 ---
Testing this patch:
Index: ia64.c
===
--- ia64.c (revision 107220)
+++ ia64.c (working copy)
@@ -2113,7 +2113,7 @@
emit_insn (GEN_FCN (icode) (cm
--- Comment #30 from pcarlini at suse dot de 2005-11-19 23:06 ---
Created an attachment (id=10298)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10298&action=view)
Further reduced, pure C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
--- Comment #29 from pcarlini at suse dot de 2005-11-19 23:02 ---
(In reply to comment #28)
> I'll try to add an alignment attribute to the _Atomic_word typedef, as cris
> is already doing for instance, and see whether something changes for the
> better.
Nope. Maybe the alignment is for
--- Comment #28 from pcarlini at suse dot de 2005-11-19 22:45 ---
Thanks Richard G. In fact, from time to time I saw warnings on the shell,
which really puzzled me, because I was sure that no alignment issues were
present anymore in the higher lever library code proper.
I'll try to add
--- Comment #27 from rguenth at gcc dot gnu dot org 2005-11-19 22:38
---
The only thing in the pthread3_reduced.cc testcase that could make it going
wrong is wrong alignment of aw. And I remember seeing a lot of unaligned traps
in dmesg during libstdc++ testing on ia64.
--
http://
--- Comment #26 from pcarlini at suse dot de 2005-11-19 22:12 ---
Created an attachment (id=10297)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10297&action=view)
Reduced from thread/pthread3
Richard, I'm attaching a really minimal testcase, which fails very quickly
for me with m
--- Comment #25 from pcarlini at suse dot de 2005-11-19 02:33 ---
(In reply to comment #23)
> And it does appear to change the behaviour of one of the testsuite tests,
> but it doesn't fix both of them. I'll claim, then, that it didn't fix either
> of them, but merely changed the timing
--- Comment #24 from pcarlini at suse dot de 2005-11-19 02:15 ---
(In reply to comment #23)
> Created an attachment (id=10289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10289&action=view) [edit]
> mf hack
>
> For the record, here's the aforementioned hack.
Ok, thanks. Over th
--- Comment #23 from rth at gcc dot gnu dot org 2005-11-19 02:09 ---
Created an attachment (id=10289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10289&action=view)
mf hack
For the record, here's the aforementioned hack.
And it does appear to change the behaviour of one of the
--- Comment #22 from mmitchel at gcc dot gnu dot org 2005-11-19 02:08
---
I think we need to understand this problem before we release. It might be that
we downgrade the priority if it turns out to be a problem outside our control.
--
mmitchel at gcc dot gnu dot org changed:
--- Comment #21 from pcarlini at suse dot de 2005-11-19 01:08 ---
Just in case, those are ready to use outside the testsuite... For me,
especially
the second one, fails very quickly and consistently on 4-way and 16-way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
--- Comment #20 from pcarlini at suse dot de 2005-11-19 01:06 ---
Created an attachment (id=10288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10288&action=view)
Slightly hacked, self contained test (for use outside the testsuite)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #19 from pcarlini at suse dot de 2005-11-19 01:05 ---
Created an attachment (id=10287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10287&action=view)
Slightly hacked, self contained test (for use outside the testsuite)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #18 from rth at gcc dot gnu dot org 2005-11-19 00:56 ---
Dammit, lemme try again; I patched a different tree than I tested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
--- Comment #17 from pcarlini at suse dot de 2005-11-18 23:41 ---
(In reply to comment #16)
> Alex's explanation can't be all of it. I hacked the compiler to emit two
> "mf" instructions before and after the sequence here, and it made no
> difference to the two tests failing. I really
--- Comment #16 from rth at gcc dot gnu dot org 2005-11-18 23:32 ---
Alex's explanation can't be all of it. I hacked the compiler to emit two
"mf" instructions before and after the sequence here, and it made no
difference to the two tests failing. I really have no idea what's going on.
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-18 15:35
---
See also:
http://www.linuxbase.org/spec/refspecs/IA64-softdevman-vol1.pdf
Page73.
Which is where the comment in comment #13. So If I read table 4-20 currently
then the memory access will always be ordered in th
--- Comment #14 from pcarlini at suse dot de 2005-11-18 15:32 ---
I'm not sure that specific patch is the culprit, because (see Comment #5) the
threaded testcases started failing before that date. I would like to see the
assembly before and after that date. In any case, it would be nice
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-18 15:29
---
(In reply to comment #12)
> Yes but I trust RTH better than Alexander on this issue.
And if you read the message which I pointed to:
The semaphore instructions also have implicit ordering.
So if I am reading this
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-18 15:27
---
(In reply to comment #10)
> Did you read the last message from Alexander on the libstdc++ mailing list, in
> particular the last paragraph?
Yes but I trust RTH better than Alexander on this issue.
--
http://gc
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-18 15:24
---
(In reply to comment #9)
> I should note that
> ld.acq+cmpxchg.rel is a full barrier.
> as noted in ia64.c so a mf is not required.
If that is really the issue, then
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg
--- Comment #10 from pcarlini at suse dot de 2005-11-18 15:23 ---
(In reply to comment #9)
> I should note that
> ld.acq+cmpxchg.rel is a full barrier.
> as noted in ia64.c so a mf is not required.
Did you read the last message from Alexander on the libstdc++ mailing list, in
particula
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-18 15:20 ---
I should note that
ld.acq+cmpxchg.rel is a full barrier.
as noted in ia64.c so a mf is not required.
See also http://www.ussg.iu.edu/hypermail/linux/kernel/0205.1/0226.html
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #8 from pcarlini at suse dot de 2005-11-17 13:50 ---
I have got additional evidence that __sync_fetch_and_add does not work
correctly. If, for example, in this code, stressed in the testcase
12658_thread-1.cc, and using atomic operations:
const locale&
locale::operator
--- Comment #7 from pcarlini at suse dot de 2005-11-10 09:59 ---
I'm marking this as a 4.1 Regression: certainly it is. If people can figure a
way to workaround it at the library level, I'm ok with that.
--
pcarlini at suse dot de changed:
What|Removed
29 matches
Mail list logo
