GCC Warning on MIPS

Joel Sherrill joel.sherrill at OARcorp.com
Tue Apr 22 21:22:56 UTC 2008


Ralf Corsepius wrote:
> On Tue, 2008-04-22 at 10:13 -0500, Joel Sherrill wrote:
>   
>> Ralf Corsepius wrote:
>>     
>>> On Tue, 2008-04-22 at 10:01 -0500, Joel Sherrill wrote:
>>>
>>>       
>>>> Ralf Corsepius wrote:
>>>>
>>>>         
>>>>> On Tue, 2008-04-22 at 09:25 -0500, Joel Sherrill wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Ralf,
>>>>>>
>>>>>> I know neither of us go digging through build
>>>>>> logs when the build works, but I came across this
>>>>>> warning building GCC SVN trunk targeting mips-rtems4.9
>>>>>>
>>>>>> In file included from ./tm.h:10,
>>>>>>                  from ../../gcc/gcc/gencheck.c:24:
>>>>>> ../../gcc/gcc/config/rtems.h:21:1: warning: "NO_IMPLICIT_EXTERN_C" redefined
>>>>>> In file included from ./tm.h:8,
>>>>>>
>>>>>> Not critical but is repeated about 10,000 times. :-D
>>>>>>
>>>>>> I think the #define NO_IMPLICIT_EXTERN_C in gcc/config/rtems.h
>>>>>> needs an ifndef or an undef added.
>>>>>>
>>>>>> What do you think we need to do?
>>>>>>
>>>>>>
>>>>>>             
>>>>> Hmm, do you have this patch below applied?
>>>>>
>>>>> diff -Naur gcc-4.3.0.orig/gcc/config/mips/elf.h gcc-4.3.0/gcc/config/mips/elf.h
>>>>> --- gcc-4.3.0.orig/gcc/config/mips/elf.h        2007-08-02 12:49:31.000000000 +0200
>>>>> +++ gcc-4.3.0/gcc/config/mips/elf.h     2008-03-06 16:22:30.000000000 +0100
>>>>> @@ -48,6 +48,4 @@
>>>>>  #undef  ENDFILE_SPEC
>>>>>  #define ENDFILE_SPEC "crtend%O%s crtn%O%s"
>>>>>
>>>>> -#define NO_IMPLICIT_EXTERN_C 1
>>>>> -
>>>>>  #define HANDLE_PRAGMA_PACK_PUSH_POP 1
>>>>>
>>>>>
>>>>> This is a general bug in the mips port (I _know_ it is), but ...
>>>>> upstream refuses to apply it, which forces us to keep it as a separate
>>>>> patch :)
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> In many cases throughout the gcc config files, they just undef
>>>> the previous one and redefine.  In the above, ENDFILE_SPEC
>>>> is done that way.  Three of the five definitions in config/rtems.h
>>>> have an undef in front of them.  Would it be so bad to just
>>>> do that for the rest of the ones in rtems.h?
>>>>
>>>>         
>>> Why should they?
>>>
>>> Wrt. to NO_IMPLICIT_EXTERN_C, to me this doesn't make any sense at all.
>>>
>>>
>>>       
>> Maybe not but there is precedence for it.  The shared
>> config files for a number of other OSes do this:
>>
>> [joel at iceland config]$ grep -r NO_IMPLICIT_EXTERN_C .| grep ifndef |
>> grep -v .svn
>> ./lynx.h:#ifndef NO_IMPLICIT_EXTERN_C
>> [joel at iceland config]$ grep -r NO_IMPLICIT_EXTERN_C .| grep undef| grep
>> -v .svn
>> ./netbsd.h:#undef  NO_IMPLICIT_EXTERN_C
>> ./rs6000/sysv4.h:#undef  NO_IMPLICIT_EXTERN_C
>> ./i386/sco5.h:#undef NO_IMPLICIT_EXTERN_C
>> ./freebsd.h:#undef  NO_IMPLICIT_EXTERN_C
>> ./vx-common.h:#undef  NO_IMPLICIT_EXTERN_C
>> ./sparc/openbsd64.h:#undef NO_IMPLICIT_EXTERN_C
>>     
>
> And where would be the sense behind this?
>
> We want to force NO_IMPLICIT_EXTERN_C.
>
> The bug is in mips/elf.h. This file belongs to the mips backend.
>
> This file simply is broken by defining an OS specific flag such as
> NO_IMPLICIT_EXTERN_C.
>
> Cf. how we set up _all_ other targets. The only one behaving differently
> is this broken mips file.
>   
Then how about proposing a patch for the mips/elf.h file
to gcc?
> Ralf
>
>
>
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985





More information about the users mailing list