Please don't deprecate i386 for GCC 4.8

Richard Biener
Sat Dec 15 15:19:00 GMT 2012

On Sat, Dec 15, 2012 at 6:42 AM, Ralf Corsepius
<> wrote:
> On 12/14/2012 10:09 PM, Richard Biener wrote:
>> On Fri, Dec 14, 2012 at 9:16 PM, Robert Dewar <> wrote:
>>> On 12/14/2012 3:13 PM, Cynthia Rempel wrote:
>>>> Hi,
>>>> RTEMS still supports the i386, and there are many i386 machines still
>>>> in use.  Deprecating the i386 will negatively impact RTEMS ability to
>>>> support the i386.  As Steven Bosscher said, the "benefits" are small,
>>>> and the impact would be serious for RTEMS i386 users.
>>> Since there is a significant maintenance burden for such continued
>>> support, I guess a question to ask is whether the RTEMS folks or
>>> someone using RTEMS are willing to step in and shoulder this burden.
>> Btw, while I see very sporadical testresults for arm-rtems and older
>> results
>> for v850 and sparc and powerpc-rtems testresult posting on gcc-testresults
> Correct. These results are side-effects of works from people who currently
> are working with these architectures, facing problems  or porting RTEMS to
> these targets.
> This doesn't mean the other targets aren't used nor non functional, because
> RTEMS targets usually only are variants from the corresponding newlib-elf
> targets.
>> no such results exist for i386-rtems in 2012 which means it's current
>> status
>> is in the dark.
> More or less correct.
> Older ix86-rtems-gcc's are known to work, newer ix86-rtems-gccs are known to
> have not yet fully understood problems (Related to soft-float math, i386 and
> not using a linux-libc).
>> If you want a port to be live show that it is live by posting regular
>> testresults to gcc-testresults.
> Not all of this world is Linux nor backed by large teams at $$$$ companies
> :)  We simply do not have the resources do to this.

Well, easiest is to, whenever you build a version of GCC and run the testsuite
(using a simulator I guess), use ./contrib/test_summary and pipe the output
to a shell.  That will report the testresults to gcc-patches.

Thus, it doesn't have to be a dedicated machine doing automated regular
builts and tests.  It's enough if you happen to build and test GCC for your
arch a few times a year, that you make sure to report the results.

Especially nice would be to do that for SVN trunk at the point in time it
matters most - during and after stage3 - so that issues can be identified
before a new major release happens.


> Ralf

More information about the Gcc mailing list