Bug#778440: libgcc-5-dev: hardcorded omp_nest_lock_t size breaks non-linux use

[Matthias Klose <doko@debian.org>]

On 03/25/2015 02:20 AM, Samuel Thibault wrote:
> 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.

but then you need to know during the build of libgomp, which multilibs you are
building.  I've now limited the fix for Linux. That still leaves the multilib
issue on other OSes.