This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Use the same exported ABI for --disable-linux-futex and --enable-linux-futex libgomp
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~