* need help with gcc 4.1.0 crosscompiler for arm @ 2006-04-12 23:11 marty fouts 2006-04-13 7:25 ` Niklaus 0 siblings, 1 reply; 11+ messages in thread From: marty fouts @ 2006-04-12 23:11 UTC (permalink / raw) To: gcc-help I'm obviously doing something stupid, and would appreciate some help. I've got an embedded application running on arm hardware. Currently it is built with gcc 3.4.3 and binutils 2.15. I configure binutils and gcc in the obvious ways: ../binutils-2.15/configure --prefix=/usr/local/armdev-3.4.3 --target=arm-elf ../gcc-3.4.3/configure --prefix=/usr/local/armdev-3.4.3 --target=arm-elf --enable-languages=c,c++ after having patched gcc/config/arm/t-elf using this patch file: ----- patch file ----- --- gcc-3.4.2/gcc/config/arm/t-arm-elf 2003-09-30 03:21:41.000000000 -0700 +++ gcc-3.4.2-p/gcc/config/arm/t-arm-elf 2004-09-17 09:29:58.312527908 -0700 @@ -26,9 +26,9 @@ # MULTILIB_DIRNAMES += 32bit 26bit # MULTILIB_EXCEPTIONS += *mthumb/*mapcs-26* # -# MULTILIB_OPTIONS += mno-thumb-interwork/mthumb-interwork -# MULTILIB_DIRNAMES += normal interwork -# MULTILIB_EXCEPTIONS += *mapcs-26/*mthumb-interwork* +MULTILIB_OPTIONS += mno-thumb-interwork/mthumb-interwork +MULTILIB_DIRNAMES += normal interwork +MULTILIB_EXCEPTIONS += *mapcs-26/*mthumb-interwork* # # MULTILIB_OPTIONS += fno-leading-underscore/fleading-underscore # MULTILIB_DIRNAMES += elf under @@ -71,7 +71,7 @@ # Currently there is a bug somewhere in GCC's alias analysis # or scheduling code that is breaking _fpmul_parts in fp-bit.c. # Disabling function inlining is a workaround for this problem. -TARGET_LIBGCC2_CFLAGS = -Dinhibit_libc -fno-inline +TARGET_LIBGCC2_CFLAGS = -Dinhibit_libc -fno-inline -msoft-float # Assemble startup files. $(T)crti.o: $(srcdir)/config/arm/crti.asm $(GCC_PASSES) ----- end of patch file ----- GCC builds fine and builds the application fine. I try doing the same thing for gcc 4.1.0 and gcc builds fine, but when it finally gets around to trying to link the executable, I get error messages that I *think* mean that libgcc is being built with arm floating point instructions, for instance: /usr/local/gnuarm-4.1.0/bin/arm-elf-ld: ERROR: /usr/local/gnuarm-4.1.0/lib/gcc/arm-elf/4.1.0/interwork/libgcc.a(_clz.o) uses FPA instructions, whereas application.elf does not I've tried every configuration option I can think of to build libgcc without floating point, but have not managed to do so. As I said, I'm obviously doing something dumb, and any help in figuring out what I should do instead would be greatly appreciated. Thanks, Marty ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: need help with gcc 4.1.0 crosscompiler for arm 2006-04-12 23:11 need help with gcc 4.1.0 crosscompiler for arm marty fouts @ 2006-04-13 7:25 ` Niklaus 2006-04-13 22:53 ` marty fouts 0 siblings, 1 reply; 11+ messages in thread From: Niklaus @ 2006-04-13 7:25 UTC (permalink / raw) To: marty fouts; +Cc: gcc-help On 4/13/06, marty fouts <mf.danger@gmail.com> wrote: > I'm obviously doing something stupid, and would appreciate some help. > > I've got an embedded application running on arm hardware. Currently it > is built with gcc 3.4.3 and binutils 2.15. I configure binutils and > gcc in the obvious ways: > > ../binutils-2.15/configure --prefix=/usr/local/armdev-3.4.3 --target=arm-elf > > ../gcc-3.4.3/configure --prefix=/usr/local/armdev-3.4.3 > --target=arm-elf --enable-languages=c,c++ > > after having patched gcc/config/arm/t-elf using this patch file: > > ----- patch file ----- > --- gcc-3.4.2/gcc/config/arm/t-arm-elf 2003-09-30 03:21:41.000000000 -0700 > +++ gcc-3.4.2-p/gcc/config/arm/t-arm-elf 2004-09-17 > 09:29:58.312527908 -0700 > @@ -26,9 +26,9 @@ > # MULTILIB_DIRNAMES += 32bit 26bit > # MULTILIB_EXCEPTIONS += *mthumb/*mapcs-26* > # > -# MULTILIB_OPTIONS += mno-thumb-interwork/mthumb-interwork > -# MULTILIB_DIRNAMES += normal interwork > -# MULTILIB_EXCEPTIONS += *mapcs-26/*mthumb-interwork* > +MULTILIB_OPTIONS += mno-thumb-interwork/mthumb-interwork > +MULTILIB_DIRNAMES += normal interwork > +MULTILIB_EXCEPTIONS += *mapcs-26/*mthumb-interwork* > # > # MULTILIB_OPTIONS += fno-leading-underscore/fleading-underscore > # MULTILIB_DIRNAMES += elf under > @@ -71,7 +71,7 @@ > # Currently there is a bug somewhere in GCC's alias analysis > # or scheduling code that is breaking _fpmul_parts in fp-bit.c. > # Disabling function inlining is a workaround for this problem. > -TARGET_LIBGCC2_CFLAGS = -Dinhibit_libc -fno-inline > +TARGET_LIBGCC2_CFLAGS = -Dinhibit_libc -fno-inline -msoft-float > > # Assemble startup files. > $(T)crti.o: $(srcdir)/config/arm/crti.asm $(GCC_PASSES) > > ----- end of patch file ----- > > GCC builds fine and builds the application fine. > > I try doing the same thing for gcc 4.1.0 and gcc builds fine, but when > it finally gets around to trying to link the executable, I get error > messages that I *think* mean that libgcc is being built with arm > floating point instructions, for instance: > > /usr/local/gnuarm-4.1.0/bin/arm-elf-ld: ERROR: > /usr/local/gnuarm-4.1.0/lib/gcc/arm-elf/4.1.0/interwork/libgcc.a(_clz.o) > uses FPA instructions, whereas application.elf does not > How did you try to build gcc-4.1. Can you give the whole build command. Can you paste relevant 10-20 lines above the error. I tried it like this and got it installed. ~/gcc-4.1.0/configure --target=arm-elf --prefix=/home/pro/armenv/ --with-float=soft --with-newlib --without-headers --enable-languages=c --disable-nls --disable-shared --disable-thread /home/pro/armenv/lib/gcc/arm-elf/4.1.0/libgcc.a /home/pro/armenv/lib/gcc/arm-elf/4.1.0/thumb/libgcc.a Please provide more details so that we can help you out. > I've tried every configuration option I can think of to build libgcc > without floating point, but have not managed to do so. > > As I said, I'm obviously doing something dumb, and any help in > figuring out what I should do instead would be greatly appreciated. > > Thanks, > > Marty > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: need help with gcc 4.1.0 crosscompiler for arm 2006-04-13 7:25 ` Niklaus @ 2006-04-13 22:53 ` marty fouts 2006-04-14 4:53 ` Niklaus 2006-04-15 12:20 ` Hanumesh R 0 siblings, 2 replies; 11+ messages in thread From: marty fouts @ 2006-04-13 22:53 UTC (permalink / raw) To: Niklaus; +Cc: gcc-help [-- Attachment #1: Type: text/plain, Size: 2355 bytes --] On 4/13/06, Niklaus <niklaus@gmail.com> wrote > How did you try to build gcc-4.1. Can you give the whole build command. > Please provide more details so that we can help you out. > I've attached a shar file with all the details. Unpack it into an empty directory, cd to that directory, and try 'sh ./makeit' This will fetch binutils and gcc; configure and make binutils and gcc; and then attempt to use arm-elf-gcc to compile a tiny c program that demonstrates the problem. (Obviously, if you already have binutils and gcc tgz files, you can comment out the wgets before running the script and replace them with references to your local copies.) ----- demo.c int _start() { double f = 1.23; return f; } ----- Basically, if I tell arm-elf-gcc which arm processor I'm using, it recognizes that the processor has no floating point, so arm-elf-ld fails, as it should, with the messages: sponge:sf 500:arm/bin/arm-elf-gcc -mthumb-interwork -msoft-float -mcpu=arm926ej-s -c demo.c sponge:sf 501: arm/bin/arm-elf-ld -o demo.elf demo.o arm/lib/gcc/arm-elf/4.1.0/interwork/libgcc.a arm/bin/arm-elf-ld: ERROR: arm/lib/gcc/arm-elf/4.1.0/interwork/libgcc.a(_fixdfsi.o) uses FPA instructions, whereas demo.elf does not arm/bin/arm-elf-ld: failed to merge target specific data of file arm/lib/gcc/arm-elf/4.1.0/interwork/libgcc.a(_fixdfsi.o) if I remove '-mcpu=arm926ej-s' from the compile, then the ld will work, but i'll end up with floating point instructions on an arm processor that has no fp. The configuration and make steps from the attached script are: mkdir binutils-build cd binutils-build ../binutils-2.16.1/configure --prefix=$BASE/arm --target=arm-elf --enable-interwork --enable-multilib --with-float=soft make all && make install cd .. mkdir gcc-build cd gcc-build ../gcc-4.1.0/configure --prefix=$BASE/arm --target=arm-elf --enable-languages=c --with-float=soft --enable-interwork make all-gcc && make install-gcc cd .. The problem seems to be that I'm not passing the right arguments to gcc-4.1.0/configure to cause it to not build libgcc.a with floating point. All help is appreciated. If the shar file attachment doesn't make it through, it can be picked up via wget http://www.fogey.com/bug.shar or wget http://www.fogey.com/bug.tgz Marty [-- Attachment #2: bug.shar --] [-- Type: application/x-shar, Size: 10135 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: need help with gcc 4.1.0 crosscompiler for arm 2006-04-13 22:53 ` marty fouts @ 2006-04-14 4:53 ` Niklaus 2006-04-14 5:07 ` marty fouts 2006-04-15 12:20 ` Hanumesh R 1 sibling, 1 reply; 11+ messages in thread From: Niklaus @ 2006-04-14 4:53 UTC (permalink / raw) To: marty fouts; +Cc: gcc-help On 4/14/06, marty fouts <mf.danger@gmail.com> wrote: > On 4/13/06, Niklaus <niklaus@gmail.com> wrote > > How did you try to build gcc-4.1. Can you give the whole build command. > > Please provide more details so that we can help you out. > > > > I've attached a shar file with all the details. Unpack it into an > empty directory, cd to that directory, and try 'sh ./makeit' This > will fetch binutils and gcc; configure and make binutils and gcc; and > then attempt to use arm-elf-gcc to compile a tiny c program that > demonstrates the problem. (Obviously, if you already have binutils and > gcc tgz files, you can comment out the wgets before running the script > and replace them with references to your local copies.) > > ----- demo.c > int _start() > { > double f = 1.23; > return f; > } > ----- > > > Basically, if I tell arm-elf-gcc which arm processor I'm using, it > recognizes that the processor has no floating point, so arm-elf-ld > fails, as it should, with the messages: > > sponge:sf 500:arm/bin/arm-elf-gcc -mthumb-interwork -msoft-float > -mcpu=arm926ej-s -c demo.c > sponge:sf 501: arm/bin/arm-elf-ld -o demo.elf demo.o > arm/lib/gcc/arm-elf/4.1.0/interwork/libgcc.a > > arm/bin/arm-elf-ld: ERROR: > arm/lib/gcc/arm-elf/4.1.0/interwork/libgcc.a(_fixdfsi.o) uses FPA > instructions, whereas demo.elf does not > arm/bin/arm-elf-ld: failed to merge target specific data of file > arm/lib/gcc/arm-elf/4.1.0/interwork/libgcc.a(_fixdfsi.o) > > > if I remove '-mcpu=arm926ej-s' from the compile, then the ld will > work, but i'll end up with floating point instructions on an arm > processor that has no fp. > > The configuration and make steps from the attached script are: > > mkdir binutils-build > cd binutils-build > ../binutils-2.16.1/configure --prefix=$BASE/arm --target=arm-elf > --enable-interwork --enable-multilib --with-float=soft > make all && make install > cd .. > pro@deb:~/armenv/bin$ ./arm-elf-gcc -v Using built-in specs. Target: arm-elf Configured with: /home/pro/gcc-4.1.0/configure --target=arm-elf --prefix=/home/pro/armenv/ --with-float=soft --with-newlib --without-headers --enable-languages=c --disable-nls --disable-shared --disable-thread Thread model: single gcc version 4.1.0 pro@deb:~/armenv/bin$ pro@deb:~/armenv/bin$ cat foo.c int _start() { double f = 1.23; return f; } pro@deb:~/armenv/bin$ ./arm-elf-gcc -c foo.c pro@deb:~/armenv/bin$ file foo.o foo.o: ELF 32-bit LSB relocatable, ARM, version 1 (ARM), not stripped pro@deb:~/armenv/bin$ ./arm-elf-ld -o demo.elf foo.o ../lib/gcc/arm-elf/4.1.0/libgcc.a i usually build binutils first. Then export the PATH for binutils prefix/bin. then build gcc bootstrap (stage1). Does this help you ? If not ask for more. You can add newlib or glibc after gcc bootstrap. > mkdir gcc-build > cd gcc-build > ../gcc-4.1.0/configure --prefix=$BASE/arm --target=arm-elf > --enable-languages=c --with-float=soft --enable-interwork > > make all-gcc && make install-gcc > cd .. > > The problem seems to be that I'm not passing the right arguments to > gcc-4.1.0/configure to cause it to not build libgcc.a with floating > point. > > All help is appreciated. > > If the shar file attachment doesn't make it through, it can be picked up via > wget http://www.fogey.com/bug.shar > > or > > wget http://www.fogey.com/bug.tgz > > Marty > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: need help with gcc 4.1.0 crosscompiler for arm 2006-04-14 4:53 ` Niklaus @ 2006-04-14 5:07 ` marty fouts 2006-04-14 6:18 ` Niklaus 0 siblings, 1 reply; 11+ messages in thread From: marty fouts @ 2006-04-14 5:07 UTC (permalink / raw) To: Niklaus; +Cc: gcc-help On 4/13/06, Niklaus <niklaus@gmail.com> wrote: [much snippage] > > Basically, if I tell arm-elf-gcc which arm processor I'm using, it > > recognizes that the processor has no floating point, so arm-elf-ld > > fails, as it should, with the messages: > > sponge:sf 500:arm/bin/arm-elf-gcc -mthumb-interwork -msoft-float > > -mcpu=arm926ej-s -c demo.c > > if I remove '-mcpu=arm926ej-s' from the compile, then the ld will > > work, but i'll end up with floating point instructions on an arm > > processor that has no fp. > > > pro@deb:~/armenv/bin$ ./arm-elf-gcc -c foo.c > pro@deb:~/armenv/bin$ file foo.o > foo.o: ELF 32-bit LSB relocatable, ARM, version 1 (ARM), not stripped > pro@deb:~/armenv/bin$ ./arm-elf-ld -o demo.elf foo.o > ../lib/gcc/arm-elf/4.1.0/libgcc.a > Does this help you ? If not ask for more. You can add newlib or glibc > after gcc bootstrap. Thanks very much for taking the time to look at this. Sorry, but it doesn't help. If you leave off the -mcpu=arm96ej-s option, than you get an elf binary with floating point. What I really need is instructions for building libgcc.a for arm w/o any FP instructions in it, and especially, without the FP based calling sequences. In particular, why did this work in 3.4 but not 4.1? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: need help with gcc 4.1.0 crosscompiler for arm 2006-04-14 5:07 ` marty fouts @ 2006-04-14 6:18 ` Niklaus 0 siblings, 0 replies; 11+ messages in thread From: Niklaus @ 2006-04-14 6:18 UTC (permalink / raw) To: marty fouts; +Cc: gcc-help On 4/14/06, marty fouts <mf.danger@gmail.com> wrote: > On 4/13/06, Niklaus <niklaus@gmail.com> wrote: > > [much snippage] > > > > Basically, if I tell arm-elf-gcc which arm processor I'm using, it > > > recognizes that the processor has no floating point, so arm-elf-ld > > > fails, as it should, with the messages: > > > > sponge:sf 500:arm/bin/arm-elf-gcc -mthumb-interwork -msoft-float > > > -mcpu=arm926ej-s -c demo.c > > > if I remove '-mcpu=arm926ej-s' from the compile, then the ld will > > > work, but i'll end up with floating point instructions on an arm > > > processor that has no fp. > > > > > > pro@deb:~/armenv/bin$ ./arm-elf-gcc -c foo.c > > pro@deb:~/armenv/bin$ file foo.o > > foo.o: ELF 32-bit LSB relocatable, ARM, version 1 (ARM), not stripped > > pro@deb:~/armenv/bin$ ./arm-elf-ld -o demo.elf foo.o > > ../lib/gcc/arm-elf/4.1.0/libgcc.a > > > Does this help you ? If not ask for more. You can add newlib or glibc > > after gcc bootstrap. > > Thanks very much for taking the time to look at this. Sorry, but it > doesn't help. If you leave off the -mcpu=arm96ej-s option, than you > get an elf binary with floating point. > Yeah you are right, i got the same error that you got when doing it with mcpu=arm96ej-s. Now i built gcc --with-cpu.see below it seems to work fine. pro@deb:~/armenv/bin$ cat foo.c int _start() { double f = 1.23; return f; } pro@deb:~/armenv/bin$ ./arm-elf-gcc -v Using built-in specs. Target: arm-elf Configured with: /home/pro/gcc-newlib/configure --target=arm-elf --prefix=/home/pro/armenv/ --with-cpu=arm926ej-s --with-newlib --disable-nls --disable-shared --disable-thread --enable-languages=c --disable-libssp Thread model: single gcc version 4.1.0 pro@deb:~/armenv/bin$ ./arm-elf-gcc -msoft-float -mcpu=arm926ej-s -c foo.c cc1: error: unrecognized command line option "-mcput=arm926ej-s" pro@deb:~/armenv/bin$ ./arm-elf-gcc -msoft-float -mcpu=arm926ej-s -c foo.c pro@deb:~/armenv/bin$ ./arm-elf-ld -o demo.elf foo.o ../lib/gcc/arm-elf/4.1.0/libgcc.a pro@deb:~/armenv/bin$ > What I really need is instructions for building libgcc.a for arm w/o > any FP instructions in it, and especially, without the FP based > calling sequences. In particular, why did this work in 3.4 but not > 4.1? I think there are not FP instructions in libgcc.a in this case. Let me know if you have any problems. > Well this also works pro@deb:~/armenv/bin$ ./arm-elf-gcc -msoft-float -mcpu=arm926ej-s -c foo.c pro@deb:~/armenv/bin$ ./arm-elf-ld -o demo.elf foo.o ../lib/gcc/arm-elf/4.1.0/ crtbegin.o crti.o include/ libgcc.a thumb/ crtend.o crtn.o install-tools/ libgcov.a pro@deb:~/armenv/bin$ ./arm-elf-ld -o demo.elf foo.o ../lib/gcc/arm-elf/4.1.0/libgcc.a pro@deb:~/armenv/bin$ ./arm-elf-gcc -v Using built-in specs. Target: arm-elf Configured with: /home/pro/gcc-newlib/configure --target=arm-elf --prefix=/home/pro/armenv/ --with-cpu=arm926ej-s --with-newlib --disable-nls --disable-shared --disable-thread --disable-libssp --enable-languages=c --with-float=soft Thread model: single gcc version 4.1.0 pro@deb:~/armenv/bin$ cat foo.c int _start() { double f = 1.23; return f; } pro@deb:~/armenv/bin$ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: need help with gcc 4.1.0 crosscompiler for arm 2006-04-13 22:53 ` marty fouts 2006-04-14 4:53 ` Niklaus @ 2006-04-15 12:20 ` Hanumesh R 2006-04-16 6:48 ` Niklaus 1 sibling, 1 reply; 11+ messages in thread From: Hanumesh R @ 2006-04-15 12:20 UTC (permalink / raw) To: gcc-help Hi, Please help me out. i am trying to create a shared library using arm-elf-gcc for arm on uClinux. for that what are the flags required pls reply me . currently i am using -mid-shared-library and for id -mshared-library-id=0 were not able to recognise. is their any alternate flags for these ? or i am doing totally wrong? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: need help with gcc 4.1.0 crosscompiler for arm 2006-04-15 12:20 ` Hanumesh R @ 2006-04-16 6:48 ` Niklaus 2006-04-17 19:43 ` Free Lunch cino hilliard 0 siblings, 1 reply; 11+ messages in thread From: Niklaus @ 2006-04-16 6:48 UTC (permalink / raw) To: Hanumesh R; +Cc: gcc-help On 4/15/06, Hanumesh R <hamsy.rh@gmail.com> wrote: > Hi, > Please help me out. > i am trying to create a shared library using arm-elf-gcc for arm on uClinux. for > that what are the flags required pls reply me . currently i am using > -mid-shared-library and for id -mshared-library-id=0 were not able to recognise. > is their any alternate flags for these ? or i am doing totally wrong? What shared library are you trying to use ? Which files are you using those mid-shared-libary options on . What are you trying to do . Please provide more details so that we can help you. Also create a seperate thread/mail. As the list is archived i think it will have wrong followups when viewed. > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Free Lunch 2006-04-16 6:48 ` Niklaus @ 2006-04-17 19:43 ` cino hilliard 2006-04-18 10:14 ` Andrew Haley 0 siblings, 1 reply; 11+ messages in thread From: cino hilliard @ 2006-04-17 19:43 UTC (permalink / raw) To: gcc-help The following code appears to provide a free lunch. Can someone try this on their systems to see if they get similar results? Thanks, Cino // Free Lunch // //Mind boggling code in Gcc 3.4.4. incrementing a variable in a loop runs 20 times faster than just //an empty loop. //System: p4 2.53 ghz xp pro //Compile data //C:\gcc\examples>f:\gcc\bin\g++ COUNTgcc.c -o COUNTgcc.exe -s -O3 -mtune=pentium4 //C:\gcc\examples>g++ -dumpversion //3.4.4 #include <windows.h> #include <stdio.h> #define timer GetTickCount()/1000.0 float t1,t2; long count1(long); long count2(long); int main() { t1=timer; printf("%s%u\n"," j = ",count1(2000000000)); t2=timer; printf("%s%f\n"," Sec = ",t2-t1); printf("\n"); t1=timer; printf("%s%u\n"," y = ",count2(2000000000)); t2=timer; printf("%s%f\n"," Sec = ",t2-t1); getchar(); return 0; } long count1(long i) { long j; for(j=1;j<=i;j++) { } return j; } long count2(long i) { long j,y=0,s=0; for(j=1;j<=i;j++) { y+=1; //s+=7; } return y; } output j = 2000000001 Sec = 0.984375 y = 2000000000 Sec = 0.046875 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Free Lunch 2006-04-17 19:43 ` Free Lunch cino hilliard @ 2006-04-18 10:14 ` Andrew Haley 2006-04-18 20:52 ` cino hilliard 0 siblings, 1 reply; 11+ messages in thread From: Andrew Haley @ 2006-04-18 10:14 UTC (permalink / raw) To: cino hilliard; +Cc: gcc-help cino hilliard writes: > The following code appears to provide a free lunch. Can someone try this on > their systems > to see if they get similar results? > > Thanks, > Cino > > // Free Lunch > // > //Mind boggling code in Gcc 3.4.4. incrementing a variable in a loop runs 20 > times faster than just > //an empty loop. There's a good reason for this. You can discover it by reading gcc's documentation. See ``Deleting "empty" loops''. Andrew. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Free Lunch 2006-04-18 10:14 ` Andrew Haley @ 2006-04-18 20:52 ` cino hilliard 0 siblings, 0 replies; 11+ messages in thread From: cino hilliard @ 2006-04-18 20:52 UTC (permalink / raw) To: gcc-help >From: Andrew Haley <aph@gcc.gnu.org> >To: "cino hilliard" <hillcino368@hotmail.com> >CC: gcc-help@gcc.gnu.org >Subject: Re: Free Lunch >Date: Tue, 18 Apr 2006 11:14:37 +0100 > > >There's a good reason for this. You can discover it by reading gcc's >documentation. See ``Deleting "empty" loops''. Ok here it is. Historically, GCC has not deleted Âempty loops under the assumption that the most likely reason you would put one in a program is to have a delay, so deleting them will not make real programs run any faster. However, the rationale here is that optimization of a nonempty loop cannot produce an empty one. This held for carefully written C compiled with less powerful optimizers but is not always the case for carefully written C++ or with more powerful optimizers. Thus GCC will remove operations from loops whenever it can determine those operations are not externally visible (apart from the time taken to execute them, of course). As GCC improves, it will remove the loop itself. Indeed, with Â-funroll-loops small loops can already be removed, so leaving an empty non-unrolled loop is both suboptimal and inconsistent. Be aware of this when performing timing tests, for instance the following loop can be completely removed, provided some_expression can provably not change any global state. { int sum = 0; int ix; for (ix = 0; ix != 10000; ix++) sum += some_expression; } Now based on this, I modifed the code shown below to produce the following timing. 2000000000 Sec = 1.640625 2000000001 Sec = 1.000000 So count1 loop which has the assignment statement z=x takes 1.64 sec while count 2 which which has 3 assignment statements z=j; y+=1; s=y+1; Yet count 2 executes in .64 sec secs less time. That is the free lunch. The best I can do in just an empty loop in assembly language A386 is 2.47. Some of the time is probably the timer and output routines. On my p3 1 ghz system I get count1 4.171875 sec count2 4.187500 sec1 a small price for 2 billion loops of y+=1; s=y+1; The gcc assembly code appears to produce 2 bill loops for both functions Also if we change the type to unsigned long and use 4000000000UL, we get 4000000000 Sec = 3.234375 4000000001 Sec = 0.000000 If we relax the -O3 optimization switch, the free lunch goes BY By as we get, 4000000000 Sec = 8.125000 4000000001 Sec = 17.531250 Similarly for type long we get 2000000000 Sec = 4.031250 2000000001 Sec = 8.828125 And the free lunch goes BY By. To Optimize or not to Optimize, that is the question. Dog gone it TANSTAAFL! Have fun, Cino ***********************************code******************************** // Free Lunch //> Executing: c:\context\ConExec.exe "gc2.bat" COUNTgcc //C:\gcc\examples>f:\gcc\bin\g++ COUNTgcc.c -o COUNTgcc.exe -s -O3 -mtune=pentium4 //C:\gcc\examples>rem g++ -c -g -Wa,-a,-ad COUNTgcc.c > COUNTgcc.lst //C:\gcc\examples>g++ -S -c COUNTgcc.c //C:\gcc\examples>g++ -dumpversion //3.4.4 //> Execution finished. //System: p4 2.53 ghz xp pro #include <windows.h> #include <stdio.h> #define timer GetTickCount()/1000.0 float t1,t2; long count1(long); long count2(long); int main() { long j1,j2; t1=timer; j1 = count1(2000000000); t2=timer; printf("%u\n",j1); printf("%s%f\n"," Sec = ",t2-t1); printf("\n"); t1=timer; j2 = count2(2000000000); t2=timer; printf("%u\n",j2); printf("%s%f\n"," Sec = ",t2-t1); getchar(); return 0; } long count1(long y) { long x,z; for(x=1;x<=y;x++) { z=x; } return z; } long count2(long i) { long j,y=0,s=0,z; for(j=1;j<=i;j++) { z=j; y+=1; s=y+1; } return s; } ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-04-18 20:52 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-04-12 23:11 need help with gcc 4.1.0 crosscompiler for arm marty fouts 2006-04-13 7:25 ` Niklaus 2006-04-13 22:53 ` marty fouts 2006-04-14 4:53 ` Niklaus 2006-04-14 5:07 ` marty fouts 2006-04-14 6:18 ` Niklaus 2006-04-15 12:20 ` Hanumesh R 2006-04-16 6:48 ` Niklaus 2006-04-17 19:43 ` Free Lunch cino hilliard 2006-04-18 10:14 ` Andrew Haley 2006-04-18 20:52 ` cino hilliard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).