LI74350: UNEXPECTED BEHAVIOR WITH QSMP=OMP OPTION

March 2009 Update for XL C/C++ for Linux, V10.1
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

• Compiling the following test case with -qsmp=omp and running it
  with OMP_NUM_THREADS=4 generates unexpected output:
  
  #include <omp.h>
  #include <stdio.h>
  int main(void) {
  #pragma omp parallel
    {
      int i;
  #pragma omp critical
      printf("thread_a %d: %p\n", omp_get_thread_num(), &i);
    }
  #pragma omp parallel
    do {
      int i;
  #pragma omp critical
      printf("thread_b %d: %p\n", omp_get_thread_num(), &i);
    } while(0);
    return 0;
  }
  

Local fix

• Add an extra bracket "{}" to embrace the do-while loop.
  

Problem summary

• OpenMP users with parallel directive which binds to a do/while
  or while loop, may be affected.
  
  The automatic variables enclosed by the lexical scope of the
  loop are not marked private (per thread).  This may result in
  undetected and unexpected runtime failure of generated
  executable.
  

Problem conclusion

• To solve this issue, the variables enclosed in the loop will be
  marked as private.  This fix will be applied to a future PTF.
  

Temporary fix

Comments

APAR Information

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

  IZ40899

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

  LI74420

Fix information

• Fixed component name

  XL C/C++ SLES10

• Fixed component ID

  5724U8300

Applicable component levels

• RA10 PSN IZ40899

     UP06/09/13