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

[Richard Henderson]

On Tue, Jun 20, 2006 at 02:27:09PM -0400, Jakub Jelinek wrote:
> 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;

This bit certainly works.  I suppose that's the most important
thing -- the way the user-level code gets generated.

> ).  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

It's the definition within the library itself that seems wrong.
Since that's not installed, there is no problem with multilibs.

> 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).

I don't see that as a real problem.


r~