This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/53975] New: [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction


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

             Bug #: 53975
           Summary: [ia64] Target register of a speculative load moved to
                    a branch register prior to the chk.s instruction
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@jermar.eu


When building HelenOS/ia64 with gcc 4.7.1, we hit a problem in this code
sequence:

 4404570:       09 70 00 42 38 10       [MMI]       ld8.s r14=[r33]
 4404576:       a0 04 90 70 20 20                   ld8.s r74=[r36]
 440457c:       19 00 00 90                         mov r73=1;;
 4404580:       11 38 00 10 06 39       [MIB]       cmp.eq p7,p6=0,r8
 4404586:       60 70 04 80 83 03                   mov b6=r14
 440458c:       a0 fd ff 4b                   (p07) br.cond.dpnt.few 4404320
<printf_core+0x19e0>;;
 4404590:       c2 40 8a 19 00 21       [MII] (p06) adds r72=98,r12
 4404596:       00 00 00 02 00 40                   nop.i 0x0;;
 440459c:       a3 04 00 01                         chk.s.i r74,4404730
<printf_core+0x1df0>
 44045a0:       08 b8 38 00 40 04       [MMI]       chk.s.m r14,4404710
<printf_core+0x1dd0>
 44045a6:       00 00 00 02 00 00                   nop.m 0x0
 44045ac:       00 00 04 00                         nop.i 0x0
 44045b0:       11 00 00 00 01 00       [MIB]       nop.m 0x0
 44045b6:       00 00 00 02 00 00                   nop.i 0x0
 44045bc:       68 00 80 10                         br.call.sptk.many b0=b6;;

Note that r14 is loaded speculatively and thus can have its NaT bit set as a
result of a deferred exception. This is checked and, if necessary, recovered by
the chk.s instruction at 0x44045a0. The problem seems to be that r14 is moved
to b6 at 0x4404586 prior to the chk.s instruction. If r14 indeed has the NaT
bit set, the instruction will generate the NaT Consumption vector exception.
Seems to me that the mov b6=r14 instruction should have been scheduled only
after the chk.s instruction when we are sure r14's NaT is cleared.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]