Summary: What do the -f and -m in gcc and clang compiler options stand for?
Details:
When using clang I've noticed that many compiler options start with -f and others start with -m. I assume that there is some historical reason for this and I was curious so I looked at the gcc help and saw the following:
Options starting with -g, -f, -m, -O, -W, or --param are automatically
passed on to the various sub-processes invoked by gcc. In order to
pass other options on to these processes the -W options must
be used.
If I had to guess I think that -f might stand for frontend and -m for machine. But I'd be interested to hear a more comprehensive answer, possibly including the other sub-processes that gcc invokes.
I don't have specific sources that state what 'f' and 'm' mean, but we can infer based on usage patterns found in documentation.
'f' stands for 'flag'.
Flags are on if specified via '-fFLAG' and off via '-fno-FLAG'
ex:
-fpic # flag to set position independent code
-fno-builtin # don't recognize build in functions ...
The technical definition is that 'f' defines "Control the interface conventions used in code generation".
Src:
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
(e.g -fpci, when this flag is set)
'm' stands for mode. One general characteristic is that it sometimes has parameters. e.g
-mabi=name #abi mode = name
-mcpu=cpu
Src:
https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html (e.g ... when this mode...)
According to gcc onlinedocs, options of the form -ffoo and -fno-foo stand for machine independent code generation conventions.
Examples: fpic, -fno-pic
-m options stand for machine dependent options.
eg: -mcpu, -march, -matomic
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options or https://home.cs.colorado.edu/~main/cs1300/doc/gnu/gcc_2.html#SEC43
https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html#Submodel-Options or https://home.cs.colorado.edu/~main/cs1300/doc/gnu/gcc_2.html#SEC16
Related
In gcc we have -x option that use to specify how to treat source file.
For example suppose we have a csourcecode file without any extension like .c.
In gcc simply using -x c before express csourcecode force compiler to use it as valid c source code.
gcc -x c csourcecode -o out
Is there any similar option for gfortran?
From the helpful gcc manual: [Note 1]
You can specify the input language explicitly with the -x option:
-x language
Specify explicitly the language for the following input files
(rather than letting the compiler choose a default based on the
file name suffix). This option applies to all following input
files until the next -x option. Possible values for language
are:
(snip)
f77 f77-cpp-input f95 f95-cpp-input
If you're using a Unix-y system and you took the precaution of installing the gcc documentation package (apt-get install gcc-doc on debian/ubuntu-like systems), then you could have found that information directly by typing
info gcc --index-search=x
because the GCC info files are index by option name. Most of the time you don't need to type --index-search=; info gcc x would suffice.
Notes:
In case it's not obvious, gfortran is just another front-end for the Gnu compiler collection ("gcc" for short), and accepts any options that would be accepted by the gcc command.
I'm learning GCC and Bazel. I want to enable all the optimization for Bazel to build a project which requires the best performance.
Then I found -c opt which means to set the compilation mode to optimized without debug information.
And --copt=-O3 means set the optimization level to the third one. There are -O2, -Os, etc.
I'm confused with these two options.
What is the difference between -c opt and --copt=-O3?
Will they trigger each other. So I only need to write one of them with bazel build?
--copt is for passing args to to the compiler.
-c is a short form of --compilation-mode.
Its effect is described in the user-manual:
It sets compiler options (e.g. -c opt implies -O2 -DNDEBUG)
There are different output directories per compilation mode, so you can switch between debug and optimized builds without full recompilation.
So usually, -c optis enough. If you want the behaviour of -c opt but with a different optimization level, you combine the two options like in -c opt --copt=-O3 and the compiler will get both options -O2 and -O3, but the last one will win.
And watch out, there is a third similar option:
--config=configname is for selecting a configuration. You can have a .bazelrc which defines default options. Some of them are not always active, but some only if you activate them by the --config=configname command line option. Now opt is a popular configname, so if you have a .bazelrc that contains
build:opt --copt=-O3
then bazel build --config=opt has the same effect as bazel build --copt=-O3
Summary: What do the -f and -m in gcc and clang compiler options stand for?
Details:
When using clang I've noticed that many compiler options start with -f and others start with -m. I assume that there is some historical reason for this and I was curious so I looked at the gcc help and saw the following:
Options starting with -g, -f, -m, -O, -W, or --param are automatically
passed on to the various sub-processes invoked by gcc. In order to
pass other options on to these processes the -W options must
be used.
If I had to guess I think that -f might stand for frontend and -m for machine. But I'd be interested to hear a more comprehensive answer, possibly including the other sub-processes that gcc invokes.
I don't have specific sources that state what 'f' and 'm' mean, but we can infer based on usage patterns found in documentation.
'f' stands for 'flag'.
Flags are on if specified via '-fFLAG' and off via '-fno-FLAG'
ex:
-fpic # flag to set position independent code
-fno-builtin # don't recognize build in functions ...
The technical definition is that 'f' defines "Control the interface conventions used in code generation".
Src:
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
(e.g -fpci, when this flag is set)
'm' stands for mode. One general characteristic is that it sometimes has parameters. e.g
-mabi=name #abi mode = name
-mcpu=cpu
Src:
https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html (e.g ... when this mode...)
According to gcc onlinedocs, options of the form -ffoo and -fno-foo stand for machine independent code generation conventions.
Examples: fpic, -fno-pic
-m options stand for machine dependent options.
eg: -mcpu, -march, -matomic
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options or https://home.cs.colorado.edu/~main/cs1300/doc/gnu/gcc_2.html#SEC43
https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html#Submodel-Options or https://home.cs.colorado.edu/~main/cs1300/doc/gnu/gcc_2.html#SEC16
I have seen makefiles use the -DLINUX flag but can't find any documentation on it.
Is there a place to find information on tools like 'gcc' that are more up-to-date than
the officially released manuals?
It just defines the LINUX symbol for the C preprocessor.
Probably there are pieces of the code that look like:
#ifdef LINUX
//Linux-specific code
#elif defined WINDOWS
//Windows-specific code
#endif
It's the -D option controlling the preprocessor. It defines the LINUX macro, that you can then use with #ifdef.
According to man gcc:
-D name
Predefine name as a macro, with definition 1.
Hence, it let define a constant from the compilation command line.
It defines a preprocessor macro named LINUX. That's it. The macro itself, LINUX, is not a predefined one, it's probably used for a cross-platform codebase where specific sections of code are enabled for a Linux target. For this purpose, one could actually have re-used the predefined linux or __linux__ ones (see the output of gcc -dP -E - < /dev/null to get all the predefined macros on your system).
See http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/ for the standard documentation on gcc (that's obviously for GCC 4.8.2). To my knowledge, that's the best place to look for if this documentation is not already installed (or up-to-date) on your system.
Is there a way to change the specs file so that it will pass -march=native if nothing is specified in command line?
Related things in the default specs file is:
*cc1:
%(cc1_cpu)
*cc1_cpu:
%{march=native:%>march=native %:local_cpu_detect(arch) %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)}} %{mtune=native:%>mtune=native %:local_cpu_detect(tune)}
I am not sure how specs works. Simply specifying -march=native before or after %(cc1_cpu) doesn't work. However, this line does take effect because GCC will report error if I put -something_wierd instead of -march=native.
Another thing I noticed is if I put %{march=i386:-something_wierd} before %(cc1_cpu), gcc reports error so looks like -march=i386 is always passed in if nothing is specified, so is there a way to distinguish between nothing specified and -march=i386 in specs file?
BTW, what does %> do? Seems like it is not specified in the documentation.
I am using MinGW's gcc-4.6.2.
Referring to your last question: The gcc 4.6.1 sources (gcc/gcc.c) contain the following comment on %>:
%>S Similar to "%<S", but keep it in the GCC command line.
For the sake of completeness following the comment for %< form the same file:
%<S remove all occurrences of -S from the command line.
Note - this command is position dependent. % commands in the
spec string before this one will see -S, % commands in the
spec string after this one will not.
To answer the first question in short: yes, but ....
... the only generic solution I found has the significant drawback that the -march option will be ignored, so every build is done as if -march=native had been specified. Anyhow there is a workaround to that.
1 The solution (without workaround)
Create a specs-file called let's say specs.nativealways containing:
*cc1_cpu:
%<march=* -march=native %>march=native %:local_cpu_detect(arch) %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)} %{mtune=native:%>mtune=native %:local_cpu_detect(tune)}
When using the specs-file (for example by invoking gcc with the option -specs=specs.nativealways) the build will be done as if -march=native was specified (with the mentioned drawback that any occurrence of option -march=<arch> would have simply been ignored).
2 The workaround
To still by able to override the newly configured default behavior one can use a modified version of the specs-file described above, introducing a new option called -myarch using the same syntax as -march (except for -myarch=native, which won't work, which does not metter as native now is the default).
The modfied specs-file looks like this:
*cc1_cpu:
%<march=* %{myarch=*:%<myarch* -march=%* ; :-march=native %>march=native %:local_cpu_detect(arch) %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)}} %{mtune=native:%>mtune=native %:local_cpu_detect(tune)}
PS: This has been tested with with gcc 4.6.2 on Linux, but should work on MinGW.
While not a direct answer to your question, you can reach a very similar effect by defining CFLAGS and CXXFLAGS in your shell's initialization file. 99% of the Makefiles are sufficiently standard to pick up the environment values and pass the flags to gcc.
*cc1_cpu:
+ %{!march*:-march=native}