Download Red Hat Enterprise Linux 7 Developer Guide

⁠Chapt er 3. Compiling and Building
Therefore, atomic transactions can be nested within other atomic and relaxed transactions, but
relaxed transactions can only be nested within other relaxed transactions. Furthermore, relaxed
transactions are likely to be executed with less performance, but this depends on the implementation
and available hardware.
GCC verifies these restrictions statically at compile time (for example, the requirements on code
allowed to be called from within atomic transactions). This has implications for when transactions
call functions that are defined within other compilation unit (source file) or within libraries. To enable
such cross-compilation-unit calls for transactional code, the respective functions must be marked to
contain code that is safe to use from within atomic transactions. Programmers can do so by adding
the transacti o n_safe function attribute to the declarations of these functions and by including
this declaration when defining the function. In turn, GCC then verifies that the code in these functions
is safe for atomic transactions and generates code accordingly. If the programmer does not follow
these constraints and/or steps, compile-time or link-time errors occur. Note that within a compilation
unit, GCC detects automatically whether a function is safe for use within transactions, and the
attributes therefore typically do not need to be added. See the draft specification linked above for
further details.
GCC's transactional memory support is designed in such a way that it does not decrease the
performance of programs that do not use transactions, nor the performance of nontransactional
code, except due to the normal kinds of interference by concurrent threads that use the same
resources such as the CPU.
Transactional memory support in GCC and l i bi tm is still experimental, and both the ABI and API
could change in the future if this is required due to the evolution of the specification of the language
constructs, or due to implementation requirements. Note that when executing applications built with
the -fg nu-tm command line option, it is currently a prerequisite to also have the appropriate version
of the l i bi tm. so . 1 shared library installed.
3.1.1.2.1.4 . Arch it ect u re- sp ecif ic O p t io n s
Red Hat D eveloper Toolset 2.0 is only available for Red Hat Enterprise Linux 5 and 6, both for the
32-bit and 64-bit Intel and AMD architectures. Consequently, the options described below are only
relevant to these architectures.
Optimization for several processors is now available through the command line options described in
Table 3.5, “ Processor Optimization Options” .
T ab le 3.5. Pro cesso r O p t imiz at io n O p t io n s
O p t io n
D escrip t io n
-march= co re2 and -mtune= co re2
-march= co rei 7 and -mtune= co rei 7
Optimization for Intel Core 2 processors.
Optimization for Intel Core i3, i5, and i7
processors.
Optimization for Intel Core i3, i5, and i7
processors with AVX.
Optimization for the Intel processor code-named
Ivy Bridge with RD RND , FSGSBASE, and F16C.
Optimization for a next-generation processor
from Intel with AVX2, FMA, BMI, BMI2, and
LZ CNT.
Optimization for AMD Opteron processors codenamed Piledriver.
Optimization for AMD family 14 processors
code-named Bobcat.
-march= co rei 7-avx and -mtune= co rei 7avx
-march= co re-avx-i
-march= co re-avx2
-march= bd ver2 and -mtune= bd ver2
-march= btver1 and -mtune= btver1
59