Adrian Smarzewski adrians at aska.com.pl
Wed Nov 27 15:26:13 PST 2002

Of course I have additional questions :)

> 1) It detects your CPU type/class (e.g. i686, i586, etc).  It compiles apps
> natively for that CPU (i.e. won't work on any CPU below that class).

Is it detected by configure (and passed to gcc as argument) or by gcc?
If by gcc than why configure script tries to detect it?

> 2) I don't think you need to (remember previous versions of gcc defaulted to
> i386 so this flag was always required for such optimizations to occur).

I thought gcc was called with argument passed from configure.

> 3) If you don't specify -march=<processor-type> then as mentioned by 1)
> above the apps simply won't work on anything below the CPU that gcc compiled
> it for

I thought the argument --target/--host=i386-pc-linux-gnu for example will
be sufficient. Why not?

> 4) I don't think that it's neccessarily buggy gcc code, just that each app
> has different code, so it's not possible to always get the optimization
> right.

I don't understand it :) applications are written in C code, optimization
is only for example inlining functions, unrolling loops and so on.
If the algorithm is good and the C code is good why can gcc create bad binary

> 5) I believe that should be don't set optimization specific options in your
> CFLAGS.  That is don't specify -Ox of the -f-omit-pointer, -f-unroll-loops
> and such like.

So can I compile glibc and gcc with CFLAGS="-march=athlon-xp"?
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message

More information about the lfs-support mailing list