locked
fatal error C1001: An internal error has occurred in the compiler

    Question

  • I have been working on a plugin that does many transformations, including loop tiling. The Execute function runs to completion and dies while exiting with the following error:

    fatal error C1001: An internal error has occurred in the compiler.
    (compiler file 'd:\enlistments\sdk_march08\src\clients\c2\c2-diagnostics.cpp', line 690)
    Access Violation Fault (instruction at "0x305FDDD4" read memory at "0x00000038")

    If I debug it in VS it gives the following while exiting:

    A first chance exception of type 'System.InvalidCastException' occurred in phxd.dll
    'cl.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System.Windows.Forms\2.0.0.0__b77a5c561934e089\System.Windows.Forms.dll'
    'cl.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System.Drawing\2.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll'
    The program '[1288] cl.exe: Managed' has exited with code 1 (0x1).

    I would be more than happy to attach files and binaries to aid in debugging this issue, but I don't know what needs to be generated and how.

     

    Thank you,

    Sain

    Tuesday, April 22, 2008 4:13 PM

Answers

  • One thing I noticed -- when you construct your memory operands you are not giving them valid alias tags. Instead you're passing in Phx::Alias::Constants::InvalidTag, which shows up in the call stack as the 0 valued tag, and the alias package rightly complains.

     

    You need to pass something valid here. If you're not sure what to use, use functionUnit->AliasInfo->AllMemoryTag.

    Friday, April 25, 2008 8:54 PM
    Moderator

All replies

  • Well, I can only guess. But my guess is probably that you have generated or modified the IR incorrectly, so later on when optimizations or lowering occurs it assumes a type is of some type which it is not, causing the invalid cast exception. Can you turn off all your transformations and see if it repros? If not, then we can work on finding out what you are doing exactly that is exposing this problem in the framework or maybe in your plugin. If it repros with everything off (eg, you simply do nothing in your plugin) it woudl be good to look at your input files as it would be a backend c2 issue.

    Tuesday, April 22, 2008 11:35 PM
    Moderator
  • Hello Lin,

     

    Thank you for the advice. I had to deal with some type issues and I'm not sure if I did so correctly. That might be the problem.

     

    I am still in the process of trying to narrow down the problem. However, I noticed that the debug version of the DLLs are giving me a lot more problems than the release version. For example, after eliminating most of my transformations, I still get many Assertion Failures and the following when using the debug version while the release goes through fine.

     

    Consistency check failures after EM-CUDA
       Instruction has an invalid debug tag
                                 GOTO $L10                                             #0
       Use operand's instruction is not linked in the function
          $L11
                                 CONDITIONALBRANCH(True) tv304-, $L11, $L10            #0
       Use operand's instruction is not linked in the function
          $L10
                                 CONDITIONALBRANCH(True) tv304-, $L11, $L10            #0
    Phoenix Assertion Failure: d:\enlistments\sdk_march08\src\phx\ir\ir-check.cpp, Line 1954
      !this->HaveEmittedDiagnostic : Consistency check failures
      in (Function number 3) ?kernel@@YAXUdim3@@0PAM1@Z [line 0] during EM-CUDA
      in (Module) main.cpp

     

    What I had done was to replace a Conditional Branch instruction with a Goto, like so:

     

    Replace

                           CONDITIONALBRANCH(True) t304, $L11, $L10             #61
    with

                           GOTO $L10                                             #0

    I created a new BranchInstruction for the Goto instruction, inserted it before the existing Condition Branch, and then deleted the Conditional Branch instruction with Instruction->Remove() 

     

    Again, thank you for your help.

    Sain

    Wednesday, April 23, 2008 3:45 PM
  • I managed to narrow it down to the addition of this Instruction, garrayToSharedCopyInstr:

     

    Code Snippet

        Operand ^sharedMemOffsetMemOperand = MemoryOperand::New
          (functionUnit, functionUnit->TypeTable->Pointer32Type,
           nullptr, (VariableOperand ^) sharedMemOffsetOperand,
           0, align, Phx::Alias::Constants::InvalidTag,
           Phx::Safety::Tag());

     

        Operand ^newGarrayAccMemOperand = MemoryOperand::New
          (functionUnit, functionUnit->TypeTable->Pointer32Type,
           nullptr,
           (VariableOperand ^) newGarrayAccOperand,
           0, align, Phx::Alias::Constants::InvalidTag,
           Phx::Safety::Tag());

     

        Instruction ^garrayToSharedCopyInstr =
          ValueInstruction::NewUnary
          (functionUnit, Phx::Common::Opcode::Assign,
           sharedMemOffsetMemOperand, newGarrayAccMemOperand);
        coalesceBodyBlock->LastInstruction->InsertBefore
          (garrayToSharedCopyInstr);

     

     


     

    I've calculated offsets to 2 seperate arrays and stored them as sharedMemOffsetOperand and newGarrayAccOperand. I then want to load the value pointed to by newGarrayAccOperand and store it into the location pointed to by sharedMemOffsetOperand. So I figured I have to create MemoryOperands based on them. Or

     

       [sharedMemOffsetOperand]      = ASSIGN [GarrayAccOperand]                                  #65

     

    It gives the following error in debug:

    A first chance exception of type 'System.NullReferenceException' occurred in phxd.dll

    A first chance exception of type 'Phx.FatalError' occurred in phxd.dll

     

    And the following error in release:

    fatal error C1001: An internal error has occurred in the compiler.
    (compiler file 'd:\enlistments\sdk_march08\src\clients\c2\c2-diagnostics.cpp', line 690)
    Access Violation Fault (instruction at "0x305FDDD4" read memory at "0x00000038")

     

    Thank you,

    Sain

    Wednesday, April 23, 2008 9:27 PM
  • Can you get a call stack for the null reference expection?  This should narrow down the problem considerably.  In the meantime, I will try to get a repro locally.

    Wednesday, April 23, 2008 11:35 PM
  • Following is the call stack when Phoenix stops after exiting my plugin. Hope it is of help. Thank you again for looking into this.

     

     

    > c2.dll!C2::WorkItem::Execute() Line 6022 C++
      [Native to Managed Transition] 
      [Managed to Native Transition] 
      phxd.dll!Phx.Alias.Info.GetAliasType(int tag = 0) + 0x82 bytes 
      phxd.dll!Phx.Alias.FactorAnalyzer.ComputeProxyClosure(Phx.FunctionUnit functionUnit = {?kernel@@YAXUdim3@@0PAM1@Z (State: Hir)}) + 0x129 bytes 
      phxd.dll!Phx.SSA.Info.CollectBaseFlowInfo(Phx.SSA.Attribute ssaAttribute = Aliased) + 0x13b bytes 
      phxd.dll!Phx.SSA.Info.Build() + 0x37 bytes 
      c2.dll!C2::Warnings::FlowAnalysis::Initialize(Phx::FunctionUnit^ functionUnit = 0x016f8af8) Line 296 + 0x18 bytes C++
      c2.dll!C2::Warnings::FlowAnalysis::Run(Phx::FunctionUnit^ functionUnit = 0x016f8af8) Line 545 C++
      c2.dll!C2::Warnings::WarningsPhase::Execute(Phx::Unit^ unit = 0x016f8af8) Line 127 C++
      phxd.dll!Phx.Phases.Phase.DoPhase(Phx.Unit unit = {?kernel@@YAXUdim3@@0PAM1@Z (State: Hir)}) + 0xe8 bytes 
      phxd.dll!Phx.Phases.PhaseList.DoPhaseList(Phx.Unit unit = {?kernel@@YAXUdim3@@0PAM1@Z (State: Hir)}) + 0x35 bytes 
      c2.dll!C2:Big Smileriver::ReadFunction(Phx::ModuleUnit^ moduleUnit = 0x015fac90, Phx::CxxIL::FunctionInfoExtensionObject^ functionExtensionObject = 0x01629b70, int functionCount = 3) Line 1016 C++
      c2.dll!C2::WorkItem::RealExecute() Line 6088 + 0x28 bytes C++
      c2.dll!C2::WorkItem::TryExecute() Line 6044 C++
      c2.dll!C2::WorkItem::Execute() Line 6020 + 0x8 bytes C++
      c2.dll!C2:Big Smileriver::CompileFunctions() Line 3396 + 0x7 bytes C++
      c2.dll!C2::C2Pass::Execute(Phx::ModuleUnit^ moduleUnit = 0x015fac90) Line 6449 + 0x5 bytes C++
      phxd.dll!Phx.Passes.Pass.DoPass(Phx.ModuleUnit moduleUnit = {main.cpp}) + 0xcc bytes 
      phxd.dll!Phx.Passes.PassList.DoPassList(Phx.ModuleUnit moduleUnit = {main.cpp}) + 0x77 bytes 
      c2.dll!C2:Big Smileriver::CompileModule(Phx::ModuleUnit^ moduleUnit = 0x015fac90) Line 4496 + 0x1e bytes C++
      c2.dll!C2::C2Driver::Compile(int argc = 16, wchar_t** argv = 0x00BA1CE8, bool mustClosePdb = true) Line 5468 + 0xb bytes C++
      c2.dll!C2Main(int argc = 16, wchar_t** argv = 0x00BA1CE8, int fClosePDB = 1, HINSTANCE__** uiModuleHandle = 0x0041CFE8) Line 6906 + 0x23 bytes C++
      c2.dll!InvokeCompilerPassWorker(int argc = 16, wchar_t** argv = 0x00BA1CE8, int fClosePDB = 1, HINSTANCE__** hCLUIModule = 0x0041CFE8) Line 176 + 0x11 bytes C++
    Thursday, April 24, 2008 2:31 PM
  • Alright, it's not immediately apparent just from the call stack what the problem is.  Is there any way I can have the plugin project for debugging?  If not, I may be able to work with just a binary.

    Thursday, April 24, 2008 9:36 PM
  • One thing I noticed -- when you construct your memory operands you are not giving them valid alias tags. Instead you're passing in Phx::Alias::Constants::InvalidTag, which shows up in the call stack as the 0 valued tag, and the alias package rightly complains.

     

    You need to pass something valid here. If you're not sure what to use, use functionUnit->AliasInfo->AllMemoryTag.

    Friday, April 25, 2008 8:54 PM
    Moderator
  • Thanks Andy. The plugin now passes using the release DLLs with no problems. Debug DLLs still have issues, which might be from something else.

    Tuesday, April 29, 2008 3:41 PM
  • Well, I can only guess. But my guess is probably that you have generated or modified the IR incorrectly, so later on when optimizations or lowering occurs it assumes a type is of some type which it is not, causing the invalid cast exception. Can you turn off all your transformations and see if it repros? If not, then we can work on finding out what you are doing exactly that is exposing this problem in the framework or maybe in your plugin. If it repros with everything off (eg, you simply do nothing in your plugin) it woudl be good to look at your input files as it would be a backend c2 issue.


    I found that it is really the cause, Thanks for your help!
    Friday, January 28, 2011 10:24 PM