This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 5 Status Report (2015-03-20)

Joel Sherrill a écrit:
I thought I would pass along a couple of data points from
the *-rtems targets.

Fourteen *-rtems target build OK on the head. The following
do not even complete building gcc+newlib.

v850 - PR65501. New and must be relatively recent. I built
  a C/C++ toolset on January 15.
m32c - PR63683. Reported against 4.9 branch. DJ may have a
  patch for this.

The avr is still broken. I don't know that it is worth the trouble
to even dig up the PRs anymore.

Like some other 3ary platforms, avr is plagued by spill fails, summarized as meta PR56183.

Apart from that the device selection scheme changed some while ago: Setting -mmcu= will trigger a target specific spec file to be applied. The initial version didn't factor out libc and focused solely on avr-libc. I tried to rectify that in PR65296, i.e. spec files generator is now sensitive to avr-*-rtems configuration. What does not yet work is spaces in the installation path.

Some of the avr core architectures are not well suited for "big" system like rtems + newlib. There are even devices without RAM so that for some of the core architecture it makes hardly any sense to build newlib variants for them, in particular "avr1" and "avrtiny" maybe even more.

If parts of the device spec files are not generated as needed by rtems, it might be the case that the avr backend needs more adjustments, in particular specs.h, rtems.h, gen-avr-mmcu-specs.c, maybe also t-multilib and its generator genmultilib.awk.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]