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 c/66660] New: [ia64] Speculative load not checked before use, leading to a NaT Consumption Vector interruption


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66660

            Bug ID: 66660
           Summary: [ia64] Speculative load not checked before use,
                    leading to a NaT Consumption Vector interruption
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at jermar dot eu
  Target Milestone: ---

Created attachment 35848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35848&action=edit
Reproducible test case.

I hit what appears to be a bug in handling speculative loads on Itanium in GCC
5.1.0. I am going to attach a simplified testcase derived from the latest
HelenOS sources, which reproduces the issue.

In the Ski IA-64 simulator running HelenOS, I can see the following sequence of
events wrt. r23:

 4407ff0:       09 b0 00 00 00 21       [MMI]       mov r22=r0
 4407ff6:       70 01 88 70 20 00                   ld8.s r23=[r34]     <=====
speculative load, sets the NaT bit for r23
 4407ffc:       e0 08 2a 00                         mov.i ar.lc=14;;
 4408000:       02 00 00 00 01 00       [MII]       nop.m 0x0
 4408006:       60 01 58 22 00 00                   zxt2 r22=r22;;
 440800c:       82 78 20 79                         shl r16=r8,r15
 4408010:       03 00 00 00 01 00       [MII]       nop.m 0x0
 4408016:       f0 78 38 80 3c e0                   shr.u r15=r14,r15;;
 440801c:       01 78 44 00                         zxt2 r15=r15;;
 4408020:       18 70 fc 21 3f 23       [MMB]       adds r14=-1,r16
 4408026:       00 78 74 10 23 00                   st2 [r29]=r15
 440802c:       00 00 00 20                         nop.b 0x0
 4408030:       01 00 50 34 98 11       [MII]       st8 [r26]=r20
 4408036:       50 11 3c 3c 29 60                   extr.u r21=r15,1,31
 440803c:       12 78 b0 80                         and r19=1,r15;;
 4408040:       0b c8 64 1c 0c 20       [MMI]       and r25=r25,r14;;
 4408046:       00 00 00 02 00 c0                   nop.m 0x0
 440804c:       01 c8 44 00                         zxt2 r14=r25;;
 4408050:       08 00 00 00 01 00       [MMI]       nop.m 0x0
 4408056:       60 72 98 00 40 00                   add r38=r14,r38
 440805c:       00 00 04 00                         nop.i 0x0
 4408060:       03 70 00 22 38 10       [MII]       ld8.s r14=[r17]
 4408066:       00 00 00 02 00 20                   nop.i 0x0;;
 440806c:       05 30 59 00                         sxt4 r41=r38;;
 4408070:       08 00 00 00 01 00       [MMI]       nop.m 0x0
 4408076:       00 00 00 02 00 00                   nop.m 0x0
 440807c:       00 00 04 00                         nop.i 0x0
 4408080:       09 80 00 24 38 10       [MMI]       ld8.s r16=[r18]
 4408086:       00 00 00 02 00 c0                   nop.m 0x0
 440808c:       00 a0 1c e4                         cmp.eq p6,p7=0,r20;;
 4408090:       f1 a0 fc 29 3f 23       [MIB] (p07) adds r20=-1,r20
 4408096:       00 00 00 02 80 03                   nop.i 0x0
 440809c:       a0 00 00 43                   (p07) br.cond.dpnt.few 4408130
<inflate_codes+0x7f0>;;
...
 4408130:       01 00 00 00 01 00       [MII]       nop.m 0x0
 4408136:       f0 00 54 22 00 00                   zxt2 r15=r21
 440813c:       32 b1 38 80                         or r16=r19,r22;;
 4408140:       00 00 3c 3a 88 11       [MII]       st2 [r29]=r15
 4408146:       60 81 f8 9c 29 00                   dep.z r22=r16,1,15
 440814c:       02 80 44 00                         zxt2 r16=r16
 4408150:       18 00 50 34 98 11       [MMB]       st8 [r26]=r20
 4408156:       00 00 00 02 00 00                   nop.m 0x0
 440815c:       00 00 00 20                         nop.b 0x0
 4408160:       11 00 00 00 01 00       [MIB]       nop.m 0x0
 4408166:       70 b9 60 00 40 00                   add r23=r23,r24     <=====
NaT bit not yet consumed
 440816c:       30 00 00 40                         br.few 4408190
<inflate_codes+0x850>;;
...
 4408190:       10 00 00 00 01 00       [MIB]       nop.m 0x0
 4408196:       60 01 58 22 00 00                   zxt2 r22=r22
 440819c:       00 00 00 20                         nop.b 0x0
 44081a0:       09 b8 00 2e 08 10       [MMI]       ld2 r23=[r23]       <=====
NaT consumption vector

In short, after doing the speculative load to r23, a conditional branch is
taken to code path which uses the speculatively-loaded register without first
running chk.s on it. So if the register has a NaT bit set (such as after a
deferred exception), there is going to be the NaT consumption vector
interruption on address 44081a0 above.

The issue did not show with GCC 4.8.1, but shows with GCC 5.1.0. Don't know
about the versions in between. The issue is also somewhat similar to an already
fixed Bug ID #53975. The same workaround applies, i.e.
-fno-selective-scheduling -fno-selective-scheduling2 will prevent the bug from
occurring.


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