RTEMS 4.11: Tool Chain

[Sebastian Huber]

On 2014-02-05 10:17, Ralf Corsepius wrote:
> On 02/05/2014 09:01 AM, Sebastian Huber wrote:
>> On 2014-02-04 18:50, Ralf Corsepius wrote:
>>> On 02/04/2014 04:13 PM, Sebastian Huber wrote:
>>>> Hello,
>>>>
>>>> we have to define the tool chain versions intended for RTEMS 4.11.
>>>>
>>>> For Binutils I would like to use release 2.24 with the attached patch.
>>>>
>>>> For GCC we should use a recent 4.8 branch snapshot (e.g.
>>>> ftp://ftp.gwdg.de/pub/misc/gcc/snapshots/4.8-20140130/gcc-4.8-20140130.tar.bz2)
>>>>
>>>>
>>>> and use GCC 4.8.3 for the release.  This gives us also some time to test
>>>> the RTEMS 4.11 branch, which we should create soon.
>>>>
>>>> In the GCC 4.8.2 release there are several SPARC specific patches not
>>>> included which are part of the GCC 4.8 branch.  We should submit all
>>>> outstanding GCC patches upstream before the GCC 4.8.3 release.
>>>>
>>>> This GCC patch change is still open:
>>>>
>>>> http://www.rtems.org/pipermail/rtems-devel/2013-April/002868.html
>>>>
>>>> See also:
>>>>
>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47111
>>> Well, IMO, this is a general rtems-independent bug in the mips port.
>>>
>>> When trying to have it fixed in GCC, some years ago, the mips maintainers
>>> refused to apply it.
>>>
>>> So, one may undef it for rtems as a work-around, but this is just
>>> playing with
>>> symptoms and with a cure to the cause.
>>
>> Ok, but we have now this workaround in upstream GCC, so there is no need
>> to keep the patch.
> As I said before, this work-around actually is wrong.
>
> It's a new bug to pamper an old bug.

What would be a proper solution for this MIPS bug?  Maybe it makes sense to 
submit this again since MIPS GCC port seems to get more attention recently.

>
>
>>>> This is also an open issue:
>>>>
>>>> http://www.rtems.org/pipermail/rtems-devel/2013-April/002830.html
>>> Right, these patches should be upstreamed.
>>
>> We should first determine why we need these patches.
>>
>> The default seems to be:
>>
>> gcc/defaults.h:#ifndef WCHAR_TYPE_SIZE
>> gcc/defaults.h:#define WCHAR_TYPE_SIZE INT_TYPE_SIZE
>> gcc/defaults.h:#ifndef WCHAR_TYPE
>> gcc/defaults.h:#define WCHAR_TYPE "int"
>>
>> On m32c we have:
>>
>> gcc/config/m32c/m32c.h:#undef  WCHAR_TYPE
>> gcc/config/m32c/m32c.h:#define WCHAR_TYPE "long int"
>> gcc/config/m32c/m32c.h:#undef  WCHAR_TYPE_SIZE
>> gcc/config/m32c/m32c.h:#define WCHAR_TYPE_SIZE 32
>>
>> On m68k we have:
>>
>> gcc/config/m68k/m68k.h:#define WCHAR_TYPE "long int"
>> gcc/config/m68k/m68k.h:#define WCHAR_TYPE_SIZE 32
>>
>> On sh we have:
>>
>> gcc/config/sh/sh.h:#define WCHAR_TYPE "short unsigned int"
>> gcc/config/sh/sh.h:#define WCHAR_TYPE_SIZE 16
>> gcc/config/sh/sh.h:#define SH_ELF_WCHAR_TYPE "long int"
>> gcc/config/sh/elf.h:#undef WCHAR_TYPE
>> gcc/config/sh/elf.h:#define WCHAR_TYPE SH_ELF_WCHAR_TYPE
>> gcc/config/sh/elf.h:#undef WCHAR_TYPE_SIZE
>> gcc/config/sh/elf.h:#define WCHAR_TYPE_SIZE 32
>>
>> On sparc we have:
>>
>> gcc/config/sparc/sparc.h:#define WCHAR_TYPE "short unsigned int"
>> gcc/config/sparc/sparc.h:#define WCHAR_TYPE_SIZE 16
>> gcc/config/sparc/sp-elf.h:#undef WCHAR_TYPE
>> gcc/config/sparc/sp-elf.h:#define WCHAR_TYPE "long int"
>> gcc/config/sparc/sp-elf.h:#undef WCHAR_TYPE_SIZE
>> gcc/config/sparc/sp-elf.h:#define WCHAR_TYPE_SIZE BITS_PER_WORD
>>
>> On v850 we have:
>>
>> gcc/config/v850/v850.h:#undef  WCHAR_TYPE
>> gcc/config/v850/v850.h:#define WCHAR_TYPE "long int"
>> gcc/config/v850/v850.h:#undef  WCHAR_TYPE_SIZE
>> gcc/config/v850/v850.h:#define WCHAR_TYPE_SIZE BITS_PER_WORD
>>
>> So to me this seems that the architecture specific headers use "long
>> int" instead of the default "int" for WCHAR_TYPE.  > What is wrong with this?
>
> Type symmetry as required by GCC's fprintf and newlib (esp. stdint.h/inttypes.h).
>
> I would not want to exclude these patches have become obsolete, because I
> haven't been trying gcc-4.9/newlib-2.x, but at least up to
> gcc-4.7.x/newlib-1.2.x these were necessary.
>
> Unfortunately, I have not been able to catch up yet, because the
> stdint.h/inttypes.h changes in newlib have broken much of my work on
> stdint/inttypes and gcc-types and pushed me back by ca. 2 years of work.

stdint.h uses now the GCC builtin defines, so this shouldn't be a problem.

The inttypes.h is broken in general since GCC doesn't provide any defines which 
can be used here.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.