Bug#778440: libgcc-5-dev: hardcorded omp_nest_lock_t size breaks non-linux use
Matthias Klose, le Tue 24 Mar 2015 16:09:27 +0100, a écrit :
> > I guess this
> > was done in order to be able to use the same omp.h on both i386 and
> > amd64, but I don't think this is still needed now that omp.h is in
> > arch-specific
> >
> > /usr/lib/gcc/x86_64-linux-gnu/5/include/omp.h
> >
> > Could you consider removing this patch?
>
> this location is not arch-specific for multilibs.
Argl.
> So I still think this is needed. And maybe even on the multilib'ed
> kfreebsd targets.
Indeed.
> So better guard the bits with preprocessor macros?
Yes. The issue is that for non-Linux ports libgomp uses pthread_mutex_t
or sem_t, whose sizes are mostly unknown, so ideally it'd be
#ifdef m32
unsigned char _x[@OMP_NEST_LOCK_SIZE_32@]
__attribute__((__aligned__(@OMP_NEST_LOCK_ALIGN_32@)));
#elif defined(mx32)
unsigned char _x[@OMP_NEST_LOCK_SIZE_x32@]
__attribute__((__aligned__(@OMP_NEST_LOCK_ALIGN_x32@)));
#elif defined(m64)
unsigned char _x[@OMP_NEST_LOCK_SIZE_64@]
__attribute__((__aligned__(@OMP_NEST_LOCK_ALIGN_64@)));
#endif
the _32, _x32 and _64 values being computed by configure for the various
targets.
Samuel
Reply to: