Ok I'll do it.. Thanks!
On Thu, Sep 18, 2014 at 12:59 PM, Joel Sherrill
<joel.sherr...@oarcorp.com> wrote:
>
> On 9/18/2014 10:40 AM, Marcos Díaz wrote:
>> What I printed is the internal representation of those types (at AST
>> of gcc), as I could see the types for each architecture are defined
>> with the macro WCHAR_TYPE for each of them (inside gcc/config/)
>>
>> For sparc the only one I see defined as long int is in gcc/config/sp-elf.h
>> #define WCHAR_TYPE "long int"
>>
>> I think there is the mistake.
>>
>>
>> For ARM it is defined like this:(gcc/config/arm.h)
>> #define WCHAR_TYPE (TARGET_AAPCS_BASED ? "unsigned int" : "int")
> This is where the internal type gets propagated to "user space".
>
> lib/gcc/sparc-rtems4.11/5.0.0/include/stddef.h:typedef __WCHAR_TYPE__
> wchar_t;
>
> It sounds like there is a gcc PR here for an inconsistency. It
> looks like there are cases where wchar_t is long and
> wint_t is just an unsigned int. So we have some inconsistency
> on size and maybe sign.
>
> I think you are right that when wchar_t is long, we get the warning.
>
> This shows all the definitions in gcc.
>
> cd gcc/contrib
> egrep "WCHAR_TYPE\b" */*.h | grep define
>
> I hacked on that script to dump the preprocessed output and
> then grep for the typedefs for these types on all targets. The
> results are attached. I think it confirms your conclusion.
>
> I think we have a GCC PR at least to get some further insight
> and perhaps direction to change the cases where wchar_t
> is long int to just int.. Can you file it and CC me please?
>
> This is why the remaining warnings are often still in the
> tree and not for the faint of heart.
>
> Thanks.
>
> --joel
>> On Thu, Sep 18, 2014 at 12:18 PM, Joel Sherrill
>> <joel.sherr...@oarcorp.com> wrote:
>>> 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.d...@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.d...@tallertechnologies.com> wrote:
>>>>>> Thanks, I will look into it.
>>>>>>
>>>>>> On Wed, Sep 17, 2014 at 4:02 PM, Joel Sherrill
>>>>>> <joel.sherr...@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.sherr...@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.sherr...@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.sherr...@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@rtems.org
>>>>>>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>>>> --
>>>>>>>>> Joel Sherrill, Ph.D. Director of Research & Development
>>>>>>>>> joel.sherr...@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.sherr...@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.sherr...@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.sherr...@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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
