Please don't deprecate i386 for GCC 4.8
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. Thanks! Cynthia Rempel From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] on behalf of Ralf Corsepius [ralf.corsep...@rtems.org] Sent: Wednesday, December 12, 2012 8:30 PM To: rtems-de...@rtems.org; RTEMS Users Subject: GCC considers to drop i386 Hi, I'd like to pass on this to the RTEMS community: http://gcc.gnu.org/ml/gcc/2012-12/msg00079.html Executive summary: It has been proposed to GCC to drop the i386 CPU and to switch to i486 as minimal required CPU for the ix86-architecture. As RTEMS seems to be one of the last remaining dinosaurs, who is trying to support the i386, this would significantly impact RTEMS and its toolchains. I'd therefore ask all RTEMS users, who might have something substantial to say or have a strong opinion on this topic (e.g. because their works are really using i386s), to reply to the original thread on the GCC list. Otherwise, the i386 is likely gone very soon - If you are using it speak up *now*. This likely your last chance! Sorry for being a little dramatic, but I feel it's inevitable. Thanks in advance. Ralf ___ rtems-devel mailing list rtems-de...@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Keeping gcc ports live
Hi Richard Biener and Robert Dewar, Thanks for the fast response, I really appreciate it! I'll look into gcc-testresults for an i386, now that I know it's a requirement to keep a port live. I compile, and run, RTEMS for the pc386 RTEMS target regularly, so I know the 4.7 cross-compiler does that much, but I'll look into the gcc-testresults suite. Below are some links that would be helpful for anyone is interested in helping out with a different architecture live on gcc as well. gcc-testresults for RTEMS http://www.rtems.org/wiki/index.php/ToolStatus#GCC_Test_Results gcc-testresults for a cross-compiler http://gcc.gnu.org/simtest-howto.html Perhaps gcc-testing could be added to what an intern does to "get started" as part of Google Summer of Code for RTEMS? What else would be required to keep a target gcc port live? Thanks, Cynthia Rempel From: Richard Biener [richard.guent...@gmail.com] Sent: Friday, December 14, 2012 1:09 PM To: Robert Dewar Cc: Cynthia Rempel; gcc@gcc.gnu.org Subject: Re: Please don't deprecate i386 for GCC 4.8 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 no such results exist for i386-rtems in 2012 which means it's current status is in the dark. If you want a port to be live show that it is live by posting regular testresults to gcc-testresults. Thanks, Richard.
RE: Please don't deprecate i386 for GCC 4.8
Hi, Thanks for the fast response! So to keep an architecture supported by GCC, we would need to: Three or more times a year preferably either during OR after "stage3" 1. use the SVN version of gcc, 2. patch with an RTEMS patch, 3. use ./contrib/test_summary and pipe the output to a shell. 4. Report the testresults to gcc-patches. Would this be sufficient to maintain support for an architecture? As far as support goes, I rebuild RTEMS quite often, so once I understand how to run the tests I don't mind doing so for the x86 architectures. If running the test script is all that's required, I can do that. We really appreciate the useful and detailed information! Cynthia Rempel 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. Richard. > Ralf >
i386 port
Hi, I followed the directions on http://gcc.gnu.org/simtest-howto.html 1. ran into the problem that gcc failed the compiling with newlib -- it's a cross-compiler issue 2. patched with gcc-rtems patch 3. configured with ../combined/configure \ --target=i386-rtems \ --prefix=/home/stanr/Desktop/gcc-testing/install \ --with-gnu-as \ --with-gnu-ld \ --with-newlib \ --with-system-zlib \ --disable-nls \ --enable-version-specific-runtime-libs \ --disable-shared \ --disable-checking 4. ran make >> /dev/null 5. running make check-gcc >> results.txt After the results ran past the screen limit I cancelled it, and am running it again, this time to a file. Much to my surprise, the i386-rtems compiler passed some of the tests running on my i686 machine. I know the results will not be completely useful, because the build machine is a i686, but I'm trying to show a good faith effort. My next step will be to learn how to use qemu as an i386 simulator in the context of DejaGNU. After some searching I've found http://gcc.gnu.org/ml/gcc/2009-04/msg00759.html. Hopefully, I'll be able to figure out how to use qemu with DejaGNU. Again, thanks for all the help and support! From: Ralf Corsepius [ralf.corsep...@googlemail.com] Sent: Saturday, December 15, 2012 7:50 PM To: Joel Sherrill Cc: Robert Dewar; Ralf Corsepius; Richard Biener; Cynthia Rempel; gcc@gcc.gnu.org Subject: Re: Please don't deprecate i386 for GCC 4.8 On 12/15/2012 07:02 PM, Joel Sherrill wrote: > I did test i386-rtems in the past few months but it had a build breakage and > I filed a PR. That issue was resolved but at that point about 1/4 of the > rtems targets failed to compile. You likely are referring to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 Yes, this bug is fixed, but a follow-up discussion[1] of this as resulted into what I had called "the known and yet unresolved soft-float/i386" issues earlier in this thread. Ralf [1] Start around http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175#c9 Todate, I know there are at least 2 (possibly 3) bugs interacting, one (possibly 2) in GCC and one in newlib, which render the i386/softfloat multilib variant of i386-rtems GCC non-functional.
Updating the simtest-howto
Hi, I was looking at http://gcc.gnu.org/simtest-howto.html and was wondering if the bottom of the page could be modified from links to tests ran in 2003 to a link to testresults with a search for sim, like http://gcc.gnu.org/cgi-bin/search.cgi?wm=wrd&form=extended&m=all&s=D&ul=%2Fml%2Fgcc-testresults%2F%25&q=sim The website would then have more up-to-date configurations so potential gcc-simtest users would more easily find configurations to use with the experimental/pre-release gcc, in additon to the configurations not running off the page. Thanks! C Rempel
contrib/test_summary mail error
Hi, I tried to run the following command: ../gcc/contrib/test_summary -p my_commentary.txt -m gcc-testresu...@gcc.gnu.org | sh and got the following error: sh: 22297: Mail: not found After digging through emails, ran accross http://lists.debian.org/debian-user/2002/04/msg00065.html Mint complained it was a 'virtual package' and told me to pick one of three options: mailutils 1:2.2+dfsg1-5 heirloom-mailx 12.5-1build1 bsd-mailx 8.1.2-0.2006cvs-1 The first one didn't fix the error, but the second one did. Could you fix the contrib/test_summary script to suggest mail packages that would work for gcc/contrib/test_summary on Ubuntu? Thanks! Cindy
