Hi. I'm sure this has been covered somewhere before, but I couldn't find anything and so figured I would post here.

I have been using Linux OSes for the past couple of years and also using GCC/G++ for application development. However, I have almost always been on x86 systems and never gained much experience using the wide range of optimization options available.

My question is, if I do not specify the -march=PROCTYPE option, will GCC still be able to detect the current architecture and build the code accordingly? I primarily ask this because I am working with an x86_64 system, and specifying -march=x86_64 in my makefiles generates errors about it being an unknown processor type, even though the CPU and OS are X86_64.

I know this sounds like a newbie question, but it's just ground I've never had to cover before until now. Any advice is appreciated!

Thanks!

x86_64 isn't a proper arch type for the march option. If you're using a GCC newer than 4.3 you should be able to use -march=native. For more information on how -march and -m work together I've written a small article on the matter: http://www.alunduil.com/2009/12/18/o...gentoo-cflags/.

Regards,

Alunduil

x86_64 isn't a proper arch type for the march option. If you're using a GCC newer than 4.3 you should be able to use -march=native. For more information on how -march and -m work together I've written a small article on the matter: http://www.alunduil.com/2009/12/18/o...gentoo-cflags/.

Regards,

Alunduil

Alunduil, thanks for the swift response! The info and the link were definitely helpful. I believe my previous source that told me x86_64 was valid was outdated.

Something else I was wondering: what happens if the -march option is not specified at all? The code still builds fine without it, but I have no way of telling if it is 32 or 64 bit.

Thanks again!

Try

Assuming that your gcc's backend is x86_64 and you specified the -m64 option to generate 64-bit code, if you don't use the -march= option for gcc/g++, you'll get code generated for a common subset of x86_64 CPUs, meaning that it should run on a wide range (all) of x86_64 systems, but you possibly don't get all the optimizations/features which your specifc (local) CPU provides.

So, gcc always has a default path even if the user doesn't specify a concrete option. :-)

Right, the file command is absolute correct. It will display the ABI used. Just for your interest, the file command looks at the first bytes of the executable to determine what kind of executable format is used and which ABI is used. The default executable format on Linux is ELF and you'll get the ELF-ABI by using

# readelf -h /usr/bin/gcc
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
OS/ABI: UNIX - System V
Type: EXEC (Executable file)

That's all great information but I want to specify that the extra instruction sets that modern CPUs might have available are not going to be used at all to get the common CPU instructions that would run on a generic-x86_64.

Regards,

Alunduil

Oh, sh**! :-) I went through the code and finally found the mistake. Although it isn't (yet) documented in the man page, the correct switch name is -march=x86-64 to get the default setting. The difference between the dash and underscore was just too marginal to catch it in the first instance.

There already was a discussion on the GCC mailing list about the confusion by x86-64 and x86_64 (http://gcc.gnu.org/ml/gcc/2006-03/msg00229.html), but unfortunately without any result why x86_64 isn't allowed.

I think this needs to be changed in the documentation ...