Skip to content

Test failure JIT\\Regression\\JitBlue\\Runtime_63354\\Runtime_63354\\Runtime_63354.cmd #78898

Closed

Description

@v-wenyuxu

Run: runtime-coreclr jitstress 20221126.2

Failed test:

coreclr windows x86 Checked jitstress1 @ Windows.10.Amd64.Open

- JIT\\Regression\\JitBlue\\Runtime_63354\\Runtime_63354\\Runtime_63354.cmd

coreclr windows x86 Checked jitstress1_tiered @ Windows.10.Amd64.Open

- JIT\\Regression\\JitBlue\\Runtime_63354\\Runtime_63354\\Runtime_63354.cmd

coreclr windows x86 Checked jitstress2 @ Windows.10.Amd64.Open

- JIT\\Regression\\JitBlue\\Runtime_63354\\Runtime_63354\\Runtime_63354.cmd

coreclr windows x86 Checked jitstress2_tiered @ Windows.10.Amd64.Open

- JIT\\Regression\\JitBlue\\Runtime_63354\\Runtime_63354\\Runtime_63354.cmd

Error message:

Assert failure(PID 2576 [0x00000a10], Thread: 5528 [0x1598]): Assertion failed '!m_VariableLiveRanges->back().m_EndEmitLocation.Valid()' in 'Runtime_63354:Test2(System.Numerics.Vector3):System.Numerics.Vector3' during 'Generate code' (IL size 52; hash 0x3273ce14; FullOpts)

File: D:\a\_work\1\s\src\coreclr\jit\codegencommon.cpp Line: 8795
Image: C:\h\w\9B6408B0\p\corerun.exe
Return code:      1
Raw output file:      C:\h\w\9B6408B0\w\A9090942\uploads\Reports\JIT.Regression\JitBlue\Runtime_63354\Runtime_63354\Runtime_63354.output.txt
Raw output:
BEGIN EXECUTION
"C:\h\w\9B6408B0\p\corerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false"  Runtime_63354.dll
Expected: 100
Actual: -1073740286
END EXECUTION - FAILED
FAILED
Test Harness Exitcode is : 1
To run the test:

set CORE_ROOT=C:\h\w\9B6408B0\p
C:\h\w\9B6408B0\w\A9090942\e\JIT\Regression\JitBlue\Runtime_63354\Runtime_63354\Runtime_63354.cmd
Expected: True
Actual:   False


Stack trace
   at JIT_Regression._JitBlue_Runtime_63354_Runtime_63354_Runtime_63354_._JitBlue_Runtime_63354_Runtime_63354_Runtime_63354_cmd()
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

Activity

  1. ghost added
    area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
    on Nov 28, 2022
  2. ghost added
    untriagedNew issue has not been triaged by the area owner
    on Nov 28, 2022
  3. added this to the 8.0.0 milestone on Nov 29, 2022
  4. ghost removed
    untriagedNew issue has not been triaged by the area owner
    on Nov 29, 2022
  5. BruceForstall commented on Nov 29, 2022

    @BruceForstall
    Contributor
  6. BrianBohe commented on Dec 1, 2022

    @BrianBohe
    Member

    I bisected this bug. It was introduced on #76491.

  7. BrianBohe commented on Dec 1, 2022

    @BrianBohe
    Member

    What is happening is we start a block with V01 arg0 in stack (ebp+08). It is copied to xmm1, indicating live and death. And then reporting the death again of the same variable in xmm1 for a second time without begin alive first.

  8. BrianBohe commented on Dec 1, 2022

    @BrianBohe
    Member

    We are reporting a variable as dying in xmm1, although previously saying the same. The first change of liveness happens after HWINSTRINSIC:

    Generating: N063 (  3,  2) [000050] ----------z                   t50 =    LCL_VAR   simd12<System.Numerics.Vector3> V01 arg0         u:3 mm1 (last use) REG mm1 $181
    Generating: N065 (???,???) [000104] -----------                  t104 =    CNS_VEC   simd16<0x00000000, 0x00000000, 0x00000000, 0x00000000> REG mm0
    IN0013:        vxorps   xmm0, xmm0, xmm0
    Generating: N067 (???,???) [000105] -c---------                  t105 =    CNS_INT   int    0 REG NA
                                                                            /--*  t50    simd12 
                                                                            +--*  t104   simd16 
                                                                            +--*  t105   int    
    Generating: N069 (  6,  6) [000052] -----------                   t52 = *  HWINTRINSIC simd16 float Insert REG mm1 $c1
    IN0014:        vmovupd  xmm1, xmmword ptr [V01 ebp+08H]
    							V01 in reg mm1 is becoming live  [000050]
    							Live regs: 000000C0 {esi edi} => 000000C0 {esi edi xmm1}
    							V01 in reg mm1 is becoming dead  [000050]
    							Live regs: 000000C0 {esi edi xmm1} => 000000C0 {esi edi}
    							Live vars: {V00 V01 V02} => {V00 V02}
    IN0015:        vinsertps xmm1, xmm1, xmm0, 0
                                                                            /--*  t52    simd16 
    Generating: N071 ( 10,  9) [000039] DA---------                         *  STORE_LCL_VAR simd12<System.Numerics.Vector3> V01 arg0         d:4 mm1 REG mm1
    IN0016:        vmovsd   qword ptr [V01 ebp+08H], xmm1 // Brian: Why not alive?
    IN0017:        vpshufd  xmm0, xmm1, 2
    IN0018:        vmovss   dword ptr [V01+0x8 ebp+10H], xmm0
    

    where before we modified the variable directly on stack:

    Generating: N063 (  1,  2) [000037] -----------                   t37 =    CNS_INT   int    0 REG eax
    IN0017:        xor      eax, eax
                                                                            /--*  t37    int    
    Generating: N065 (  5,  7) [000039] UA---------                         *  STORE_LCL_FLD int    V01 arg0         ud:3->4[+0] NA REG NA
    IN0018:        mov      dword ptr [V01 ebp+08H], eax
    
  9. SingleAccretion commented on Dec 1, 2022

    @SingleAccretion
    Contributor

    It looks suspect to me that genStoreLclTypeSIMD12 does not call genUpdateLife.

  10. BrianBohe commented on Dec 2, 2022

    @BrianBohe
    Member

    Calling to genProduceReg (which triggers genUpdateLife) after treenode 39 seems to solved it. What I don't get is, it is a store, and flags indicate it is becoming alive, but we are not updating varDsc with the stack position. It is still there the offset and the lvIsOnFrame set, but the register doesn't change back to STK and keeps XMM1. So reporting life change after that would say v01 is becoming alive in XMM1. The next instruction that triggers the assert is a load from the stack to xmm1 of the same variable, which indicates first it is dying

  11. SingleAccretion commented on Dec 2, 2022

    @SingleAccretion
    Contributor

    but we are not updating varDsc with the stack position

    That also looks like a bug in genStoreLclTypeSIMD12. It should do varDsc->SetRegNum(REG_STK);.

  12. added
    in-prThere is an active PR which will close this issue when it is merged
    on Dec 5, 2022
  13. ghost locked as resolved and limited conversation to collaborators on Jan 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

JitStressCLR JIT issues involving JIT internal stress modesarch-x86area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMIblocking-clean-ci-optionalBlocking optional rolling runsin-prThere is an active PR which will close this issue when it is mergedos-windows

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions