LI75066: INTERNAL COMPILER ERROR IN XLCENTRY WITH ASM

October 2009 Update for XL C/C++ for Linux, V10.1
June 2011 Update for XL C/C++ for Linux, V10.1
XL C/C++ for Linux Fix Pack 8 (January 2014 Update) for 10.1
August 2010 Update for XL C/C++ for Linux, V10.1
January 2011 Update for XL C/C++ for Linux, V10.1
January 2012 Update for XL C/C++ for Linux, V10.1
July 2012 Update for XL C/C++ for Linux, V10.1

APAR status

• Closed as program error.

Error description

• The following test case results the compiler to abend:
  
  Compile line:
  xlc++ -c test.C
  
  =====Start of test.C==========
  typedef long            ptrdiff_t;
  
  class BasicBlock;
  class ThreadContext;
  
  typedef BasicBlock* (TargetCodePtr)(BasicBlock*,
  ThreadContext*);
  
  struct BasicBlockCommon
  {
    TargetCodePtr *targetCodePtr;
    static unsigned long getOffsetOfTargetCodePtr()
    {
      return
  ((ptrdiff_t)(((ptrdiff_t)&(((BasicBlockCommon*)0x40000000)->targ
  etCodePtr)) - 0x40000000));
    }
  };
  
  
  void dummyRunloop()
  {
  
    asm volatile
    (
  
      "blr\n\t"
      :
      :[tcpoffset]
  "g"(BasicBlockCommon::getOffsetOfTargetCodePtr()),
        [regStackOutsOffset] "g" (11)
        : "r0"
    );
  }
  =======End of test.C===============
  

Local fix

• A workaround to the problem is assign the result of the pointer
  to function call to a variable, and replace the function
  call inside the asm constraint with the variable value.
  
  ======Modified test case======
  typedef long            ptrdiff_t;
  
  struct BasicBlock;
  struct ThreadContext;
  
  typedef BasicBlock* (TargetCodePtr)(BasicBlock*,ThreadContext*);
  
  struct BasicBlockCommon
  {
    TargetCodePtr *targetCodePtr;
    static unsigned long getOffsetOfTargetCodePtr()
    {
   return
  ((ptrdiff_t)(((ptrdiff_t)&(((BasicBlockCommon*)0x40000000)->targ
  etCodePt
  r)) - 0x40000000));
    }
  };
  
  
  void dummyRunloop()
  {
  //unsigned long aa =
  BasicBlockCommon::getOffsetOfTargetCodePtr();
    asm volatile
    (
  
      "blr\n\t"
      :
      //:[tcpoffset]         "g"(aa),
      :[tcpoffset]         "g"(
  BasicBlockCommon::getOffsetOfTargetCodePtr())
      [regStackOutsOffset] "g" (11)
        : "r0"
    );
  }
  

Problem summary

• User using functions of rvalue or non-modifiable lvalue
  as 'g' constraint for the input operand are affected by this
  issue.
  
  The compiler converts 'g' constraint into 'm' constraint by
  default unless it is a constant expression or a
  register. But 'm' constraint requires the expression to be an
  lvalue, the compiler failed to diagnose this
                      constraint, and ICE when generating wcode.
  

Problem conclusion

• The fix change the logic in converting 'g'
  constrait to different constraint as follows:
  'i', if the expression is a constant
  expression, else to 'm', if the expression is an lvalue.
  otherwise 'r'.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

  IZ51043

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  XL C/C++ SLES10

• Fixed component ID

  5724U8300

Applicable component levels

• RA10 PSY

     UP