need help with gcc 4.1.0 crosscompiler for arm

need help with gcc 4.1.0 crosscompiler for arm

[marty fouts]

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

Re: need help with gcc 4.1.0 crosscompiler for arm

[Niklaus]

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
>

Re: need help with gcc 4.1.0 crosscompiler for arm

[marty fouts]

[-- 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 --]

Re: need help with gcc 4.1.0 crosscompiler for arm

[Niklaus]

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
>
>
>

Re: need help with gcc 4.1.0 crosscompiler for arm

[marty fouts]

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?

Re: need help with gcc 4.1.0 crosscompiler for arm

[Niklaus]

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$

Re: need help with gcc 4.1.0 crosscompiler for arm

[Hanumesh R]

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?

Re: need help with gcc 4.1.0 crosscompiler for arm

[Niklaus]

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.
>
>
>

Free Lunch

[cino hilliard]

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

Re: Free Lunch

[Andrew Haley]

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.

Re: Free Lunch

[cino hilliard]

>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;
}