bug in gcc-3.2.3/gcc/gthr_rtems.h

Joel Sherrill joel.sherrill at OARcorp.com
Mon Apr 19 22:47:26 UTC 2004


Till Straumann wrote:

> I think Yacine is right. Looking at gcc-3.2.2 is affected, too.
> 
> Joel apparently added a macro definition on 2003-05-21 (gcc PR 9296)
> - however, the reasons for this change are not apparent.
> 
> Joel, can you remember why you thought you had to define
> __GTHREAD_MUTEX_INIT ?

Honestly no I don't. I think it may have been a compilation
problem that originated the patch.

Sound like the 4.6 and 4.7 tools need a spin.

> Thanks
> 
> -- Till
> 
> The Changelog
> 
> EL KOLLI Yacine wrote:
> 
>> Hello,
>>
>> I think there is a bug in gthr_rtems.h in the gcc-3.2.3 source tree 
>> under gcc-3.2.3/gcc/gthr_rtems.h.
>>
>> In this file   __GTHREAD_MUTEX_INIT is define to 0 and 
>> __GTHREAD_MUTEX_INIT_FUNCTION   is defined to rtems_gxx_mutex_init.
>>
>> But a comment in gthr.h states:
>>      __GTHREAD_MUTEX_INIT
>>          to initialize __gthread_mutex_t to get a fast
>>     non-recursive mutex.
>>      __GTHREAD_MUTEX_INIT_FUNCTION
>>          some systems can't initialize a mutex without a
>>     function call.  On such systems, define this to a
>>     function which looks like this:
>>     void __GTHREAD_MUTEX_INIT_FUNCTION (__gthread_mutex_t *)
>>     Don't define __GTHREAD_MUTEX_INIT in this case
>>
>> The result of having defined __GTHREAD_MUTEX_INIT is that the STL 
>> global constructor does not call rtems_gxx_mutex_init to init its 
>> mutex, but rather use the statically defined value 0.
>> All locking performed by the STL lib on this mutex fail with return 
>> value OBJECT_ERROR, which seems not be tested.
>>
>> I've recompiled gcc with __THREAD_MUTEX_INIT left undefined. Now STL 
>> constructor is calling rtems_gxx_mutex_init , and nothing seems broken.
>>
>> Any comments ?
>>
>> Y El Kolli.
>>
> 
> 





More information about the users mailing list