Which version go g++/gcc support -xintruments=datarace #compiler option?
Which version go g++/gcc support -xintruments=datarace #compiler option?
None, such option is invalid and not supported by any gcc version. From gcc documentation about overall options:
-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:
c c-header cpp-output
c++ c++-header c++-system-header c++-user-header c++-cpp-output
objective-c objective-c-header objective-c-cpp-output
objective-c++ objective-c++-header objective-c++-cpp-output
assembler assembler-with-cpp
ada
d
f77 f77-cpp-input f95 f95-cpp-input
go
-x none
Turn off any specification of a language, so that subsequent files are handled according to their file name suffixes (as they are if -x
has not been used at all).
intruments=datarace is not a valid language.
Related
I was trying to make use of precompiled headers to speed up compilation following this link: https://codeforces.com/blog/entry/53909
I observed that pre-compilation of headers and subsequent compilation of .cpp programs have to be done using the same g++ flags for the speed-up to work, which makes sense. However, explicitly setting the c++ standard to the default one did not work. So, neither of pre-compilation using g++ stdc++.h and subsequent g++ -std=c++14 program.cpp, nor, g++ -std=c++14 and g++ program.cpp worked.
This didn't make sense to me as I knew that my compiler, x86_64-w64-mingw32-g++.exe (gcc version 10.2.0), by default, conforms to 201402L (c++14) standard, which I figured using g++ -dM -E -x c++ /dev/null | fgrep __cplusplus, and getting the following response:
#define __cplusplus 201402L
So, my question is, what is the difference between g++ and g++ -std=c++14 when g++, by default, adheres to 201402L? Also, is it significant enough for me to specifically opt for either one of them ?
GCC doesn't compile with -std=c++14 by default. The description of the -std flag from the GCC man pages (for version 9.3.0) says
-std= Determine the language standard. This option is currently only supported when compiling C or C++.
The compiler can accept several base standards, such as c90 or c++98, and GNU dialects of those standards, such as gnu90 or gnu++98. When a base standard is specified, the compiler accepts all programs following that standard plus those using GNU extensions that do not contradict it.
. . .
A value for this option must be provided; possible values are
. . .
c++14
c++1y
The 2014 ISO C++ standard plus amendments. The name c++1y is deprecated.
gnu++14
gnu++1y
GNU dialect of -std=c++14. This is the default for C++ code. The name gnu++1y is deprecated.
. . .
Emphasis mine. The current default is -std=gnu++14, which targets the C++14 standard while also enabling GNU extensions to the C++ language. The distinction between the -std=c++XX flags and the -std=gnu++XX flags is explained further in What are the differences between -std=c++11 and -std=gnu++11?.
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.
Sorry for noobie question but I could not understand this .. what does gcc -lnsl flag do .
I tried searching over internet also read about rpc.
This flag tells gcc to link the binary with nsl library. To be more clear, the line gcc -lnsl could be rewritten to more verbose equivalent gcc -l nsl. See man gcc:
-llibrary
-l library
Search the library named library when linking. (The second
alternative with the library as a separate argument is only for
POSIX compliance and is not recommended.)
The -l option is passed directly to the linker by GCC. Refer to
your linker documentation for exact details. The general
description below applies to the GNU linker.
The linker searches a standard list of directories for the
library. The directories searched include several standard
system directories plus any that you specify with -L.
Is there a compiler directive to tell gfortran-gcc compiler that the code is written in free-form? I have code written in a file with '.for' as extension (which is recognized as fixed-form), but the language is f95 free-form.
Adding a flag to the compiler options to force free-form is not possible for my application, hence it needs to be done using directives.
For ifort, the command is:
!DEC$ FREEFORM
For gfortran is should be something like:
!GCC$ DIRECTIVE
I have, unfortunately, not been able to find which command exactly.
No, there is none. Use the -ffree-form compiler option.
My toolchain is a recent version of arm-gcc.
I have a piece of code in an assembly file which must be conditionally included/assembled.
.ifdef MACRO_FROM_CMDLINE
Assembly instr1
Assembly instr2
.endif
Encapsulated code is a recent addition.
I have tried both:
gcc -x assembler-with-cpp --defsym MACRO_FROM_CMDLINE=1 <along with other necessary options>
gcc -x assembler-with-cpp -D MACRO_FROM_CMDLINE=1 <along with other necessary options>
The -D results in "Invalid identifier for .ifdef " and ".endif without .if" errors.
The --defsym results in "MACRO_FROM_CMDLINE=1 : No such file or directory", "unrecognized option --defsym" errors.
The gcc binary drives the compilation process by invoking a number of other programs in sequence to actually perform the various stages of work (compiling, assembling, linking).
When you say:
gcc -x assembler-with-cpp -D MACRO_FROM_CMDLINE=1 ...
you are asking it to run the source through the C preprocessor, and then run the result through the assembler.
The C preprocessor step will turn:
.ifdef MACRO_FROM_CMDLINE
into:
.ifdef 1
before passing it to the assembler, which then can't make sense of it. This is why you get the "invalid identifier" error. It also explains why using C preprocessor #ifdef fixes the problem.
--defsym doesn't work because it's an option to the assembler, not the gcc driver program. (The gcc driver does understand and pass through some options to some of the programs it invokes, but not all.)
You can, however, pass arbitrary options through to the assembler using the
-Wa,option[,option...]
syntax, which tells the gcc driver to pass those option(s) through to the assembler (as a list of space-separated options).
For example:
gcc -x assembler-with-cpp -Wa,--defsym,MACRO_FROM_CMDLINE=1 ...
adds
--defsym MACRO_FROM_CMDLINE=1
to the list of options passed to as when gcc invokes it, and that's how to make your original .ifdef example work.
You can see the individual programs invoked by gcc, and the options it actually passes to them, by adding the -v option.
In this case, you should see something called cc1 (the actual GCC C compiler binary) invoked with the -E flag (preprocess only) to preprocess the input to a temporary file, and then as invoked on the temporary file to assemble it.
Strange, but it it turns out I needed to use the C syntax in the assembly file.
#ifdef MACRO
Assembly Instruction
Assembly Instruction
#endif
And the macro had to be passed using the -D option.