inconsistent code generation at -m32 with -fprofile-generate -D_PROFILE_GENERATE
Jan, It appears that the gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE testcase exposes inconsistent code generation on both x86_64 darwin and x86_64 linux at -m32. The darwin linker developer looked at the crashing pr44777.exe executable that this testcase produces... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52444#c1 I looked at this further was surprised to find that each time the compilation... /home/howarth/work-gcc/gcc/xgcc -B/home/howarth/work-gcc/gcc/ /home/howarth/gcc/gcc/testsuite/gcc.dg/tree-prof/pr44777.c -fno-diagnostics-show-caret -O0 -fprofile-generate -D_PROFILE_GENERATE -lm -m32 -o /home/howarth/work-gcc/gcc/testsuite/gcc/pr44777.x01 --save-temps produces slightly different assembly... --- pr44777.s.orig2012-12-15 09:40:32.507293659 -0500 +++ pr44777.s2012-12-15 09:40:45.323922586 -0500 @@ -250,7 +250,7 @@ .LPBX0: .long875575397 .long0 -.long-1627233075 +.long-1627220258 .long.LC0 .long__gcov_merge_add .long0 but always at this location. Can you take a look at this under linux? You won't see the crashing executable but you will see the variable assembly generation in the -D_PROFILE_GENERATE compile. Jack
Re: Please don't deprecate i386 for GCC 4.8
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 >
Re: Please don't deprecate i386 for GCC 4.8
On 12/15/2012 12:42 AM, Ralf Corsepius wrote: 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. But that's the point. If you don't have the resources, you seem to be expecting others to provide them, but at this stage I really don't see a strong argument for investing such effort.
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 >
Re: Please don't deprecate i386 for GCC 4.8
On 12/15/2012 12:32 PM, Cynthia Rempel wrote: 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. Well of course it would always be appreciated if you can jump in and help sort out problems that are 386 specific (hopefully there won't be any!)
Re: Please don't deprecate i386 for GCC 4.8
I am on travel and answering from my phone so don't remember all the exact dates and PRs. 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. I filed PRs but didn't get back around to running the tests and reporting. When I get home, I will do a build/test run for *-rtems and generate PRs, etc. --joel Robert Dewar wrote: >On 12/15/2012 12:42 AM, Ralf Corsepius wrote: > >>> 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. > >But that's the point. If you don't have the resources, you seem >to be expecting others to provide them, but at this stage I >really don't see a strong argument for investing such effort. >
gcc-4.7-20121215 is now available
Snapshot gcc-4.7-20121215 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20121215/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 194524 You'll find: gcc-4.7-20121215.tar.bz2 Complete GCC MD5=fcb01341b8b2a6311a21633578205aa4 SHA1=99fb3b3e141539c85305099d041e726ae405819f Diffs from 4.7-20121208 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
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.
