[PATCH] Use the same exported ABI for --disable-linux-futex and --enable-linux-futex libgomp

[Jakub Jelinek]

On Tue, Jun 20, 2006 at 10:20:53AM -0700, Richard Henderson wrote:
> On Mon, Jun 19, 2006 at 12:29:55PM -0400, Jakub Jelinek wrote:
> > +typedef int omp_lock_t __attribute__((aligned (8)));
> > +typedef struct { int owner, count; } omp_nest_lock_t
> > +     __attribute__((aligned (8)));
> 
> I don't like attempting to use aligned to increase the allocation size.
> I'm pretty sure that doesn't actually work.

I agree it is not pretty, but I think it works (the generated omp.h
has stuff like:
typedef struct
{
  unsigned char _x[4]
    __attribute__((__aligned__(8)));
} omp_lock_t;

typedef struct
{
  unsigned char _x[8]
    __attribute__((__aligned__(8)));
} omp_nest_lock_t;
).  There were 2 reasons why I used it:
1) so far omp.h (and omp_lib{,_kinds}.mod) were multilib independent
   with --enable-linux-futex
   If omp_lock_t is changed to say
   typedef union { int futex; pthread_mutex_t *lock; } omp_lock_t;
   then we need to install one omp.h (and one omp_lib{,_kinds}.mod pair)
   for each multilib
2) in --enable-linux-futex mode, gomp_mutex_t is an int typedef, so
   using
   typedef int omp_lock_t __attribute__((mode(pointer)));
   would be wrong as config/linux freely casts between gomp_mutex_t
   and omp_lock_t.  Using the union, we'd need to uglify a little
   bit (convert from omp_lock_t pointer to gomp_mutex_t pointer using
   &omp_lock->futex).

But if you want to go that way...
1) is even more complicated by the fact that unlike C++ (or Fortran
finclude), C doesn't AFAIK have a multilib specific include dir

	Jakub