On Tue, Mar 13, 2012 at 11:22 AM, Richard Earnshaw <rearn...@arm.com> wrote:
> On 13/03/12 10:05, Richard Guenther wrote:
>> On Tue, Mar 13, 2012 at 10:44 AM, Richard Guenther
>> <richard.guent...@gmail.com> wrote:
>>> On Mon, Mar 12, 2012 at 6:44 PM, Gerald Pfeifer <ger...@pfeifer.com> wrote:
>>>> On Mon, 12 Mar 2012, Richard Guenther wrote:
>>>>>>> 2012-01-18  Richard Guenther  <rguent...@suse.de>
>>>>>>>
>>>>>>>        * gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION): Adjust specification.
>>>>>>>        * gthr-posix.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
>>>>>>>        (__gthread_mutex_init_function): New function.
>>>>>>>        * gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
>>>>>>>
>>>>>>>        PR gcov/49484
>>>>>>>        * libgcov.c: Include gthr.h.
>>>>>>>        (__gcov_flush_mx): New global variable.
>>>>>>>        (init_mx, init_mx_once): New functions.
>>>>>>>        (__gcov_flush): Protect self with a mutex.
>>>>>>>        (__gcov_fork): Re-initialize mutex after forking.
>>>>>>>        * unwind-dw2-fde.c: Change condition under which to use
>>>>>>>        __GTHREAD_MUTEX_INIT_FUNCTION.
>>>>
>>>> Richi, I'm afraid this caused the following on i386-unknown-freebsd10?
>>>>
>>>> /scratch2/tmp/gerald/gcc-HEAD/libgcc/libgcov.c:710:54: error: 'NULL' 
>>>> undeclared here (not in a function)
>>>> gmake[3]: *** [_gcov.o] Error 1
>>>> gmake[3]: *** Waiting for unfinished jobs....
>>>> gmake[3]: Leaving directory 
>>>> `/scratch2/tmp/gerald/OBJ-0312-1454/i386-unknown-freebsd10.0/libgcc'
>>>> gmake[2]: *** [all-stage1-target-libgcc] Error 2
>>>
>>> This is
>>>
>>> #ifdef __GTHREAD_MUTEX_INIT
>>> ATTRIBUTE_HIDDEN __gthread_mutex_t __gcov_flush_mx = __GTHREAD_MUTEX_INIT;
>>>
>>> thus if __GTHREAD_MUTEX_INIT uses NULL and gthr.h does not include
>>> everything to make that initializer valid it is a freebsd header bug, unless
>>> it is
>>>
>>> #if defined(inhibit_libc)
>>> #define IN_LIBGCOV (-1)
>>> #else
>>> #undef NULL /* Avoid errors if stdio.h and our stddef.h mismatch.  */
>>> #include <stdio.h>
>>>
>>> wtf?  This is a target library, why is stdio.h not properly included
>>> by tsystem.h?
>>> It is.  Anyone remembers?
>>
>> Goes back to rev. 5880 by rms, at which time tsystem.h did not exist.
>>
>> I'm going to remove those two lines, bootstrap & test it and commit as
>> obvious.
>>
>
> Please also check this on a bare-metal build.

Bare-metal should not be affected as that defines inhibit_libc(?).  What
is an example for a bare-metal target triplet?

Richard.

> R.
>
>> Richard.
>>
>>> Can you verify that theory, thus remove that #undef and the #include?
>>>
>>> Richard.
>>>
>>>> Gerald
>>
>
>

Reply via email to