bug in gcc-3.2.3/gcc/gthr_rtems.h

[Till Straumann]

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 ?

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