R devel - Aug 2015 - OpenMP problem with 64-bit Rtools

I've been getting pqR to work on windows systems, and in the process
have discovered various problems with R core versions of R and with
Rtools.

One is with the implementation of OpenMP in 64-bit Rtools.  This
problem is in Rtools215 and Rtools33, and presumably all the ones in
between.  You can see the problem with the following test program:

#include <stdio.h>
#include <omp.h>
static struct { omp_lock_t lock; char pad[20]; } s;

void show_pad(void)
{ int i;
  for (i = 0; i<20; i++) printf(" %02x",s.pad[i]);
  printf("\n");
}

int main(void)
{ int i;
  printf("size: %d\n",(int)sizeof s);
  for (i = 0; i<20; i++) s.pad[i] = 7;
  show_pad();
  omp_init_lock (&s.lock);
  show_pad();
  omp_set_lock (&s.lock);
  show_pad();
  return 0;
}

When compiled using the Rtools compiler with "gcc -m32 -fopenmp", it
works fine, printing three lines of output with all numbers being 7.
But when compiled with "gcc -m64 -fopenmp", the last two lines have
four zeros at the beginning.

What's happended is that omp_init_lock has written zeros to four bytes
after the end of the omp_lock_t structure.

The reason for this appears to be that the omp.h file included is
appropriate only for the 32-bit version of the openMP library.  As
far as I can see, there is no 64-bit version of this include file
in the stuff installed with Rtools.

This problem obviously has the potential to affect many packages that
use OpenMP, though simple OpenMP applications may not do anything for
which the incorrect omp.h include file makes a difference.

   Radford Neal

Hi Radford

On Fri, Aug 21, 2015 at 8:38 PM, Radford Neal <radford at cs.toronto.edu>
wrote:
>
> I've been getting pqR to work on windows systems, and in the process
> have discovered various problems with R core versions of R and with
> Rtools.

We happen to be working on a new version of the windows tool chain,
perhaps you are interested to test if problems still exist in the
latest versions. Find a copy of gcc-4.9.2 as well as an installer with
the latest r-devel built with this compiler here:
http://www.stat.ucla.edu/~jeroen/mingw-w64/. Note that this R
installer contains a copy of the tool chain (hence requires no
seperate 'rtools' installation).
> The reason for this appears to be that the omp.h file included is
> appropriate only for the 32-bit version of the openMP library.  As
> far as I can see, there is no 64-bit version of this include file
> in the stuff installed with Rtools.

This particular behavior exists in all builds of mingw-w64, not rtools
per se. We might get a better answer in the mingw-w64-public mailing
list.

> On Fri, Aug 21, 2015 at 8:38 PM, Radford Neal <radford at
cs.toronto.edu> wrote:
>
> > The reason for this appears to be that the omp.h file included is
> > appropriate only for the 32-bit version of the openMP library.  As
> > far as I can see, there is no 64-bit version of this include file
> > in the stuff installed with Rtools.
On Sat, Aug 22, 2015 at 01:30:51AM +0200, Jeroen Ooms wrote:
> This particular behavior exists in all builds of mingw-w64, not rtools
> per se. We might get a better answer in the mingw-w64-public mailing
> list.
A comment near the front of omp.h says "These two structures get
edited by the libgomp build process to reflect the shape of the two
types".  So presumably it is possible to generate the 64-bit version,
and presumably this must have been done in order to compile the 64-bit
version of the OpenMP library that is supplied with Rtools.

Maybe there's no provision in the build process for having two omp.h
files at once, though...

   Radford