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.
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.
For Newlib I would use 2.1.0 without any patches or a recent snapshot.
My trust in newlib-2.x is fairly low, because of the amount of changes
it has
seen and because it still has not stabilized enough to allow proper
testing.
I use the Newlib HEAD now for two years or so and addressed all problems
I found. The only remaining issue I am aware of is:
https://www.rtems.org/bugzilla/show_bug.cgi?id=1247
Finally, FYI: Some weeks ago I attempted a stab on porting the
rtems-tools
chains to x86_64-cygwin, but was badly hit by what I currently assume
to be a
bug in cyginw's newlib-2.0, which seems to originate from one of these
changes.
However, I am not sure about it, yet.
Ok, but this is a Cygwin problem?
I currently believe it's a general bug in newlib, they inherited from
newlib which likely is triggered by Cross-building GCC for
Linux->Cygwin. Unfortunately, I also haven't found enough time to
furtherly investigate this, but am wondering why the cygwin folks have
not yet stumbled over this bug, themselves.
Ralf
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
