[Bug middle-end/43760] New: [4.6 regression] New test failures

[Bug middle-end/43760] New: [4.6 regression] New test failures

[hjl dot tools at gmail dot com]

On Linux/ia64, revision 158361 gave:

FAIL: 23_containers/deque/operators/1.cc (test for excess errors)
FAIL: gfortran.dg/array_constructor_23.f  -O2  (test for excess errors)
FAIL: gfortran.dg/array_constructor_24.f  -O2  (test for excess errors)

Revision 158345 is OK.


-- 
           Summary: [4.6 regression] New test failures
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl dot tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760

[Bug middle-end/43760] [4.6 regression] New test failures

[rguenth at gcc dot gnu dot org]

-- 

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

[Bug middle-end/43760] [4.6 regression] New test failures

[sje at cup dot hp dot com]

------- 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

[Bug middle-end/43760] [4.6 regression] New test failures

[wilson at gcc dot gnu dot org]

------- 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

[Bug middle-end/43760] [4.6 regression] New test failures

[sje at cup dot hp dot com]

------- 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

[Bug middle-end/43760] [4.6 regression] New test failures

[wilson at codesourcery dot com]

------- 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

[Bug middle-end/43760] [4.6 regression] New test failures

[wilson at gcc dot gnu dot org]

------- 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

[Bug middle-end/43760] [4.6 regression] New test failures

[rguenth at gcc dot gnu dot org]

------- 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

[Bug middle-end/43760] [4.6 regression] New test failures

[sje at cup dot hp dot com]

------- 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

[Bug middle-end/43760] [4.6 regression] New test failures

[sje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760

--- Comment #8 from Steve Ellcey <sje at gcc dot gnu.org> 2010-10-18 21:34:51 UTC ---
Author: sje
Date: Mon Oct 18 21:34:46 2010
New Revision: 165664

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165664
Log:
2010-10-18  Steve Ellcey  <sje@cup.hp.com>

    PR target/36898
    PR middle-end/43760
    * config/ia64/ia64.c (rws_access_regno): Remove predicate check.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/ia64/ia64.c

[Bug middle-end/43760] [4.6 regression] New test failures

[sje at cup dot hp.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760

Steve Ellcey <sje at cup dot hp.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED

--- Comment #9 from Steve Ellcey <sje at cup dot hp.com> 2010-10-18 21:48:17 UTC ---
Resolved by making IA64 more conservative in its bundling and not putting
multiple (predicated) instructions in one bundle if they read/write the same
register.