* [Bug middle-end/43760] [4.6 regression] New test failures
2010-04-15 14:08 [Bug middle-end/43760] New: [4.6 regression] New test failures hjl dot tools at gmail dot com
@ 2010-04-15 14:17 ` rguenth at gcc dot gnu dot org
2010-04-19 21:31 ` sje at cup dot hp dot com
` (6 subsequent siblings)
7 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-04-15 14:17 UTC (permalink / raw)
To: gcc-bugs
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
GCC target triplet| |ia64-linux
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/43760] [4.6 regression] New test failures
2010-04-15 14:08 [Bug middle-end/43760] New: [4.6 regression] New test failures hjl dot tools at gmail dot com
2010-04-15 14:17 ` [Bug middle-end/43760] " rguenth at gcc dot gnu dot org
@ 2010-04-19 21:31 ` sje at cup dot hp dot com
2010-04-19 23:28 ` wilson at gcc dot gnu dot org
` (5 subsequent siblings)
7 siblings, 0 replies; 11+ messages in thread
From: sje at cup dot hp dot com @ 2010-04-19 21:31 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from sje at cup dot hp dot com 2010-04-19 21:30 -------
/var/tmp//ccGMk41W.s: Assembler messages:
/var/tmp//ccGMk41W.s:201: Warning: Use of 'mov' may violate WAW dependency
'GR%, % in 1 - 127' (impliedf), specific resource number is 18
/var/tmp//ccGMk41W.s:201: Warning: Only the first path encountering the
conflict is reported
/var/tmp//ccGMk41W.s:200: Warning: This is the location of the conflicting
usage
It looks like this is PR 36898. The warning is bogus in the sense that there
is no real WAW dependency conflict but the assembler isn't able to figure that
out on it's own without some help with better .pred.rel.mutex lines from the
compiler.
--
sje at cup dot hp dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sje at cup dot hp dot com
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2010-04-19 21:30:40
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/43760] [4.6 regression] New test failures
2010-04-15 14:08 [Bug middle-end/43760] New: [4.6 regression] New test failures hjl dot tools at gmail dot com
2010-04-15 14:17 ` [Bug middle-end/43760] " rguenth at gcc dot gnu dot org
2010-04-19 21:31 ` sje at cup dot hp dot com
@ 2010-04-19 23:28 ` wilson at gcc dot gnu dot org
2010-04-20 0:01 ` sje at cup dot hp dot com
` (4 subsequent siblings)
7 siblings, 0 replies; 11+ messages in thread
From: wilson at gcc dot gnu dot org @ 2010-04-19 23:28 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from wilson at gcc dot gnu dot org 2010-04-19 23:28 -------
gcc-c.torture/compiler/920625-1.c would also be failing for the same reason,
except it has dg-prune-output hacks to discard the assembler warnings. We
should fix the IA-64 compiler, and then eliminate these dg-prune-output hacks
in this testcase.
--
wilson at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wilson at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/43760] [4.6 regression] New test failures
2010-04-15 14:08 [Bug middle-end/43760] New: [4.6 regression] New test failures hjl dot tools at gmail dot com
` (2 preceding siblings ...)
2010-04-19 23:28 ` wilson at gcc dot gnu dot org
@ 2010-04-20 0:01 ` sje at cup dot hp dot com
2010-04-20 1:55 ` wilson at codesourcery dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 11+ messages in thread
From: sje at cup dot hp dot com @ 2010-04-20 0:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from sje at cup dot hp dot com 2010-04-20 00:01 -------
Any ideas on how to fix the compiler? The best idea I could come up with was
to check each basic block to see if there are any conditional sets of predicate
registers in it and add pred.rel.mutex lines for those registers. If we add
pred.rel.mutex lines for all used predicate registers we wind up adding a lot
of unneeded pred.rel.mutex statements.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/43760] [4.6 regression] New test failures
2010-04-15 14:08 [Bug middle-end/43760] New: [4.6 regression] New test failures hjl dot tools at gmail dot com
` (3 preceding siblings ...)
2010-04-20 0:01 ` sje at cup dot hp dot com
@ 2010-04-20 1:55 ` wilson at codesourcery dot com
2010-04-26 15:47 ` wilson at gcc dot gnu dot org
` (2 subsequent siblings)
7 siblings, 0 replies; 11+ messages in thread
From: wilson at codesourcery dot com @ 2010-04-20 1:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from wilson at codesourcery dot com 2010-04-20 01:54 -------
Subject: Re: [4.6 regression] New test failures
On Tue, 2010-04-20 at 00:01 +0000, sje at cup dot hp dot com wrote:
> Any ideas on how to fix the compiler? The best idea I could come up with was
> to check each basic block to see if there are any conditional sets of predicate
> registers in it and add pred.rel.mutex lines for those registers. If we add
> pred.rel.mutex lines for all used predicate registers we wind up adding a lot
> of unneeded pred.rel.mutex statements.
I haven't had a chance to look at all of the details yet.
I believe that we only need to handle the case when one mutex pair is
used to create another one, e.g. something like
(p17) cmp.geu p6, p7 = r42, r51
(p16) cmp.gtu p6, p7 = r42, r51
We also only need to handle the case where we have a call-clobbered
mutex pair, e.g. p6/p7 in this case, and there was a call insn in
between here and any previous set of p6/p7.
Currently, we only insert pred.rel.mutex lines at the beginning of basic
blocks that start with labels. So now we also need to emit them after
such sequences, or alternatively after calls.
I'm not sure if the assembler is wrong here. mutex just means that we
will never have both p16 and p17 set at the same time. So there are 3
possibilities, p16 true, p17 true, neither true. If p16 is true, then
clearly p6/p7 will be mutex. Likewise if p17 is true. But if neither
is true, then p6/p7 will be unmodified, and hence aren't guaranteed to
be mutex unless they were already mutex before these lines. This is why
it only fails when we have a call-clobbered mutex pair after an
intervening call, as now we don't know anything about the previous
values of p6/p7.
If we know that p16/p17 were set in a simple compare, then we will know
that 1 and only 1 will be true, which is a stronger condition than
mutex, and in this case p6/p7 will be mutex. There is no
standard .pred.rel syntax for this though, which means that if the
p16/p17 set was in a different basic block, and we have only
the .pred.rel.mutex line inserted by the compiler, then the assembler
can't prove that p6/p7 will be mutex after this point. I'm not eager to
extend the assembler syntax to fix this, and rewrite the DV code in the
assembler, so I'm hoping that we can fix it in the compiler by emitting
another .pred.rel.mutex line in this case. This hopefully doesn't
happen too often and isn't too hard.
OK, maybe I have studied it a little, but I need to look at this a bit
more before I'm sure I understand everything that is going on here.
Jim
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/43760] [4.6 regression] New test failures
2010-04-15 14:08 [Bug middle-end/43760] New: [4.6 regression] New test failures hjl dot tools at gmail dot com
` (4 preceding siblings ...)
2010-04-20 1:55 ` wilson at codesourcery dot com
@ 2010-04-26 15:47 ` wilson at gcc dot gnu dot org
2010-09-02 10:36 ` rguenth at gcc dot gnu dot org
2010-09-02 18:27 ` sje at cup dot hp dot com
7 siblings, 0 replies; 11+ messages in thread
From: wilson at gcc dot gnu dot org @ 2010-04-26 15:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from wilson at gcc dot gnu dot org 2010-04-26 15:46 -------
Created an attachment (id=20495)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20495&action=view)
initial patch
This patch fixes gcc.c-torture/compile/920625-1.c, but unfortunately doesn't
fix any of the 3 failures reported in this PR. I will have to revise it and
try again. I also noticed that we had support for an obsolete assembler errata
warning, and removed that too in this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/43760] [4.6 regression] New test failures
2010-04-15 14:08 [Bug middle-end/43760] New: [4.6 regression] New test failures hjl dot tools at gmail dot com
` (5 preceding siblings ...)
2010-04-26 15:47 ` wilson at gcc dot gnu dot org
@ 2010-09-02 10:36 ` rguenth at gcc dot gnu dot org
2010-09-02 18:27 ` sje at cup dot hp dot com
7 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-09-02 10:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-02 10:36 -------
So this is, after all, an assembler bug and not a GCC bug?
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/43760] [4.6 regression] New test failures
2010-04-15 14:08 [Bug middle-end/43760] New: [4.6 regression] New test failures hjl dot tools at gmail dot com
` (6 preceding siblings ...)
2010-09-02 10:36 ` rguenth at gcc dot gnu dot org
@ 2010-09-02 18:27 ` sje at cup dot hp dot com
7 siblings, 0 replies; 11+ messages in thread
From: sje at cup dot hp dot com @ 2010-09-02 18:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from sje at cup dot hp dot com 2010-09-02 18:26 -------
I wonder if we should attack this from a different angle. We have been trying
to make the .pred.mutex.rel info more accurate to avoid this warning. If we
can't do that I wonder if we should make GCC more conservative about doing two
predicated writes in a single instruction group. This would make the code
slower but it might be an infrequent enough occurance that it doesn't matter.
Also, I currently see gfortran.dg/maxlocval_3.f90 failing with this message and
when I look at the assembly code, there are two predicated writes that are
using two consecutive pr registers (p12 and p13) but they are not set in a
single cmp instructions. They are set seperately and I believe that both could
be true which would mean that we are generating invalid code.
I am going to test a patch that changes rws_access_regno to not allow two
predicated register write in the same instruction group.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
^ permalink raw reply [flat|nested] 11+ messages in thread