Single Warning Analysis Request
Joel Sherrill
joel.sherrill at oarcorp.com
Thu Sep 18 15:18:40 UTC 2014
On 9/18/2014 10:00 AM, Marcos Díaz wrote:
> The output of the two types (debugging gcc at the comparison of types):
> For ARM (doesn't throw the warning):
>
> (gdb) p debug_tree(wanted_type)
> <integer_type 0x7ffff664a690 unsigned int public unsigned SI
>
> (gdb) p debug_tree(cur_type)
> <integer_type 0x7ffff664a690 unsigned int public unsigned SI
>
> For sparc: (throws the warning)
> p debug_tree(wanted_type)
> <integer_type 0x7ffff760f690 unsigned int public unsigned SI
>
> (gdb) p debug_tree(cur_type)
> <integer_type 0x7ffff760f738 long int public SI
>
> NOTE: wanted_type is the passed to the string (%lc) cur_type is the
> actually passed (wc)
This is what I was concerned about. Differences between targets.
When I checked the typedefs, they appeared to be the same though.
How does gcc get the information you printed?
I think a GCC PR should be raised with all the information we
have and see if someone has a suggestion. Maybe gcc doesn't
know something about newlib at this level. CC me on the PR
so I can track it.
FWIW Sebastian did one on another warning and it got very
quick feedback (but no quick fix). I may have to start updating
my script to crunch the logs to ignore certain warnings we have
tools PRs outstanding about.
Jeez.. these cross-target inconsistent warnings are hard. :(
Thanks.
> On Thu, Sep 18, 2014 at 11:56 AM, Marcos Díaz
> <marcos.diaz at tallertechnologies.com> wrote:
>> Hi, I've been looking this, and I saw the following:
>> This warning arise because the %lc format option is for wint_t type,
>> and we are passing a wchar_t type.
>> At the architectures that doesn't give the warning, those two types
>> are the same (wint_t and wchar_t), and those who give the warning have
>> them of different types. At the end I'll show how I could see that.
>> According to the c standard there isn't an option to print one wchar_t
>> character, but you can print a string of wchar_t (passing the pointer,
>> and with WEOF as end of string) so, one solution could be print this
>> variable as follows:
>> wchar_t wc[2]= {L'a'}; (or wchar_t wc[2]= {L'a', WEOF};
>> printf("%ls",wc);
>>
>> The other could be that gcc has wrongly defined the types for wchar_t
>> and wint_t for those architectures. This should be analysed
>>
>> On Wed, Sep 17, 2014 at 4:55 PM, Marcos Díaz
>> <marcos.diaz at tallertechnologies.com> wrote:
>>> Thanks, I will look into it.
>>>
>>> On Wed, Sep 17, 2014 at 4:02 PM, Joel Sherrill
>>> <joel.sherrill at oarcorp.com> wrote:
>>>> On 9/17/2014 1:38 PM, Marcos Díaz wrote:
>>>>> Where can we see in which BSP's and with which tools this warning was
>>>>> generated? Thanks
>>>> OK. It is with the tools generated by the current RSB and
>>>> the RTEMS head.
>>>>
>>>> I have attached a cut down and script that I used to test it
>>>> on all RTEMS gcc's I have installed. It gives a summary and
>>>> is easy to hack on. Plus this doesn't need RTEMS at all to
>>>> investigate the warning. :)
>>>>
>>>> === arm-rtems4.11-gcc - no warning
>>>> === avr-rtems4.11 - warning
>>>> === bfin-rtems4.11-gcc - no warning
>>>> === h8300-rtems4.11 - warning
>>>> === i386-rtems4.11-gcc - no warning
>>>> === lm32-rtems4.11-gcc - no warning
>>>> === m68k-rtems4.11-gcc - warning
>>>> === m32c-rtems4.11-gcc - warning
>>>> === m32r-rtems4.11-gcc - no warning
>>>> === mips-rtems4.11-gcc - no warning
>>>> === moxie-rtems4.11-gcc - no warning
>>>> === nios2-rtems4.11-gcc - no warning
>>>> === or1k-rtems4.11-gcc - no warning
>>>> === powerpc-rtems4.11-gcc - warning
>>>> === sh-rtems4.11-gcc - warning
>>>> === sparc64-rtems4.11-gcc - no warning
>>>> === sparc-rtems4.11-gcc - warning
>>>> === v850-rtems4.11-gcc - warning
>>>>
>>>> This is the list of BSPs that have this warning. Interesting that at least
>>>> arm, mips, m32r, moxie, nios2, and sparc64 don't generate this.
>>>>
>>>> m32c-m32csim m68k-av5282 m68k-COBRA5475 m68k-csb360 m68k-gen68302
>>>> m68k-gen68340 m68k-gen68360_040 m68k-gen68360 m68k-idp
>>>> m68k-m5484FireEngine m68k-mcf52235 m68k-mcf5225x m68k-mcf5235
>>>> m68k-mcf5329 m68k-mrm332 m68k-mvme136 m68k-mvme147 m68k-mvme147s
>>>> m68k-mvme167 m68k-ods68302 m68k-pgh360 m68k-sim68000 m68k-simcpu32
>>>> m68k-uC5282 powerpc-ep1a powerpc-haleakala powerpc-mbx821_001
>>>> powerpc-mbx821_002b powerpc-mbx821_002 powerpc-mbx860_001b
>>>> powerpc-mbx860_002 powerpc-mbx860_005b powerpc-mbx860_1b
>>>> powerpc-mpc8260ads powerpc-pghplus powerpc-psim powerpc-qemuppc
>>>> powerpc-ss555 powerpc-tqm8xx_stk8xx powerpc-virtex4 powerpc-virtex5
>>>> powerpc-virtex sh-gensh1 sh-gensh2 sh-gensh4 sh-simsh1 sh-simsh2e
>>>> sh-simsh2 sh-simsh4 sparc-erc32 sparc-leon2 sparc-leon3 sparc-ngmp
>>>> sparc-sis v850-v850e1sim v850-v850e2sim v850-v850e2v3sim
>>>> v850-v850esim v850-v850essim v850-v850sim
>>>>
>>>>
>>>>> On Wed, Sep 17, 2014 at 12:40 PM, Joel Sherrill
>>>>> <joel.sherrill at oarcorp.com> wrote:
>>>>>> On 9/17/2014 10:23 AM, Daniel Gutson wrote:
>>>>>>> Marcos and I will take a look.
>>>>>> Thanks.
>>>>>>> On Wed, Sep 17, 2014 at 12:19 PM, Joel Sherrill
>>>>>>> <joel.sherrill at oarcorp.com> wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I would really appreciate it if someone could look into this
>>>>>>>> warning and see if we can get an explanation. It could be
>>>>>>>> a source code issue or something higher in the tools.
>>>>>>>> It is reported on 120 BSP build configurations:
>>>>>>>>
>>>>>>>> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/hexdump-conv.c:145:4:
>>>>>>>> warning: format '%lc' expects argument of type 'wint_t', but argument 4
>>>>>>>> has type 'wchar_t' [-Wformat=]
>>>>>>>> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/hexdump-conv.c:145:4:
>>>>>>>> warning: format '%lc' expects argument of type 'wint_t', but argument 4
>>>>>>>> has type 'wchar_t' [-Wformat=]
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> devel mailing list
>>>>>>>> devel at rtems.org
>>>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>> --
>>> ______________________________
>>>
>>>
>>> Marcos Díaz
>>>
>>> Software Engineer
>>>
>>>
>>> San Lorenzo 47, 3rd Floor, Office 5
>>>
>>> Córdoba, Argentina
>>>
>>>
>>> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>>>
>>> Skype: markdiaz22
>>
>>
>> --
>> ______________________________
>>
>>
>> Marcos Díaz
>>
>> Software Engineer
>>
>>
>> San Lorenzo 47, 3rd Floor, Office 5
>>
>> Córdoba, Argentina
>>
>>
>> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>>
>> Skype: markdiaz22
>
>
--
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 devel
mailing list