ICX(1)

📦 version 2026.0.1.27+c9c3d3e3_ddb4_490e_bb41_6e9041ba32a7, in arch rolling

💅 ICX(1) — Intel(R) oneAPI C++ Compiler Options 💅

okay bestie, the tea is: the Intel(R) oneAPI C++ Compiler is based on open source LLVM* compiler technology. This man page describes the supported compiler options for the Intel(R) oneAPI C++ Compiler. iconic.

icx — invokes the C-based Intel(R) oneAPI C++ Compiler
icpx — invokes the C++-based Intel(R) oneAPI C++ Compiler

🚨 NOTE: the icpx command uses the same compiler options as the icx command. When you invoke the compiler with icpx, it compiles .c and .i files as C++. When you invoke it with icx, it compiles .c and .i files as C.

✨ SYNOPSIS ✨

To invoke the Intel(R) oneAPI C++ Compiler, it's giving:

icx/icpx [options] file1 [file2 ...]

where:

options represents zero or more compiler options.
fileN represents a C/C++ source (.C, .c, .cc, .cp, .cpp, .cxx, .c++, .i), assembly (.s), object (.o), static library (.a), or other linkable file.

🌈 NOTE: for SYCL capability, you must also specify option -fsycl.

For information about available SYCL drivers, refer to topic Invoke the Compiler in the Intel(R) oneAPI DPC++/C++ Compiler Developer Guide and Reference.

🌸 DESCRIPTION 🌸

The Intel(R) oneAPI C++ Compiler is designed to process C++ and C programs on Intel(R) 64 architecture-based systems. periodt.

This man page is intended for Linux* users.

Some options may be labeled as experimental features. An experimental feature is one that requires further testing and possible refinement. Depending on testing results, such features may be fully defined and implemented, or they may be removed in a future release.

You might see shortcut names in option descriptions that come from the Developer and Reference Guide. In that document, the shortcuts are used to avoid spelling out option syntax for different operating systems.

You may see either or both of these shortcuts:

If you see [Q]option-name, it means the Linux name of the option is what appears following [Q]. For example, if you see [Q]ipo, the Linux form of the option is -ipo.
If you see [q or Q]option-name, it means the Linux name of the option starts with a q. For example, if you see [q or Q]opt-report, the Linux form of the option is -qopt-report.

Otherwise, Linux* compiler option names are shown with an initial -.

🦋 Clang Option Support 🦋

Clang compiler options are supported for this compiler. We do not document these options, but you can check icx/icpx -help on the command line to see if a particular option is supported. For more information about Clang options, see https://clang.llvm.org/docs/ClangCommandLineReference.html.

💖 FEATURE REQUIREMENTS 💖

The following lists dependent features and their corresponding required products. Here's the dependency vibe: with certain compiler options, the compilation may fail if the option is specified but the required product is not installed. If that happens, remove the option from the command line and recompile. no cap.

Feature: -qtbb, -tbb, and /Qtbb options — Requirement: Intel(R) oneAPI Threading Building Blocks (oneTBB) installation
Feature: -mkl, -qmkl, -qmkl-ilp64, /Qmkl and /Qmkl-ilp64 options — Requirement: Intel(R) oneAPI Math Kernel Library (oneMKL) installation
Feature: -daal, -qdaal, and /Qdaal options — Requirement: Intel(R) oneAPI Data Analytics Library (oneDAL) installation
Feature: -ipp, -qipp, and /Qipp options — Requirement: Intel(R) Integrated Performance Primitives (Intel(R) IPP) installation
Feature: Use crypto to link to the Intel(R) IPP Cryptography library — Requirement: Intel(R) Integrated Performance Primitives Cryptography (Intel(R) IPP Cryptography) installation
Feature: Thread Checking — Requirement: Intel(R) Inspector installation
Feature: Trace Analyzing and Collecting — Requirement: Intel(R) Trace Analyzer and Collector installation. Compiler options related to this feature may require a set-up script. For further information, see the product documentation.

👑 OPTIONS 👑

This section contains descriptions of available compiler options. The options are listed in alphabetical order, iykyk.

Your user documentation contains other option information, such as lists of deprecated and removed options.

-ansi (LX only)* — enables language compatibility with the gcc option ansi.
- Arguments: None
- Default: OFF — GNU C++ is more strongly supported than ANSI C.
- Description: This option enables language compatibility with the gcc option -ansi and provides the same level of ANSI standard conformance as that option. If you want strict ANSI conformance, use the -strict-ansi option. slay.
- Alternate Options: None
-axcode (LX only)* — tells the compiler to generate multiple, feature-specific auto-dispatch code paths for Intel(R) processors if there is a performance benefit. 🔥
- Arguments: code — Indicates to the compiler a feature set that it may target, including which instruction sets it may generate. The following descriptions refer to Intel(R) Streaming SIMD Extensions (Intel(R) SSE) and Supplemental Streaming SIMD Extensions (SSSE). Possible values are:
  - ALDERLAKE, AMBERLAKE, ARROWLAKE, ARROWLAKE-S, BROADWELL, CANNONLAKE, CASCADELAKE, CLEARWATERFOREST, COFFEELAKE, COOPERLAKE, DIAMONDRAPIDS, EMERALDRAPIDS, GOLDMONT, GOLDMONT-PLUS, GRANDRIDGE, GRANITERAPIDS, GRANITERAPIDS-D, HASWELL, ICELAKE-CLIENT (or ICELAKE), ICELAKE-SERVER, IVYBRIDGE, KABYLAKE, LUNARLAKE, PANTHERLAKE, ROCKETLAKE, SANDYBRIDGE, SAPPHIRERAPIDS, SIERRAFOREST, SILVERMONT, SKYLAKE, SKYLAKE-AVX512, TIGERLAKE, TREMONT, WHISKEYLAKE — may generate instructions for processors that support the specified Intel(R) processor or microarchitecture code name.

🚨 Keyword ICELAKE is deprecated and may be removed in a future release.

COMMON-AVX512 — may generate Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512) Foundation instructions, Intel(R) AVX-512 Conflict Detection Instructions (CDI), as well as the instructions enabled with CORE-AVX2.
CORE-AVX512 — may generate Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512) Foundation instructions, Intel(R) AVX-512 Conflict Detection Instructions (CDI), Intel(R) AVX-512 Doubleword and Quadword Instructions (DQI), Intel(R) AVX-512 Byte and Word Instructions (BWI) and Intel(R) AVX-512 Vector Length extensions, as well as the instructions enabled with CORE-AVX2.
CORE-AVX2 — may generate Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2), Intel(R) AVX, SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions for Intel(R) processors.
CORE-AVX-I — may generate Float-16 conversion instructions and the RDRND instruction, Intel(R) Advanced Vector Extensions (Intel(R) AVX), Intel(R) SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions for Intel(R) processors.
AVX — may generate Intel(R) Advanced Vector Extensions (Intel(R) AVX), Intel(R) SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions for Intel(R) processors.
SSE4.2 — may generate Intel(R) SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions for Intel processors.
SSE4.1 — may generate Intel(R) SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions for Intel(R) processors.
ATOM_SSE4.2 — may generate MOVBE instructions for Intel(R) processors, depending on the setting of option -minstruction (Linux) or /Qinstruction (Windows). May also generate Intel(R) SSE4.2, SSE3, SSE2, and SSE instructions for Intel processors. Optimizes for Intel Atom(R) processors that support Intel(R) SSE4.2 and MOVBE instructions.

ATOM_SSSE3 — May generate MOVBE instructions for Intel® processors, depending on the setting of option -minstruction (Linux) or /Qinstruction (Windows). May also generate SSSE3, Intel® SSE3, SSE2, and SSE instructions for Intel processors. Optimizes for Intel Atom® processors that support Intel® SSE3 and MOVBE instructions.
SSSE3 — May generate SSSE3 instructions and Intel® SSE3, SSE2, and SSE instructions for Intel® processors.
SSE3 — May generate Intel® SSE3, SSE2, and SSE instructions for Intel® processors.

You can specify more than one code value, bestie 💖 — when you do, each value must be separated with a comma. Peep the Examples section below for the receipts.

🌸 Default

OFF — No auto-dispatch code is generated. Feature-specific code is generated and is controlled by the setting of the following compiler options:
- Linux*: -march and -x

🦋 Description

Okay so this option tells the compiler to generate multiple, feature-specific auto-dispatch code paths for Intel® processors if there is a performance benefit. It also generates a baseline code path. The Intel feature-specific auto-dispatch path is usually more optimized than the baseline path. Other options, such as O3, control how much optimization is performed on the baseline path.

The baseline code path is determined by the architecture specified by options -march or -x (Linux*) or options /arch or /Qx (Windows*). While there are defaults for the [Q]x option that depend on the operating system being used, you can specify an architecture and optimization level for the baseline code that is higher or lower than the default. The specified architecture becomes the effective minimum architecture for the baseline code path.

If you specify both the [Q]ax and [Q]x options, the baseline code will only execute on Intel® processors compatible with the setting specified for the [Q]x.

If you specify both the -ax and -march options (Linux) or the /Qax and /arch options (Windows), the baseline code will execute on non-Intel® processors compatible with the setting specified for the -march or /arch option.

A Non-Intel® baseline and an Intel® baseline have the same set of optimizations enabled, and the default for both is SSE4.2 for x86-based architectures. No cap ✨

The [Q]ax option tells the compiler to find opportunities to generate separate versions of functions that take advantage of features of the specified instruction features.

If the compiler finds such an opportunity, it first checks whether generating a feature-specific version of a function is likely to result in a performance gain. If this is the case, the compiler generates both a feature-specific version of a function and a baseline version of the function. At runtime, one of the versions is chosen to execute, depending on the Intel® processor in use. In this way, the program can benefit from performance gains on more advanced Intel processors, while still working properly on older processors and non-Intel processors. A non-Intel processor always executes the baseline code path. It's giving ✨backwards compatibility icon✨.

You can use more than one of the feature values by combining them. For example, you can specify -axSSE4.1,SSSE3 (Linux) or /QaxSSE4.1,SSSE3 (Windows).

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

NOTE: When using the icx compiler, if you experience any program failure when using option -ax during this release, please remove the option to see if that solves the problem. If that action solved the problem, please report a bug. 😭 (yes literally just take it out and see, and then tell the maintainers so they can fix it)

💜 Alternate Options

None

🎀 `-Bdir` (L*X only)

Specifies a directory that can be used to find include files, libraries, and executables.

Arguments

dir — Is the directory to be used. If necessary, the compiler adds a directory separator character at the end of dir.

Default

OFF — The compiler looks for files in the directories specified in your PATH environment variable.

Description

This option specifies a directory that can be used to find include files, libraries, and executables.

The compiler uses dir as a prefix.

For include files, the dir is converted to -I/dir/include. This command is added to the front of the includes passed to the preprocessor.

For libraries, the dir is converted to -L/dir. This command is added to the front of the standard -L inclusions before system libraries are added.

For executables, if dir contains the name of a tool, such as ld or as, the compiler will use it instead of those found in the default directories.

The compiler looks for include files in dir /include while library files are looked for in dir.

On Linux* systems, another way to get the behavior of this option is to use the environment variable GCC_EXEC_PREFIX.

Alternate Options

None

🌈 `-C` (L*X only)

Places comments in preprocessed source output.

Arguments

None

Default

OFF — No comments are placed in preprocessed source output.

Description

This option places (or preserves) comments in preprocessed source output.

Comments following preprocessing directives, however, are not preserved. Sad but true 🙈

Alternate Options

None

🍓 `-c` (L*X only)

Causes the compiler to generate an object only and not link.

Arguments

None

Default

OFF — Linking is performed.

Description

This option causes the compiler to generate an object only and not link. Compilation stops after the object file is generated.

The compiler generates an object file for each C or C++ source file or preprocessed source file. It also takes an assembler file and invokes the assembler to generate an object file.

🧚 `-Dname[=value]` (L*X only)

Defines a macro name that can be associated with an optional value.

Arguments

name — Is the name of the macro.
value — Is an optional integer or an optional character string delimited by double quotes; for example, Dname=string.

Default

OFF — Only default symbols or macros are defined.

Description

Defines a macro name that can be associated with an optional value. This option is equivalent to a #define preprocessor directive.

If a value is not specified, name is defined as "1". That's it, that's the whole trick 💅

Alternate Options

None

🦋 `-dD` (L*X only)

Same as option -dM, but outputs #define directives in preprocessed source.

Arguments

None

Default

OFF — The compiler does not output #define directives.

Description

Same as -dM, but outputs #define directives in preprocessed source. To use this option, you must also specify the E option. 👑 (don't forget it, bestie, it will not work alone)

Alternate Options

None

⭐ `-debug[=keyword]` (L*X only)

Enables or disables generation of debugging information.

Arguments

keyword — Is the type of debugging information to be generated. Possible values are:
- none — Disables generation of debugging information.
- full or all — Generates complete debugging information. It is the same as specifying -debug with no keyword.
- minimal — Generates line number information for debugging.
- [no]emit-column — Determines whether the compiler generates column number information for debugging.
- extended — Generates complete debugging information and also sets keyword values semantic-stepping and variable-locations.
- [no]parallel — Determines whether the compiler generates parallel debug code instrumentations useful for thread data sharing and reentrant call detection. This keyword can only be specified on Linux systems.

For information on the non-default settings for these keywords, see the Description section.

Default

-debug none — No debugging information is generated.

Description

This option enables or disables generation of debugging information.

Okay so, debug vibes: by default, enabling debugging will disable optimization. To enable both debugging and optimization, use the -debug option together with one of the optimization level options (-O3, -O2 or -O3 — yes bestie, that’s literally how it’s written, don’t come for me 😭).

Keywords inline-debug-info, variable-locations, and extended can be used in combination with each other. If conflicting keywords are used in combination, the last one specified on the command line has precedence — highkey “last one wins” energy. ✨

-debug none — disables generation of debugging information. 🚫
-debug full or -debug all — generates complete debugging information. It is the same as specifying -debug with no keyword. 💖
-debug minimal — generates line number information for debugging.
-debug emit-column — generates column number information for debugging.
-debug extended — sets keyword variable-locations. It also tells the compiler to include column numbers in the line information. The page also says: “Generates complete debugging information. This is a more powerful setting than -debug full or -debug all.” 🎀
-debug parallel — generates parallel debug code instrumentations needed for the thread data sharing and reentrant call detection. For shared data and reentrancy detection, option -qopenmp must be set. 🫶

On Linux* systems, debuggers read debug information from executable images. As a result, information is written to object files and then added to the executable by the linker. 🐧

Alternate Options: For -debug full, -debug all, or -debug Linux: -g

-device-math-lib=library (L*X only) — enables or disables certain device libraries. 💅
- Arguments: library — possible values are:
  - fp32 — links the fp32 device math library.
  - fp64 — links the fp64 device math library.
  - To link more than one library, include a comma between the library names. For example, if you want to link both the fp32 and fp64 device libraries, specify: fp32, fp64
- Default: fp32, fp64 — both the fp32 and fp64 device libraries are linked.
- Description: This option enables or disables certain device libraries. This is a deprecated option that may be removed in a future release. There is no replacement option.
- Alternate Options: None.
-no-device-math-lib=library (L*X only) — enables or disables certain device libraries. 💅
- Arguments: library — possible values are:
  - fp32 — links the fp32 device math library.
  - fp64 — links the fp64 device math library.
  - To link more than one library, include a comma between the library names. For example, if you want to link both the fp32 and fp64 device libraries, specify: fp32, fp64
- Default: fp32, fp64 — both the fp32 and fp64 device libraries are linked.
- Description: This option enables or disables certain device libraries. This is a deprecated option that may be removed in a future release. There is no replacement option.
- Alternate Options: None.
-dM (L*X only) — tells the compiler to output macro definitions in effect after preprocessing. 🧠
- Arguments: None.
- Default: OFF — the compiler does not output macro definitions after preprocessing.
- Description: This option tells the compiler to output macro definitions in effect after preprocessing. To use this option, you must also specify option E.
- Alternate Options: None.
-dryrun (L*X only) — specifies that driver tool commands should be shown but not executed. 👀
- Arguments: None.
- Default: OFF — no tool commands are shown, but they are executed.
- Description: This option specifies that driver tool commands should be shown but not executed.
- Alternate Options: None.
-dumpmachine (L*X only) — displays the target machine and operating system configuration. 🖥️
- Arguments: None.
- Default: OFF — the compiler does not display target machine or operating system information.
- Description: This option displays the target machine and operating system configuration. No compilation is performed.
- Alternate Options: None.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

-dumpversion (L*X only) — displays the version number of the compiler. 🏷️
- Arguments: None.
- Default: OFF — the compiler does not display the compiler version number.
- Description: This option displays the version number of the compiler. It does not compile your source files.
- Alternate Options: None.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

-E (L*X only) — causes the preprocessor to send output to stdout. 📤
- Arguments: None.
- Default: OFF — preprocessed source files are output to the compiler.
- Description: This option causes the preprocessor to send output to stdout. Compilation stops when the files have been preprocessed. When you specify this option, the compiler’s preprocessor expands your source module and writes the result to stdout. The preprocessed source contains #line directives, which the compiler uses to determine the source file and line number.
- Alternate Options: None.
-EP (L*X only) — causes the preprocessor to send output to stdout, omitting #line directives. 📤
- Arguments: None.
- Default: OFF — preprocessed source files are output to the compiler.
- Description: This option causes the preprocessor to send output to stdout, omitting #line directives. If you also specify option P, the preprocessor will write the results (without #line directives) to a file instead of stdout.
- Alternate Options: None.
-fasm-blocks (L*X only) — enables the use of blocks and entire functions of assembly code within a C or C++ file. 🛠️
- Arguments: None.
- Default: OFF — the compiler allows a GNU*-style inline assembly format.
- Description: This option enables the use of blocks and entire functions of assembly code within a C or C++ file. It allows a Microsoft* MASM-style inline assembly block not a GNU*-style inline assembly block.
- Alternate Options: -use-msasm

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

-fast (L*X only) — maximizes speed across the entire program. 🚀
- Arguments: None.
- Default: OFF — the optimizations that maximize speed are not enabled.
- Description: This option maximizes speed across the entire program.
  - Linux: It sets the following options: -ipo, -O3, -static, -fp-model fast
  - Windows: It sets the following options: /O3, /Qipo, /fp:fast
- Alternate Options: None.

NOTE: Option fast sets some aggressive optimizations that may not be appropriate for all applications. The resulting executable may not run on processor types different from the one on which you compile. You should make sure that you understand the individual optimization options that are enabled by option fast. NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Product and Performance Information

= = = = = = = = = = Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex. Notice revision #20201201 = = = = = = = = = =

-fasynchronous-unwind-tables (L*X only) — determines whether unwind information is precise at an instruction boundary or at a call boundary. 🧵
- Arguments: None.
- Default: -fasynchronous-unwind-tables — the unwind table generated is precise at an instruction boundary, enabling accurate unwinding at any instruction.
- Description: This option determines whether unwind information is precise at an instruction boundary or at a call boundary. The compiler generates an unwind table in DWARF2 or DWARF3 format, depending on which format is supported on your system. If -fno-asynchronous-unwind-tables is specified, the unwind table is precise at call boundaries only. In this case, the compiler will avoid creating unwind tables for routines such as the following:
  - A C++ routine that does not declare objects with destructors and does not contain calls to routines that might throw an exception.
  - A C/C++ or Fortran routine compiled without -fexceptions and without traceback information.
  - A C/C++ or Fortran routine compiled with -fexceptions that does not contain calls to routines that might throw an exception.
- Alternate Options: None.
-fno-asynchronous-unwind-tables (L*X only) — determines whether unwind information is precise at an instruction boundary or at a call boundary. 🧵
- Arguments: None.
- Default: -fasynchronous-unwind-tables — the unwind table generated is precise at an instruction boundary, enabling accurate unwinding at any instruction.
- Description: This option determines whether unwind information is precise at an instruction boundary or at a call boundary. The compiler generates an unwind table in DWARF2 or DWARF3 format, depending on which format is supported on your system. If -fno-asynchronous-unwind-tables is specified, the unwind table is precise at call boundaries only. In this case, the compiler will avoid creating unwind tables for routines such as the following:
  - A C++ routine that does not declare objects with destructors and does not contain calls to routines that might throw an exception.
  - A C/C++ or Fortran routine compiled without -fexceptions and without traceback information.
  - A C/C++ or Fortran routine compiled with -fexceptions that does not contain calls to routines that might throw an exception.
- Alternate Options: None.
-fbuiltin[-name] (L*X only) — enables inline expansion of intrinsic functions. 🧚
- Arguments: name — is a list of one or more intrinsic functions. If there is more than one intrinsic function, they must be separated by commas.
- Default:
-fno-builtin[-name] (L*X only) — disables inline expansion of intrinsic functions. 🧚
- Arguments: name — is a list of one or more intrinsic functions. If there is more than one intrinsic function, they must be separated by commas.
- Default:
ON — inline expansion of intrinsic functions is enabled. ✨

Description:

This one flips inline expansion of one or more intrinsic functions on or off. Simple as that. 💅

If you say -fno-builtin-name or /Qno-builtin-name, inline expansion gets disabled for the named functions only. And if you don't name anything at all, -fno-builtin or /Oi- disables inline expansion for all the intrinsic functions. boom, gone. 💀

Wanna see the list of built-in functions that -fbuiltin messes with? Search for "built-in functions" in the appropriate gcc* documentation. 📖

And for the list affected by /Oi, search for "/Oi" in the appropriate Microsoft* Visual C/C++* documentation. 🫶

Alternate Options:

None 🎀

`-fcf-protection[=keyword]` (`L*X` only)

Enables Intel(R) Control-Flow Enforcement Technology (Intel(R) CET) protection, which defends your program from certain attacks that exploit vulnerabilities. This option offers preliminary support for Intel(R) CET. 🛡️✨

Arguments:

keyword — specifies the level of protection the compiler should perform. Possible values are:
- return — enables shadow stack protection.
- branch — enables endbranch (EB) generation.
- full — enables shadow stack protection and endbranch (EB) generation. This is the same as specifying this compiler option with no keyword. 👑
- none — disables Intel(R) CET protection.

Default:

-fcf-protection=none or /Qcf-protection:none — no Control-flow Enforcement protection is performed. 😴

Description:

This option enables Intel(R) CET protection, which defends your program from certain attacks that exploit vulnerabilities. fr fr it's a whole bodyguard for your binary. 💪

Intel(R) CET protections are enforced on processors that support Intel(R) CET. They're ignored on processors that don't support Intel(R) CET, so they're totes safe to use in programs that might run on a variety of processors. 🌈

Shadow stack protection helps protect your program from return-oriented programming (ROP). And what is ROP, you ask? It's a technique to exploit computer security defenses such as non-executable memory and code signing by gaining control of the call stack to modify program control flow and then execute certain machine instruction sequences. literally the villain arc of an attacker. 😭

Endbranch (EB) generation helps protect your program from call/jump-oriented programming (COP/JOP). Jump-oriented programming (JOP) is a variant of ROP that uses indirect jumps and calls to emulate return instructions. Call-oriented programming (COP) is a variant of ROP that employs indirect calls. 💅

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 🫶

Alternate Options:

Linux: -qcf-protection
Windows: None

`-fcommon` (`L*X` only)

`-fno-common` (`L*X` only)

Determines whether the compiler treats common symbols as global definitions. 🧐

Arguments:

None

Default:

-fcommon — the compiler does not treat common symbols as global definitions.

Description:

This option determines whether the compiler treats common symbols as global definitions and to allocate memory for each symbol at compile time. ✨

Option -fno-common tells the compiler to treat common symbols as global definitions. When using this option, you can only have a common variable declared in one module — otherwise a link time error will occur for multiple defined symbols. no cap, one module only or the linker gets mad. 😤

Normally, a file-scope declaration with no initializer and without the extern or static keyword — like int i; — is represented as a common symbol. Such a symbol is treated as an external reference. However, if no other compilation unit has a global definition for the name, the linker allocates memory for it. 🎀

Alternate Options:

None

`-fdata-sections` (`L*X` only)

Places each data item in its own COMDAT section. 🗂️✨

Arguments:

None

Default:

OFF — the compiler does not separate functions into COMDATs.

Description:

This option places each data item in its own COMDAT section. every single one gets its own little home 💖

When using this compiler option, you can add the linker option -Wl,--gc-sections (LInux) or /link /OPT:REF (Windows), which will remove all unused code. declutter slay 🧹

NOTE: When you put each data item in its own section, it enables the linker to reorder the sections for other possible optimization. 👑

Alternate Options:

None

`-fexceptions` (`L*X` only)

`-fno-exceptions` (`L*X` only)

Enables exception handling table generation. 🎢

Arguments:

None

Default:

-fexceptions — exception handling table generation is enabled. Default for C++.
-fno-exceptions — exception handling table generation is disabled. Default for C.

Description:

This option enables exception handling table generation. ✨

The -fno-exceptions option disables exception handling table generation, resulting in smaller code. But heads up — when this option is used, any use of exception handling constructs (such as try blocks and throw statements) will produce an error. 💀 Exception specifications are parsed but ignored. It also undefines the preprocessor symbol __EXCEPTIONS. 🙈

Alternate Options:

None

`-ffp-accuracy=value` (`L*X` only)

Lets you specify the required accuracy (precision) for floating-point operations and library calls. 🎯💅

Arguments:

value — is the accuracy that the compiler should use. Possible values are:
- high — sets a maximum error of 1 ulp.
- medium — sets a maximum error of 4 ulp.
- low — sets a maximum error to 11-bits of accuracy for single-precision functions (~8192 ulp) and 26-bits of accuracy for double-precision functions.
- sycl — determined by the OpenCL specification for math function accuracy, see Relative Error as ULPs. 🦋
- cuda — determined by the CUDA standard, see Mathematical Functions. 🌸

Default:

OFF — if option ffp-accuracy or Qfp-accuracy is not specified:
- On the host, the accuracy for floating-point operations and library calls is determined by the setting of option -fp-model (Linux*) and option /fp (Windows*).
- On offload devices, the default accuracy is device-dependent. 🎀

Description:

This option lets you specify the required accuracy (precision) for floating-point operations and library calls. ✨

The accuracy requirements are applied to host code and, if used, to OpenMP and SYCL device code. The option is only supported for CPU Ahead of Time (AOT) compilation with SYCL and OpenMP. iykyk 🧚

CAUTION: This option is not compatible with the fimf-* and Qimf-* options. If this option is used with any of those options, an error will be reported. not me mixing those, do NOT do it 😭

Alternate Options:

None

`-ffp-contract=keyword` (`L*X` only)

Controls when the compiler is permitted to form fused floating-point operations, such as fused multiply-add (FMA). Fused operations are allowed to produce more precise results than performing the individual operations separately. 🔥🧮

Arguments:

keyword — possible values are:
- fast — fuses floating-point operations across statements.
- on — fuses floating-point operations within the same statement.
- off — does not fuse floating-point operations. 💀

Default:

-ffp-contract=fast — fuses floating-point operations across statements. However, if option -fp-model=strict is specified, the default is -ffp-contract=off. 🎀

Description:

This option controls when the compiler is permitted to form fused floating-point operations, such as fused multiply-add (FMA). Fused operations are allowed to produce more precise results than performing the individual operations separately. it's giving "better math, compiler's choice" 💅✨

Alternate Options:

None

`-ffreestanding` (`L*X` only)

Ensures that compilation takes place in a freestanding environment. 🏕️✨

Arguments:

None

Default:

OFF — standard libraries are used during compilation.

Description:

This option ensures that compilation takes place in a freestanding environment. The compiler assumes that the standard library may not exist and program startup may not necessarily be at main. This environment meets the definition of a freestanding environment as described in the C and C++ standard. so brave, so independent, main character energy tbh 👑🦋

An example of an app that requires an environment like that? An OS kernel, no cap. 🧠

NOTE: When you specify this option, the compiler will not assume the presence of compiler-specific libraries. It will only generate calls that appear in the source code.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

`-ffunction-sections` (L*X only) 🎀

Places each function in its own COMDAT section. It’s giving “every function gets its own little room,” and honestly? Iconic. ✨

Arguments: None

Default: OFF — the compiler does not separate functions into COMDATs.

Description: This option places each function in its own COMDAT section.

When you use this compiler option, you can add the linker option -Wl,--gc-sections (Linux) or /link /OPT:REF (Windows), which will remove all unused code.

NOTE: When you put each function in its own section, it enables the linker to reorder the sections for other possible optimization.

Alternate Options: None

`-fgnu89-inline` (L*X only) 🌸

Tells the compiler to use C89 semantics for inline functions when in C99 mode. Time-travel behavior, but make it compiler flag. 🕰️

Arguments: None

Default: OFF

Description: This option tells the compiler to use C89 semantics for inline functions when in C99 mode.

Alternate Options: None

`-fimf-absolute-error=value[:funclist]` (L*X only) 💖

Defines the maximum allowable absolute error for math library function results.

Arguments:

value — is a positive, floating-point number. Errors in math library function results may exceed the maximum relative error (max-error) setting if the absolute-error is less than or equal to value.

The format for the number is [digits] [.digits] [ { e | E }[sign]digits]

funclist — is an optional list of one or more math library functions to which the attribute should be applied. If you specify more than one function, they must be separated with commas.

Precision-specific variants like sin and sinf are considered different functions, so you would need to use -fimf-absolute-error=0.00001:sin,sinf (or /Qimf-absolute-error:0.00001:sin,sinf) to specify the maximum allowable absolute error for both the single-precision and double-precision sine functions.

You also can specify the symbol /f to denote single-precision divides, symbol / to denote double-precision divides, symbol /l to denote extended-precision divides, and symbol /q to denote quad-precision divides. For example you can specify -fimf-absolute-error=0.00001:/ or /Qimf-absolute-error: 0.00001:/.

Default: Zero ("0") — an absolute-error setting of 0 means that the function is bound by the relative error setting. This is the default behavior.

Description: This option defines the maximum allowable absolute error for math library function results.

This option can improve runtime performance, but it may decrease the accuracy of results.

This option only affects functions that have zero as a possible return value, such as log, sin, asin, etc.

The relative error requirements for a particular function are determined by options that set the maximum relative error (max-error) and precision. The return value from a function must have a relative error less than the max-error value, or an absolute error less than the absolute-error value.

If you need to define the accuracy for a math function of a certain precision, specify the function name of the precision that you need. For example, if you want double precision, you can specify :sin; if you want single precision, you can specify :sinf, as in -fimf-absolute-error=0.00001:sin or /Qimf-absolute-error:0.00001:sin, or -fimf-absolute-error=0.00001:sqrtf or /Qimf-absolute-error:0.00001:sqrtf.

If you do not specify any function names, then the setting applies to all functions (and to all precisions). However, as soon as you specify an individual function name, the setting applies only to the function of corresponding precision. So, for example, sinf applies only to the single-precision sine function, sin applies only to the double-precision sine function, sinl applies only to the extended-precision sine function, etc.

NOTE: Many routines in libraries LIBM (Math Library) and SVML (Short Vector Math Library) are more highly optimized for Intel(R) microprocessors than for non-Intel microprocessors.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options: None

`-fimf-accuracy-bits=bits[:funclist]` (L*X only) 🦋

Defines the relative error for math library function results, including division and square root. Precision math, but make it a flag. 🔥

Arguments:

bits — is a positive, floating-point number indicating the number of correct bits the compiler should use.

The format for the number is [digits] [.digits] [ { e | E }[sign]digits].

funclist — is an optional list of one or more math library functions to which the attribute should be applied. If you specify more than one function, they must be separated with commas.

Precision-specific variants like sin and sinf are considered different functions, so you would need to use -fimf-accuracy-bits=23:sin,sinf (or /Qimf-accuracy-bits:23:sin,sinf) to specify the relative error for both the single-precision and double-precision sine functions.

You also can specify the symbol /f to denote single-precision divides, symbol / to denote double-precision divides, symbol /l to denote extended-precision divides, and symbol /q to denote quad-precision divides. For example you can specify -fimf-accuracy-bits=10.0:/f or /Qimf-accuracy-bits:10.0:/f.

Default: -fimf-precision=medium or /Qimf-precision:medium — the compiler uses medium precision when calling math library functions. Note that other options can affect precision; see below for details.

Description: This option defines the relative error, measured by the number of correct bits, for math library function results.

The following formula is used to convert bits into ulps: ulps = 2p-1-bits, where p is the number of the target format mantissa bits (24, 53, and 64 for single, double, and long double, respectively).

This option can affect runtime performance and the accuracy of results.

Linux

-fimf-accuracy-bits=23:sinf,cosf,logf
-fimf-accuracy-bits=52:sqrt,/,trunc
-fimf-accuracy-bits=10:powf

Windows

/Qimf-accuracy-bits:23:sinf,cosf,logf
/Qimf-accuracy-bits:52:sqrt,/,trunc
/Qimf-accuracy-bits:10:powf

There are three options you can use to express the maximum relative error. They are as follows:

Linux

-fimf-precision
-fimf-max-error
-fimf-accuracy-bits

Windows

/Qimf-precision
/Qimf-max-error
/Qimf-accuracy-bits

If more than one of these options are specified, the default value for the maximum relative error is determined by the last one specified on the command line.

If none of the above options are specified, the default values for the maximum relative error are determined by the setting of the following options:

-fp-model (Linux) or /fp (Windows)

NOTE: Many routines in libraries LIBM (Math Library) and SVML (Short Vector Math Library) are more highly optimized for Intel(R) microprocessors than for non-Intel microprocessors.

💖 NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. Bestie, write that down.

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at
                  www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

🦋 `-fimf-arch-consistency=value[:funclist]` (L*X only)

Okay so picture this: you want your math library functions to give you the same answers no matter which microarchitectural implementation of the same architecture you're running on. That's literally what this does. Consistency queen. ✨

Arguments:

value — one of the logical values "true" or "false". That's it, that's the whole vibe.
funclist — an optional list of one or more math library functions you want the attribute applied to. If you list more than one function, separate them with commas. No spaces, no drama.

🎀 Heads up: precision-specific variants like sin and sinf are considered different functions. So you'd need -fimf-arch-consistency=true:sin,sinf (or /Qimf-arch-consistency:true:sin,sinf) to get consistent results for both the single-precision and double-precision sine functions. They're siblings, not twins, iykyk.

You also can specify the symbol /f to denote single-precision divides, symbol / to denote double-precision divides, symbol /l to denote extended-precision divides, and symbol /q to denote quad-precision divides. For example you can specify -fimf-arch-consistency=true:/ or /Qimf-arch-consistency:true:/ — cute, right?

Default:

false — implementations of some math library functions may produce slightly different results on implementations of the same architecture. Yeah. They're a little unpredictable like that. 🙈

Description:

This option ensures that the math library functions produce consistent results across different microarchitectural implementations of the same architecture (for example, across different microarchitectural implementations of Intel(R) 64 architecture). Consistency is only guaranteed for a single binary. Consistency is not guaranteed across different architectures. Periodt — don't push it. 💅

If you need to define the accuracy for a math function of a certain precision, specify the function name of the precision that you need. For example:

Linux

If you want double precision, you can specify :sin; if you want single
precision, you can specify :sinf, as in
-fimf-arch-consistency=true:sin or
-fimf-arch-consistency=false:sqrtf.

Windows

If you want double precision, you can specify :sin; if you want single
precision, you can specify :sinf, as in
/Qimf-arch-consistency:true:sin or
/Qimf-arch-consistency:false:sqrtf.

If you do not specify any function names, then the setting applies to all functions (and to all precisions). But the second you specify an individual function name, the setting applies only to the function of corresponding precision. So, for example, sinf applies only to the single-precision sine function, sin applies only to the double-precision sine function, sinl applies only to the extended-precision sine function, etc. One name, one function. No sharing. 🧚

The -fimf-arch-consistency (Linux*) and /Qimf-arch-consistency (Windows*) option may decrease runtime performance, but the option will provide bit-wise consistent results on all Intel(R) processors and compatible, non-Intel processors, regardless of micro-architecture. This option may not provide bit-wise consistent results between different architectures. Slay for bit-wise consistency on the same arch, but keep your expectations realistic across arches, fr fr.

⭐ NOTE: Many routines in libraries LIBM (Math Library) and SVML (Short Vector Math Library) are more highly optimized for Intel(R) microprocessors than for non-Intel microprocessors.

💜 NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at
                  www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

🌈 `-fimf-domain-exclusion=classlist[:funclist]` (L*X only)

This one is basically you telling the compiler: "hey, these input argument classes? I promise my program doesn't need correct results for those." And the compiler goes "say less" and serves you faster code. 🔥

It indicates the input arguments domain on which math functions must provide correct results.

Arguments:

classlist — is one of the following:
- One or more of the following floating-point value classes you can exclude from the function domain without affecting the correctness of your program. The supported class names are:
  - extremes — This class is for values which do not lie within the usual domain of arguments for a given function.
  - nans — This means "x=Nan".
  - infinities — This means "x=infinities".
  - denormals — This means "x=denormal".
  - zeros — This means "x=0".

Each classlist element corresponds to a power of two. The exclusion attribute is the logical or of the associated powers of two (that is, a bitmask). The following shows the current mapping from classlist mnemonics to numerical values:

extremes — 1
nans — 2
infinities — 4
denormals — 8
zeros — 16
none — 0
all — 31
common — 15
other combinations — bitwise OR of the used values

You must specify the integer value that corresponds to the class that you want to exclude.

💀 Note that on excluded values, unexpected results may occur. That's the trade, bestie — you're literally telling the compiler you don't care what happens there.

One of the following short-hand tokens:
- none — This means that none of the supported classes are excluded from the domain. To indicate this token, specify 0, as in -fimf-domain-exclusion=0 (or /Qimf-domain-exclusion:0).
- all — This means that all of the supported classes are excluded from the domain. To indicate this token, specify 31, as in -fimf-domain-exclusion=31 (or /Qimf-domain-exclusion:31).
- common — This is the same as specifying extremes,nans,infinities,denormals. To indicate this token, specify 15 (1 + 2+ 4 + 8), as in -fimf-domain-exclusion=15 (or /Qimf-domain-exclusion:15).

funclist — Is an optional list of one or more math library functions to which the attribute should be applied. If you specify more than one function, they must be separated with commas.

Precision-specific variants like sin and sinf are considered different functions, so you would need to use -fimf-domain-exclusion=4:sin,sinf (or /Qimf-domain-exclusion:4:sin,sinf) to specify infinities for both the single-precision and double-precision sine functions. Again: different functions, different entries. 🫶

-fimf-domain-exclusion=4 or
/Qimf-domain-exclusion:4

-fimf-domain-exclusion=5:/,powf or
/Qimf-domain-exclusion:5:/,powf

-fimf-domain-exclusion=23:log,logf,/,sin,cosf
or
/Qimf-domain-exclusion:23:log,logf,/,sin,cosf

If you don't specify argument funclist, the domain restrictions apply to all math library functions.

Default:

Zero ("0") — The compiler uses default heuristics when calling math library functions. It's doing its own thing, no notes. 💅

Description:

This option indicates the input arguments domain on which math functions must provide correct results. It specifies that your program will function correctly if the functions specified in funclist do not produce standard conforming results on the number classes.

This option can affect runtime performance and the accuracy of results. As more classes are excluded, faster code sequences can be used. Iconic trade-off behavior honestly. ⚡

So, bestie, if you need to lock in the accuracy for a math function of a certain precision, you just name the function at the precision you want. Want double precision? Drop a :sin. Want single precision? That's :sinf, like in -fimf-domain-exclusion=denormals:sin or /Qimf-domain-exclusion:denormals:sin, or -fimf-domain-exclusion=extremes:sqrtf or /Qimf-domain-exclusion:extremes:sqrtf. Precision-targeted, periodt. 🎯

Now the vibe check: if you don't name any functions at all, the setting applies to everything — all functions, all precisions. But the literal second you name an individual function, the setting applies only to that function at that precision. So sinf is only the single-precision sine function, sin is only the double-precision sine function, sinl is only the extended-precision sine function, etc. It's giving very-specific-invite-list energy. 💅

NOTE: Many routines in libraries LIBM (Math Library) and SVML (Short Vector Math Library) are more highly optimized for Intel(R) microprocessors than for non-Intel microprocessors.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at
                  www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

`-fimf-max-error=ulps[:funclist]` (L*X only)

Defines the maximum allowable relative error for math library function results, including division and square root. Lowkey the whole point of this one. 🎀

Arguments:

ulps — is a positive, floating-point number indicating the maximum allowable relative error the compiler should use. The format for the number is [digits] [.digits] [ { e | E }[sign]digits].
funclist — is an optional list of one or more math library functions to which the attribute should be applied. If you specify more than one function, they must be separated with commas.

Precision-specific variants like sin and sinf are considered different functions, so you would need to use -fimf-max-error=4.0:sin,sinf (or /Qimf-max-error=4.0:sin,sinf) to specify the maximum allowable relative error for both the single-precision and double-precision sine functions.

Default:

-fimf-precision=medium or /Qimf-precision:medium — The compiler uses medium precision when calling math library functions. Note that other options can affect precision; see below for details. (iykyk 👀)

Description:

This option defines the maximum allowable relative error, measured in ulps, for math library function results.

This option can affect runtime performance and the accuracy of results. Balance is everything, bestie. ⚖️

If you need to define the accuracy for a math function of a certain precision, specify the function name of the precision that you need. For example, if you want double precision, you can specify :sin; if you want single precision, you can specify :sinf, as in -fimf-max-error=4.0:sin or /Qimf-max-error:4.0:sin, or -fimf-max-error=4.0:sqrtf or /Qimf-max-error:4.0:sqrtf.

There are three options you can use to express the maximum relative error. They are as follows:

Linux

-fimf-precision
-fimf-max-error
-fimf-accuracy-bits

Windows

/Qimf-precision
/Qimf-max-error
/Qimf-accuracy-bits

If more than one of these options are specified, the default value for the maximum relative error is determined by the last one specified on the command line. Last one in the group chat wins, fr fr. 📱

If none of the above options are specified, the default values for the maximum relative error are determined by the setting of the following options:

-fp-model (Linux) or /fp (Windows)

NOTE: Many routines in libraries LIBM (Math Library) and SVML (Short Vector Math Library) are more highly optimized for Intel(R) microprocessors than for non-Intel microprocessors.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at
                  www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

`-fimf-precision[=value[:funclist]]` (L*X only)

Lets you specify a level of accuracy (precision) that the compiler should use when determining which math library functions to use. It's giving "choose your fighter" but for float accuracy. ✨

Arguments:

value — is one of the following values denoting the desired accuracy:
- high — this is equivalent to max-error = 1.0.
- medium — this is equivalent to max-error = 4; this is the default setting if the option is specified and value is omitted.
- low — this is equivalent to accuracy-bits = 11 for single-precision functions; accuracy-bits = 26 for double-precision functions.

Linux

In the above explanations, max-error means option -fimf-max-error; accuracy-bits means option -fimf-accuracy-bits.

Windows

In the above explanations, max-error means option /Qimf-max-error (Windows*); accuracy-bits means option /Qimf-accuracy-bits.

funclist — is an optional list of one or more math library functions to which the attribute should be applied.

If you specify more than one function, they must be separated with commas.

Precision-specific variants like sin and sinf are considered different functions, so you would need to use -fimf-precision=high:sin,sinf (or /Qimf-precision:high:sin,sinf) to specify high precision for both the single-precision and double-precision sine functions.

You also can specify the symbol /f to denote single-precision divides, symbol / to denote double-precision divides, symbol /l to denote extended-precision divides, and symbol /q to denote quad-precision divides. For example you can specify -fimf-precision=low:/ or /Qimf-precision:low:/ and -fimf-precision=low:/f or /Qimf-precision:low:/f. 🌸

Default:

medium — The compiler uses medium precision when calling math library functions. Note that other options can affect precision; see below for details.

Description:

This option lets you specify a level of accuracy (precision) that the compiler should use when determining which math library functions to use.

This option can be used to improve runtime performance if reduced accuracy is sufficient for the application, or it can be used to increase the accuracy of math library functions selected by the compiler.

In general, using a lower precision can improve runtime performance and using a higher precision may reduce runtime performance. Trade-offs, bestie — it's always trade-offs. 😭

If you need to define the accuracy for a math function of a certain precision, specify the function name of the precision that you need. For example, if you want double precision, you can specify :sin; if you want single precision, you can specify :sinf, as in -fimf-precision=low:sin or /Qimf-precision:low:sin, or -fimf-precision=high:sqrtf or /Qimf-precision:high:sqrtf. 💖

Okay so if you don't name any functions, the setting applies to all functions (and all precisions) 💖. But the moment you name even one function? It only applies to that specific precision. So like, sinf only affects the single-precision sine, sin only the double-precision sine, sinl only the extended-precision sine, etc. — precision-specific, no cap.

There are three options that let you express the max relative error:

Linux
- -fimf-precision
- -fimf-max-error
- -fimf-accuracy-bits
Windows
- /Qimf-precision
- /Qimf-max-error
- /Qimf-accuracy-bits

If you throw more than one of these at the compiler, the default max relative error is whatever the last one on the command line says. Last one wins, bestie 💅.

If you don't specify any of the above, then the default max relative error is decided by whatever -fp-model (Linux) or /fp (Windows) is set to.

NOTE: Lots of routines in LIBM (Math Library) and SVML (Short Vector Math Library) are way more optimized for Intel(R) microprocessors than for non-Intel ones. Just a heads-up 👀.

NOTE: This option is only for host compilation. If offloading is on, it doesn't touch device-specific compilation. Periodt.

Product and Performance Information

= = = = = = = = = = Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex. Notice revision #20201201 = = = = = = = = = =

Alternate Options: None

-fimf-use-svml=value[:funclist] (L*X only) — Tells the compiler to use the Short Vector Math Library (SVML) instead of the Intel(R) oneAPI DPC++/C++ Compiler Math Library (LIBM) for math library functions. 🦋

Arguments:

funclist — an optional list of one or more math library functions to which the attribute should be applied. If you specify more than one function, they must be separated with commas.

Precision-specific variants like sin and sinf are considered different functions, so you'd need to use -fimf-use-svmlt=true:sin,sinf (or /Qimf-use-svml:true:sin,sinf) to say that both the single-precision and double-precision sine functions should use SVML.

Default:

false — Math library functions are implemented using the Intel(R) oneAPI DPC++/C++ Compiler Math Library, though other compiler options may give the compiler the flexibility to implement math library functions with either LIBM or SVML.

Description:

This option instructs the compiler to implement math library functions using the Short Vector Math Library (SVML).

Linux: When you specify -fimf-use-svml=true, the specific SVML variant chosen is influenced by other compiler options such as -fimf-precision and -fp-model.

Windows: When you specify /Qimf-use-svml:true, the specific SVML variant chosen is influenced by other compiler options such as /Qimf-precision and /fp.

This option has no effect on math library functions that are implemented in LIBM but not in SVML.

In value-safe settings of -fp-model (Linux) or /fp (Windows) such as precise, this option causes a slight decrease in the accuracy of math library functions, because even the high-accuracy SVML functions are slightly less accurate than the corresponding functions in LIBM. Additionally, the SVML functions might not accurately raise floating-point exceptions, do not maintain errno, and are designed to work correctly only in round-to-nearest-even rounding mode.

The benefit of using -fimf-use-svml=true or /Qimf-use-svml:true with value-safe settings of -fp-model (Linux) or /fp (Windows) is that it can significantly improve performance by enabling the compiler to efficiently vectorize loops containing calls to math library functions.

If you need to use SVML for a specific math function of a certain precision, specify the function name of the precision that you need. For example, if you want double precision, you can specify :sin; if you want single precision, you can specify :sqrtf, as in -fimf-use-svml=true:sin or /Qimf-use-svml:true:sin, or -fimf-use-svml =false:sqrtf or /Qimf-use-svml:false:sqrtf.

NOTE: Since SVML functions may raise unexpected floating-point exceptions, be cautious about using features that enable trapping on floating-point exceptions. ⚠️

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Product and Performance Information

= = = = = = = = = = Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex. Notice revision #20201201 = = = = = = = = = =

Alternate Options: None

-finline (L*X only) and -fno-inline (L*X only) — Tells the compiler to inline functions declared with __inline and perform C++ inlining. ✨

Arguments: None

Default:

-fno-inline — The compiler does not inline functions declared with __inline.

Description:

This option tells the compiler to inline functions declared with __inline and perform C++ inlining.

Alternate Options: None

-finline-functions (L*X only) and -fno-inline-functions (L*X only) — Enables function inlining for single file compilation. 🎀

Arguments: None

Default:

-finline-functions — Interprocedural optimizations occur. However, if you specify -O0, the default is OFF.

Description:

This option enables function inlining for single file compilation.

It enables the compiler to perform inline function expansion for calls to functions defined within the current source file.

The compiler applies a heuristic to perform the function expansion.

Alternate Options: None

-fintelfpga (L*X only) — Lets you perform ahead-of-time (AOT) compilation for the Field Programmable Gate Array (FPGA). 🌸

Arguments: None

Default:

OFF — The ahead-of-time (AOT) compilation is not performed.

Description:

This option lets you perform ahead-of-time (AOT) compilation for the FPGA.

It is functionally equivalent to specifying the following, which is compiled with dependency and debug information enabled:

-fsycl-targets=spir64_fpga

Alternate Options: None

-fiopenmp (L*X only) — Enables recognition of OpenMP* features, such as parallel, simd, and offloading directives, and tells the parallelizer to generate multi-threaded code based on OpenMP* directives. This is an alternate name for compiler option -qopenmp (and /Qopenmp). 🔥

Arguments: None

Default:

OFF — No OpenMP* multi-threaded code is generated by the compiler.

Description:

This option enables recognition of OpenMP* features, such as parallel, simd, and offloading directives. This is an alternate option for compiler option [Q or q]openmp.

The -fiopenmp and /Qiopenmp options enable Intel's implementation of OpenMP* in the compiler back end. The compiler front end produces an intermediate representation that preserves the parallelism exposed by OpenMP* directives. The back end uses the exposed parallelism to do more advanced optimizations, such as SIMD vectorization.

NOTE: Option -fiopenmp is not the same as option -fopenmp.

NOTE: To enable offloading to a specified GPU target, you must also specify option -fopenmp-targets (Linux*) or /Qopenmp-targets (Windows).

Product and Performance Information

= = = = = = = = = = Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex. Notice revision #20201201 = = = = = = = = = =

Alternate Options:

Linux: -qopenmp

Windows: /Qopenmp

-fjump-tables (L*X only) and -fno-jump-tables (L*X only) — Determines whether jump tables are generated for switch statements. 🧚

Arguments: None

Default:

-fjump-tables — The compiler may use jump tables for switch statements.

Description:

This option determines whether jump tables are generated for switch statements.

Option -fno-jump-tables prevents the compiler from generating jump tables for switch statements. This action is performed unconditionally and independent of any generated code performance consideration.

...and just when you thought -fno-jump-tables was done spilling its tea, it has one more thing 👀

Option -fno-jump-tables also prevents the compiler from creating switch statements internally as a result of optimizations. Like, it will not sneak a switch back in behind your back. Rude of it to try, honestly.

Use -fno-jump-tables with -fpic when compiling objects that will be loaded in a way where the jump table relocation cannot be resolved. So bestie, if the relocation can't be resolved, you pair it up with -fpic. That's the combo. 💅

Alternate Options: None

-fkeep-static-consts (L*X only)
-fno-keep-static-consts (L*X only) — tells the compiler to preserve allocation of variables that are not referenced in the source.
- Arguments: None
- Default: -fno-keep-static-consts — if a variable is never referenced in a routine, the variable is discarded unless optimizations are disabled by option -O0 (Linux*)
- Description: this option tells the compiler to preserve allocation of variables that are not referenced in the source. The negated form can be useful when optimizations are enabled to reduce the memory usage of static data. So like, -fno-keep-static-consts is your girl for trimming down static data memory when you've got optimizations on. 🎀
- Alternate Options: None
-flink-huge-device-code (L*X only)
-fno-link-huge-device-code (L*X only) — tells the compiler to place device code later in the linked binary, which is to prevent 32-bit PC-relative relocations between surrounding Executable and Linkable Format (ELF) sections when the device code is larger than 2GB. Yes, 2GB, that's not a typo, that's a whole lot of device code 😭
- Arguments: None
- Default: fno-link-huge-device-code — no change is made to the linked binary.
- Description: this option tells the compiler to place device code later in the linked binary, to prevent those 32-bit PC-relative relocations between surrounding Executable and Linkable Format (ELF) sections when the device code is larger than 2GB. It impacts the host link for a full offload compilation. It does not impact device compilation directly, but it is only useful when offloading is performed. So it's giving "situational icon" energy ✨
- > NOTE: when using this option, you must also specify option -fsycl or option -fopenmp-targets.
- > NOTE: this option only takes effect if a link action needs to be executed. For example, it will not have any effect if certain other options are specified, such as -c or -E.
- Alternate Options: None
-flto[=arg] (L*X only)
-fno-lto (L*X only) — enables whole program link time optimization (LTO). The main character of build flags, fr fr 🔥
- Arguments:
  - arg — is the link time optimization to perform. Possible values are:
    - full — tells the compiler to merge all input into a single module before performing link time optimization (LTO). This is the default if you specify -flto with no argument.
    - thin — tells the compiler to read the information from a summary and then do LTO in parallel. This form of LTO (also called ThinLTO) is scalable and incremental. Slay 💅
- Default: -fno-lto — no link time optimization is performed.
- Description: this option enables whole program link time optimization (LTO). If you specify option -fno-lto, it disables whole program link time optimization. If you specify -flto or -flto=full, compilation time may increase because of the additional optimizations. Yeah, bestie, that's the tradeoff — more optimization, more waiting around 🫠
- Linux: you can specify option -ipo as an alias for -flto. -ipo is equivalent to -flto. If you want to specify a non-default linker, you must also specify option fuse-ld. Otherwise, the default linker ld will be used.
- Windows: you can specify /Qipo as an alias for -flto. /Qipo is the same as -flto during the compile step. During the link step, the compiler automatically adds -fuse-ld=lld so the proper linker (lld) will be picked up to perform the expected optimizations. This automatic inclusion is only performed for /Qipo; it is not performed for -flto on Windows. Noted and underlined ✍️
- > NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None
-fma (L*X only)
-no-fma (L*X only) — determines whether the compiler generates fused multiply-add (FMA) instructions if such instructions exist on the target processor.
- Arguments: None
- Default: -fma — if the instructions exist on the target processor, the compiler generates fused multiply-add (FMA) instructions. However, if you specify -fp-model strict (Linux*), but do not explicitly specify -fma, the default is -no-fma. Sneaky little plot twist, iykyk 🙈
- Description: this option determines whether the compiler generates fused multiply-add (FMA) instructions if such instructions exist on the target processor. When the [Q]fma option is specified, the compiler may generate FMA instructions for combining multiply and add operations. When the negative form of the [Q]fma option is specified, the compiler must generate separate multiply and add instructions with intermediate rounding. This option has no effect unless setting CORE-AVX2 or higher is specified for option [Q]x,-march (Linux), or /arch (Windows). So no CORE-AVX2, no effect — no cap 💀
- Alternate Options: None
-fmaintain-32-byte-stack-align (L*X only)
-fno-maintain-32-byte-stack-align (L*X only) — tells the compiler to realign the stack to 32-byte if stack alignment is uncertain for functions with external linkage, and retain 32-byte alignment for other functions.
- Arguments: None
- Default: OFF — the compiler assumes system alignment for the stack unless an option affecting that alignment is specified.
- Description: this option tells the compiler to realign the stack to 32-byte if stack alignment is uncertain for functions with external linkage, and retain 32-byte alignment for other functions. You should not use this option if you specify Clang options -mstack-alignment or -mstackrealign. Like, don't do both, that's not the vibe 🚫
- > NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None
-fmath-errno (L*X only)
-fno-math-errno (L*X only) — tells the compiler that errno can be reliably tested after calls to standard math library functions.
- Arguments: None
- Default: -fno-math-errno — the compiler assumes that the program does not test errno after calls to standard math library functions.
- Description: this option tells the compiler to assume that the program tests errno after calls to math library functions. This restricts optimization because it causes the compiler to treat most math functions as having side effects. Option -fno-math-errno tells the compiler to assume that the program does not test errno after calls to math library functions. This frequently allows the compiler to generate faster code. Floating-point code that relies on IEEE exceptions instead of errno to detect errors can safely use this option to improve performance. Faster code and it's still safe? We love to see it 💖
- Alternate Options: None
-fno-gnu-keywords (L*X only) — tells the compiler to not recognize typeof as a keyword.
- Arguments: None
- Default: OFF — keyword typeof is recognized.
- Description: tells the compiler to not recognize typeof as a keyword. Short and iconic, no notes 🎀
- Alternate Options: None
-fno-operator-names (L*X only) — disables support for the operator names specified in the standard.
- Arguments: None
- Default: OFF — operator names specified in the standard are supported.
- Description: this option disables support for the operator names specified in the standard.
- Alternate Options: None
-fno-rtti (L*X only) — disables support for runtime type information (RTTI).
- Arguments: None
- Default: OFF — support for runtime type information (RTTI) is enabled.
- Description: this option disables support for runtime type information (RTTI).
- Alternate Options: None
-fno-sycl-libspirv (L*X only) — disables the check for libspirv (the SPIR-V* tools library).
- Arguments: None
- Default: OFF — the check for libspirv is enabled.
- Description: this option disables the check for libspirv (the SPIR-V* tools library).
- > NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.
- Alternate Options: None
-fomit-frame-pointer (L*X only)
-fno-omit-frame-pointer (L*X only) — determines whether EBP is used as a general-purpose register in optimizations.
- Arguments: None
- Default: -fomit-frame-pointer — EBP is used as a general-purpose register in optimizations. However, the default can change depending on the following: ... 👀

If option -O0 or -g is specified, the default is -fno-omit-frame-pointer.

Description:

Okay so these two options are basically the EBP custody battle 💅 They decide whether EBP gets to be a general-purpose register when the compiler does its optimization thing. Option -fomit-frame-pointer says yes, use it. Option -fno-omit-frame-pointer says absolutely not, hands off.

Why would anyone care? Because some debuggers literally expect EBP to be holding down the stack frame pointer job, and they can't produce a stack backtrace unless that's the case 😭 The -fno-omit-frame-pointer option tells the compiler to generate code that maintains and uses EBP as a stack frame pointer for all functions, so a debugger can still produce a stack backtrace without you having to do this:

For -fno-omit-frame-pointer: turning off optimizations with -O0

The -fno-omit-frame-pointer option is set when you specify option -O0 or the -g option. The -fomit-frame-pointer option is set when you specify option -O1, -O2, or -O3.

NOTE: On Linux, there is currently an issue with GCC 3.2 exception handling. Therefore, the compiler ignores this option when GCC 3.2 is installed for C++ and exception handling is turned on (the default).

Alternate Options:

Linux: -fp (this is a deprecated option) 💀

`-fopenmp` (L*X only)

Enables recognition of OpenMP* features and tells the parallelizer to generate multi-threaded code based on OpenMP* directives. This option leads to lowering of OpenMP constructs in the compiler front-end (as it is implemented by the LLVM community), and is expected to be not as performant as using the option -fiopenmp, which enables the Intel implementation of OpenMP constructs where the lowering is done in the compiler backend. Also, this option does not support offloading to GPUs.

Arguments:

None

Default:

OFF — No OpenMP* multi-threaded code is generated by the compiler.

Description:

This option enables recognition of OpenMP* features and tells the parallelizer to generate multi-threaded code based on OpenMP* directives.

It's for the advanced users, the ones who specifically prefer to use OpenMP* as it is implemented by the LLVM community 🧚

NOTE: Option -fopenmp is not the same as option -fiopenmp. If you want to get full advantage of SIMD vectorization or offloading, you must use option -qopenmp or -fiopenmp.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

`-fopenmp-concurrent-host-device-compile` (L*X only)

Enables parallel compilation of host and target compilation steps when performing OpenMP offload compilations. This is an experimental feature.

Arguments:

None

Default:

OFF — No parallel compilation of host and target compilation steps occurs when OpenMP offload compilations are performed.

Description:

This option enables parallel compilation of host and target compilation steps when performing OpenMP offload compilations. It is an experimental feature, bestie — experimental 🔥

It parallelizes the compilation steps that create the host and target binaries only, and it may improve compilation times.

Alternate Options:

None

`-fopenmp-declare-target-scalar-defaultmap=`keyword (L*X only)

Determines which implicit data-mapping/sharing rules are applied for a scalar variable referenced in a target pragma.

Arguments:

keyword — is the rule to be applied for a scalar variable referenced in a target pragma. Possible values are:
- default — Specifies that the compiler should apply implicit data-mapping/sharing rules according to the OpenMP* specification.

Thus, if a scalar variable referenced in a target construct appears in a to or link clause in a declare target pragma that does not have a device_type (nohost) clause, and the target construct's clauses do not define explicit data-mapping/sharing rules for this variable, then the compiler should treat it as if it had appeared in a map clause with a map-type of tofrom.

firstprivate — Specifies that when a scalar variable referenced in a target construct appears in a to or link clause in a declare target pragma that does not have a device_type (nohost) clause, and the target construct's clauses do not define explicit data-mapping/sharing rules for this variable, then the scalar variable should not be mapped, but instead it has an implicit data-sharing attribute of firstprivate.

Default:

-fopenmp-declare-target-scalar-defaultmap=default

The compiler applies implicit data-mapping/sharing rules according to OpenMP specification.

Description:

This option determines which implicit data-mapping/sharing rules are applied for a scalar variable referenced in a target pragma, when that scalar variable appears in a declare target pragma that has a to or link clause, but not clause device_type (nohost).

It tells the compiler to assume that a scalar declare target variable with implicit data-mapping/sharing referenced in a target construct has the same value before the target construct (in the host environment) and at the beginning the target region (in the device environment). This may enable some optimizations in the host code invoking the target region for execution ✨

The option only affects data-mapping/sharing rules for scalar variables referenced in a target construct that do not appear in one of the target clauses map, is_device_ptr, or has_device_addr.

For more information about implicit data-mapping/sharing rules, see the OpenMP 5.2 specification. For example, see section 5.8.1 in that specification. (iykyk 📖)

Alternate Options:

None

`-fopenmp-device-code-split=[`triple`=]per_kernel` (L*X only)

Enables parallel compilation of SPIR-V* kernels for OpenMP offload Ahead-Of-Time compilation.

Arguments:

triple — Is a target device name, such as spir64, spir64_gen, etc.. If triple is specified, code splitting will only be applied for that specific target.
per_kernel — Creates a separate device code module for each SYCL* kernel. Each device code module will contain a kernel and all its dependencies, such as called functions and used variables.

Default:

OFF — No device code splitting of SPIR-V* kernels occurs for OpenMP offload Ahead-Of-Time compilation.

Description:

This option enables parallel compilation of SPIR-V* kernels for OpenMP offload Ahead-Of-Time compilation.

To specify the maximum number of parallel actions to perform, use option -fopenmp-max-parallel-link-jobs (Linux) or /Qopenmp-max-parallel-link-jobs (Windows).

NOTE: When OpenMP offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

`-fopenmp-device-lib=library[,library,...]` (L*X only)

`-fno-openmp-device-lib=library[,library,...]` (L*X only)

Enables or disables certain device libraries for an OpenMP* target.

Arguments:

library — Possible values are:
- libm-fp32 — Enables linking to the fp32 device math library.
- libm-fp64 — Enables linking to the fp64 device math library.
- libc — Enables linking to the C library.
- all — Enables linking to libraries libm-fp32, libm-fp-64, and libc.

To link more than one library, include a comma between the library names. For example, if you want to link both the libm-fp32 device library and the C library, specify: libm-fp32,libc.

Do not add spaces between library names. 🙈

Note that if you specify "all", it supersedes any additional value you may specify.

Default:

OFF — Disables linking to device libraries for this target.

Description:

This option enables or disables certain device libraries for an OpenMP* target.

If you specify fno-openmp-device-lib=library, linking to the specified library is disabled for the OpenMP* target. 🎀

⚠️ NOTE: When OpenMP* offloading is enabled, this option only applies to device-specific compilation.

Alternate Options: None

-fopenmp-device-link (L*X only) — okay bestie, this is the “do the device link during compilation instead of link time” switch ✨
- Arguments: None.
- Default: OFF — the compiler follows default heuristics during compilation.
- Description: This option determines whether the compiler performs a device link during the compilation step instead of a link step. When enabled for OpenMP offload compilations, it produces file device binaries within the generated fat object.

It is only valid for SPIR64-based devices.

This option is useful for building static libraries, such as the Intel(R) oneAPI Math Kernel Library (oneMKL), since it can reduce the compilation time of an application using them.

NOTE: Option -fopenmp-device-link and /Qopenmp-device-link can have an effect on options that are enabled during the device linking phase because it shifts when certain compilation steps occur.

When generating the fat object, anything that used to impact device linking during the link phase (for example, option -Xopenmp-target-backend), will be applied during the compilation phase.

NOTE: When OpenMP* offloading is enabled, this option only applies to device-specific compilation.

Alternate Options: None.

-fopenmp-max-parallel-link-jobs=num (L*X only) — this one is literally “how many parallel actions can we run during device linking?” energy 💅
- Arguments: num — is the maximum number of parallel actions to perform.
- Default: OFF — parallelization of device linking steps is disabled.
- Description: This option determines the maximum number of parallel actions to be performed during device linking steps, where applicable.

This option is useful when you specify option -fopenmp-device-code-split (Linux) or /Qopenmp-device-code-split (Windows) and want to control the number of parallel actions performed.

NOTE: When OpenMP offloading is enabled, this option only applies to device-specific compilation.

Alternate Options: None.

-fopenmp-offload-mandatory (for Clang compatibility) (L*X only) (L*X only) — the “device version only, no host fallback, periodt” option 👑
- Arguments: None.
- Default: OFF — when this option is not specified, the compiler generates both a host (CPU) and a target device version of OpenMP target regions; if offloading fails for a target region, it executes on the host.
- Description: This option tells the compiler to generate only a target device (GPU) version of OpenMP target regions. A runtime error is issued if offloading fails.

NOTE: To use this option, you must enable OpenMP offloading by specifying option -fopenmp-targets (Linux) or /Qopenmp-targets (Windows).

Alternate Options: None.

-fopenmp-target-buffers=keyword (L*X only) — this is the big-buffer problem-solver for some SPIR-V* devices, and yes, 4GB is the whole plot 🫶
- Arguments: keyword — possible values are:
  - default — tells the compiler to use default heuristics. This may produce incorrect code on some OpenMP* offload SPIR-V* devices when a target object is larger than 4GB.
  - 4GB — tells the compiler to generate code to prevent the issue described by default. OpenMP* offload programs that access target objects of size larger than 4GB in target code require this option.

This setting applies to the following:

Target objects declared in OpenMP* target regions or inside OpenMP* declare target functions
Target objects that exist in the OpenMP* device data environment
Objects that are mapped and/or allocated by means of OpenMP* APIs (such as omp_target_alloc)

Default: default — if you do not specify this option, the compiler may produce incorrect code on some OpenMP* offload SPIR-V* devices when a target object is larger than 4GB.
Description: This option enables a way to overcome the problem where some OpenMP* offload SPIR-V* devices produce incorrect code when a target object is larger than 4GB (4294959104 bytes).

However, note that when -fopenmp-target-buffers=4GB (or /Qopenmp-target-buffers:4GB) is specified on Intel(R) GPUs, there may be a decrease in performance.

To use this option, you must also specify option -fopenmp-targets (Linux*) or /Qopenmp-targets (Windows*).

NOTE: This option may have no effect for some OpenMP* offload SPIR-V* devices, and for OpenMP* offload targets different from SPIR*.

NOTE: When OpenMP* offloading is enabled, this option only applies to device-specific compilation.

Alternate Options: None.

-fopenmp-target-default-sub-group-size=val (L*X only) — sets a default sub-group size globally for SPMD kernels when offloading to SPIR64-based devices 🎀
- Arguments: val — specifies the default fallback value.

The supported values are dependent on which sub-group sizes are supported on the hardware that the program is running on. For example, on PonteVecchio (PVC) devices, the supported values are 16 and 32.

Default: OFF — the compiler uses default heuristics when determining global simd length for kernels unless a compiler option specifies otherwise.
Description: This option lets you specify a default sub-group size globally for single program multiple data (SPMD) kernels that are generated for OpenMP target constructs when offloading to SPIR64-based devices.

This option is ignored for SIMD kernels; that is, when you also specify option -fopenmp-target-simd (Linux) or /Qopenmp-target-simd (Windows).

To use option -fopenmp-target-default-sub-group-size or /Qopenmp-target-default-sub-group-size, you must also specify option -fopenmp-targets=spir64 (Linux) or option /Qopenmp-targets:spir64 (Windows).

NOTE: When OpenMP offloading is enabled, this option only applies to device-specific compilation.

Alternate Options: None.

-fopenmp-target-loopopt (L*X only) — loop optimizer + auto-vectorization for OpenMP* offloading device compilation when O2 or higher is set or specified 🔥
- Arguments: None.
- Default: OFF — the compiler uses default heuristics for optimization.
- Description: This option enables the loop optimizer and auto-vectorization for OpenMP* offloading device compilation when option O2 or higher is set or specified.

This option is only valid for SPIR64-based devices.

NOTE: When OpenMP offloading is enabled, this option only applies to device-specific compilation.

Alternate Options: None.

-fopenmp-target-simd (L*X only) — OpenMP* SIMD loop vectorization for OpenMP offloading device compilation when option level O2 or higher is set or specified 🦋
- Arguments: None.
- Default: OFF — the compiler uses default heuristics for SIMD loop vectorization.
- Description: This option enables OpenMP* SIMD loop vectorization for OpenMP offloading device compilation when option level O2 or higher is set or specified.

This option is ignored unless OpenMP offloading is enabled, and it is only valid for SPIR64-based devices.

NOTE: When OpenMP offloading is enabled, this option only applies to device-specific compilation.

Alternate Options: None.

-fopenmp-targets=triple (L*X only) — enables offloading to a specified GPU target if OpenMP* features have been enabled ⭐
- Arguments: triple — is a target triple device name. The following triplets are supported.
spir64_x86_64 — tells the compiler to enable offloading to Intel(R) CPUs.
spir64_gen — tells the compiler to enable offloading to Intel(R) Processor Graphics.

ok so like, for example ✨ when you specify spir64, the compiler generates an x86 + SPIR64 (64-bit Standard Portable Intermediate Representation) fat binary for Intel(R) GPU devices. it's giving "one binary, many vibes" 💅

Default:

OFF — if this option is not specified, no fat binaries are created. none. zero. nada 🫶

Description:

this option enables offloading to a specified GPU target if OpenMP* features have been enabled.

to use this option, you must enable recognition of OpenMP* features by specifying one of the following options, bestie:

Linux

-qopenmp
-fiopenmp
-fopenmp

Windows

/Qopenmp
/Qiopenmp

the following shows an example — copy it exactly, i'm not kidding 🙈:

icx -fiopenmp -fopenmp-targets=spir64 matmul_offload.cpp -o matmul

when you specify -fopenmp-targets or /Qopenmp-targets, C++ exception handling is disabled for target compilations. that's just how it is, periodt.

Linux

for host compilations, if you want to disable C++ exception handling, you must specify option -fno-exceptions.

NOTE: when OpenMP* offloading is enabled, this option only applies to device-specific compilation. it's a device-only situation, iykyk 💀

Alternate Options:

None

`-foptimize-sibling-calls` (`L*X` only)

`-fno-optimize-sibling-calls` (`L*X` only)

determines whether the compiler optimizes tail recursive calls. it's literally the whole personality of this flag 🌀

Arguments:

None

Default:

-foptimize-sibling-calls — the compiler optimizes tail recursive calls.

Description:

this option determines whether the compiler optimizes tail recursive calls. it enables conversion of tail recursion into loops. so much slay 🌸

if you do not want to optimize tail recursive calls, specify -fno-optimize-sibling-calls.

tail recursion is a special form of recursion that doesn't use stack space. in tail recursion, a recursive call is converted to a GOTO statement that returns to the beginning of the function. in this case, the return value of the recursive call is only used to be returned. it is not used in another expression. the recursive function is converted into a loop, which prevents modification of the stack space used. no stack drama, no cap 🔥

Alternate Options:

None

`-fortlib` (`L*X` only)

tells the C/C++ compiler driver to link to the Fortran libraries. this option is primarily used by C/C++ for mixed-language programming. it's giving crossover episode 🤝

Arguments:

None

Default:

OFF — C/C++ compiler drivers do not link to Fortran libraries.

Description:

this option tells the C/C++ compiler driver to link to the Fortran libraries. this option is primarily used by C/C++ for mixed-language programming.

it is useful for building mixed Fortran and C/C++ applications, and it is only effective at link time. link time, bestie — do not come for me about compile time 💅

Alternate Options:

None

`-fpack-struct` (`L*X` only)

specifies that structure members should be packed together. squish them. cozy little struct 🎀

Arguments:

None

Default:

OFF

Description:

specifies that structure members should be packed together.

NOTE: using this option may result in code that is not usable with standard (system) c and C++ libraries. like, it will not slay with the system libs. warned you 😭

Alternate Options:

Linux: -Zp1

`-fpermissive` (`L*X` only)

tells the compiler to allow for non-conformant code. yes it's a little chaotic, that's the point 🙈

Arguments:

None

Default:

OFF — the compiler does not allow for non-conformant code.

Description:

tells the compiler to allow for non-conformant code.

Alternate Options:

None

`-fpic` (`L*X` only)

`-fno-pic` (`L*X` only)

determines whether the compiler generates position-independent code. the "can we move it around" vibe check ✨

Arguments:

None

Default:

-fno-pic — the compiler does not generate position-independent code.

Description:

this option determines whether the compiler generates position-independent code.

option -fpic specifies full symbol preemption. global symbol definitions as well as global symbol references get default (that is, preemptable) visibility unless explicitly specified otherwise. everyone's preemptable unless you say otherwise, iconic 👑

option -fpic must be used when building shared objects. MUST. it's not a suggestion, bestie 🫶

this option can also be specified as -fPIC. same flag, different capitalization, both valid, we love options 💜

Alternate Options:

None

`-fpie` (`L*X` only)

tells the compiler to generate position-independent code. the generated code can only be linked into executables. executable-only. exclusive. main character energy only 💅

Arguments:

None

Default:

OFF — the compiler does not generate position-independent code for an executable-only object.

Description:

this option tells the compiler to generate position-independent code. it is similar to -fpic, but code generated by -fpie can only be linked into an executable.

because the object is linked into an executable, this option causes better optimization of some symbol references. cute AND efficient 🌸

to ensure that runtime libraries are set up properly for the executable, you should also specify option -pie to the compiler driver on the link command line. don't forget it, i'm begging 🙏

option -fpie can also be specified as -fPIE. again with the capitalization, it's giving aesthetic 🌈

Alternate Options:

None

`-fp-model=keyword` (`L*X` only)

controls the semantics of floating-point calculations. floating point is a whole personality trait ngl 🦋

Arguments:

keyword — specifies the semantics to be used. possible values are:
- precise — disables optimizations that are not value-safe on floating-point data.
- fast[=1|2] — enables more aggressive optimizations on floating-point data. if you specify fast with no number, it is equivalent to fast=1.
- consistent — disables optimizations that are not value-safe on floating-point data and disables contraction (FMA) and selects math library functions that produce consistent results across different microarchitectural implementations of the same architecture.
- strict — enables precise, disables contractions, and enables pragma stdc fenv_access.

Default:

-fp-model=fast — the compiler uses more aggressive optimizations on floating-point calculations.

Description:

this option controls the semantics of floating-point calculations.

the floating-point (FP) environment is a collection of registers that control the behavior of FP machine instructions and indicate the current FP status. the floating-point environment may include rounding-mode controls, exception masks, flush-to-zero controls, exception status flags, and other floating-point related features. it's a whole little ecosystem in there 🧚

-fp-model=precise or /fp:precise — tells the compiler to strictly adhere to value-safe optimizations when implementing floating-point calculations. it disables optimizations that can change the result of floating-point calculations, which is required for strict ANSI conformance.

these semantics ensure the reproducibility of floating-point computations for serial code, including code vectorized or auto-parallelized by the compiler, but they may slow performance. they do not ensure value safety or run-to-run reproducibility of other parallel code. so like, reproducible, but at what cost 😭

run-to-run reproducibility for floating-point reductions in OpenMP* code may be obtained for a fixed number of threads through the KMP_DETERMINISTIC_REDUCTION environment variable. for more information about this environment variable, see topic "Supported Environment Variables". go read it, i'll wait 💖

the compiler assumes the default floating-point environment; you are not allowed to modify it. not allowed. hands off 🚫

-fp-model=fast[=1|2] or /fp:fast[=1|2] — tells the compiler to use more aggressive optimizations when implementing floating-point calculations. these optimizations increase speed, but they may affect the accuracy or reproducibility of floating-point computations. fast but feral 🔥

specifying fast is the same as specifying fast=1.

For the fast setting, fast=1 is the default and it recognizes plus supports NaN and infinite values. If you set fast=2, it does not — no NaN or infinite values will be used or produced. 🫶

-fp-model=consistent or /fp:consistent disables optimizations that are not value-safe on floating-point data, disables contraction (FMA), and selects math library functions that produce consistent results across different microarchitectural implementations of the same architecture.

For more info, see the article titled: Consistency of Floating-Point Results using the Intel(R) Compiler.

-fp-model=strict or /fp:strict tells the compiler to strictly adhere to value-safe optimizations when implementing floating-point calculations and enables floating-point exception semantics. This is the strictest floating-point model. 🔥

The compiler does not assume the default floating-point environment; you are allowed to modify it. 💅

The -fp-model and /fp options determine the setting for the maximum allowable relative error for math library function results (max-error) if none of the following options are specified:

-fimf-accuracy-bits (Linux*) or /Qimf-accuracy-bits (Windows*)
-fimf-max-error (Linux) or /Qimf-max-error (Windows)
-fimf-precision (Linux) or /Qimf-precision (Windows)

Option -fp-model=fast (and /fp:fast) sets option -fimf-precision=medium (/Qimf-precision:medium) and option -fp-model=precise (and /fp:precise); it implies -fimf-precision=high (and /Qimf-precision:high).

✨ Product and Performance Information ✨

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.

Notice revision #20201201

Alternate Options: None

`-fpreview-breaking-changes` — `L*X only`

Lets a user tell the compiler that they are willing to give up backward compatibility guarantees and lets the compiler enable new backward breaking changes that will appear in the next major release. 👑

Arguments:

None

Default:

OFF — The compiler follows default heuristics for backward compatibility.

Description:

This option lets a user tell the compiler that they are willing to give up backward compatibility guarantees and lets the compiler enable new backward breaking changes that will appear in the next major release.

The breaking changes specified will be the default in the next major compiler release. So, this option lets you prepare for that release should you want to do so. 🎀

When this option is specified, it sets the macro __INTEL_PREVIEW_BREAKING_CHANGES.

When this option is used along with option -fsycl, the driver will link against an alternate form of libsycl, which is libsycl-preview.

NOTE: To decide whether you want to choose to use the latest changes made by developers, see the Release Notes, which will show what is actually enabled by option -fpreview-breaking-release in each release.

Alternate Options: None

`-fprofile-dwo-dir=dir` — `L*X only`

Specifies the directory where .dwo files should be stored when using options fprofile-sample-generate and gsplit-dwarf. This is an experimental feature. 🧚

Arguments:

dir — Is the directory where the DWARF .dwo files should be stored.

Default:

OFF — The compiler stores .dwo files in the default directory.

Description:

This option specifies the directory where .dwo files should be stored when using options fprofile-sample-generate and gsplit-dwarf. It is an experimental feature.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

`-fprofile-ml-use` — `L*X only`

Enables the use of a pre-trained machine learning model to predict branch execution probabilities driving profile-guided optimizations. This is a deprecated option that will be removed in a future release. 💀

Arguments:

None

Default:

OFF — The compiler follows default static heuristics for profile-guided optimizations.

Description:

This option enables the use of a pre-trained machine learning model to predict branch execution probabilities driving profile-guided optimizations.

It is a deprecated option that will be removed in a future release. There is no replacement option.

This option replaces the default static heuristics in the compiler and serves as a single-pass proxy to get the performance gains from the true 2-pass profiling methods by instrumentation/sampling.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

`-fprofile-sample-generate[=level]` — `L*X only`

Enables the compiler and linker to generate information and adjust optimization for Hardware Profile-Guided Optimization (HWPGO). 🌈

Arguments:

level — Specifies which actions the compiler should perform. Possible values are:

none — This is the same as not specifying option fprofile-sample-generate.
keep-all-opt — Tells the compiler and linker to generate information for HWPGO without disabling any optimization. This is the default if you do not specify level.
med-fidelity — Tells the compiler and linker to generate information for HWPGO and disables some optimizations that inhibit profile fidelity.
max-fidelity — Tells the compiler and linker to generate information for HWPGO and disables most compiler optimizations. This provides a binary that targets execution count profile fidelity above all else.

Default:

OFF — The compiler and linker do not generate information for HWPGO.

Description:

This option enables the compiler and linker to generate information and adjust optimization for Hardware Profile-Guided Optimization (HWPGO).

On Windows, the following cautions apply when using this option:

The LLD linker is required and you must specify /profile-sample-generate as a link option if the LLD linker is not invoked by icx/icpx.
Do not specify option /Ob0 or /Ob1 with option /fprofile-sample-generate or /fprofile-sample-use because it will disable inlining.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

`-fprofile-sample-use=profile-file` and `-fno-profile-sample-use` — `L*X only`

Enables the compiler and linker to use information for Hardware Profile-Guided Optimization (HWPGO). This is an experimental feature. 🦋

Arguments:

profile-file — Is the profile data file generated by llvm-profgen.

Default:

fno-profile-sample-use — Profiling information is not used during optimization.

Description:

This option enables the compiler and linker to use information for Hardware Profile-Guided Optimization (HWPGO). It is an experimental feature.

NOTE: On Windows, do not specify option /Ob0 or /Ob1 with option /fprofile-sample-use or /fprofile-sample-generate because it will disable inlining.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

`-fp-speculation=mode` — `L*X only`

Tells the compiler the mode in which to speculate on floating-point operations. 💫

Arguments:

mode — Is the mode for floating-point operations. Possible values are:

fast — Tells the compiler to speculate on floating-point operations.
safe — Tells the compiler to disable speculation if there is a possibility that the speculation may cause a floating-point exception.
strict — Tells the compiler to disable speculation on floating-point operations.

Default:

-fp-speculation=fast — ok so the compiler speculates on floating-point operations 💅. This is also the behavior when optimizations are enabled.

However, if you specify no optimizations (-O0), the default changes to -fp-speculation=safe (Linux). 😭

Description: This option tells the compiler the mode in which to speculate on floating-point operations.
Disabling speculation may prevent the vectorization of some loops containing conditionals.
Alternate Options: None

-fshort-enums (L*X only) — tells the compiler to allocate as many bytes as needed for enumerated types. 🦋
- Arguments: None
- Default: OFF — the compiler allocates a default number of bytes for enumerated types.
- Description: This option tells the compiler to allocate as many bytes as needed for enumerated types.
- Alternate Options: None
-fno-stack-protector[-keyword] (L*X only) — enables or disables stack overflow security checks. 💀
- Arguments:
  - keyword — possible values are:
    - strong — when option -fstack-protector-strong is specified, it enables stack overflow security checks for routines with any type of buffer.
    - all — when option -fstack-protector-all is specified, it enables stack overflow security checks for every routine.
- If no -keyword is specified, option -fstack-protector enables stack overflow security checks for routines with a string buffer.
- Default:
  - -fno-stack-protector, -fno-stack-protector-strong — No stack overflow security checks are enabled for the relevant routines.
  - -fno-stack-protector-all — No stack overflow security checks are enabled for any routines.
- Description: This option enables or disables stack overflow security checks for certain (or all) routines. A stack overflow occurs when a program stores more data in a variable on the execution stack than is allocated to the variable. Writing past the end of a string buffer or using an index for an array that is larger than the array bound could cause a stack overflow and security violations.
- The -fstack-protector options are provided for compatibility with gcc. If the gcc/glibc implementation is available, it is used; otherwise, the Intel implementation is used.
- For an Intel-specific version of this feature, see option -fstack-security-check.
- Alternate Options: None
-fstack-security-check (L*X only), -fno-stack-security-check (L*X only) — determines whether the compiler generates code that detects some buffer overruns. 🫶
- Arguments: None
- Default: -fno-stack-security-check — the compiler does not detect buffer overruns.
- Description: This option determines whether the compiler generates code that detects some buffer overruns that overwrite the return address. This is a common technique for exploiting code that does not enforce buffer size restrictions.
- This option always uses an Intel implementation.
- For a gcc-compliant version of this feature, see option fstack-protector.
- NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: Linux: None; Windows: /GS
-fsycl (L*X only) — enables a program to be compiled as a SYCL program rather than as plain C++11 program. ✨
- Arguments: None
- Default:
  - SYCL: ON — A C++ program is compiled as a SYCL program.
  - C++: OFF — A C++ program is compiled as a C++11 program.
- Description: This option enables a program to be compiled as a SYCL program rather than as plain C++11 program.
- NOTE: On Windows, option -fsycl sets option /MD, which tells the linker to search for unresolved references in a multithreaded, dynamic-link runtime library. You cannot specify option /MT.
- NOTE: On Windows, to prevent potential sycl.lib library conflicts, you should add any desired SYCL library by specifying the library in the link command.
- Alternate Options: None
-fsycl-add-default-spec-consts-image (L*X only), -fno-sycl-add-default-spec-consts-image (L*X only) — enables or disables generation of a copy of every device image that uses a specialization constant, and replaces all instances of that specialization constant with default values defined in the relevant specialization_id variable. 🎀
- Arguments: None
- Default: OFF — No device image copies are generated and specialization constants are unchanged.
- Description: This option enables or disables generation of a copy of every device image that uses a specialization constant, and replaces all instances of that specialization constant with default values defined in the relevant specialization_id variable.
- If a device image does not use a specialization constant, no copy is generated. In this case, SYCL runtime chooses between a new generated device image and the original one depending on whether a specialization constant value was changed from the specified default value in the relevant specialization_id variable.
- This option is only useful if used with Ahead of Time (AOT) Compilation.
- If you specify -fno-sycl-add-default-spec-consts-image, it disables generation of copies of device images that use specialization constants where all instances are replaced with default values.
- NOTE: When using this option, you must also specify option -fsycl.
- NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None
-fsycl-allow-device-dependencies (L*X only), -fno-sycl-allow-device-dependencies (L*X only) — determines whether dependencies are allowed between device images when splitting device code. 💀 This is a deprecated option that will be removed in a future release. The replacement option is fsycl-allow-device-image-dependencies.
- Arguments: None
- Default: -fno-sycl-allow-device-dependencies — Dependencies are not allowed between device images when splitting device code.
- Description: This option determines whether dependencies are allowed between device images when splitting device code.
- Option -fsycl-allow-device-dependencies allows dependencies between device images.
- Option -fno-sycl-allow-device-dependencies constructs complete self-contained device images with no dependencies.
- NOTE: When using this option, you must also specify option -fsycl.
- NOTE: This option only affects device-code compilation.
- Alternate Options: None
-fsycl-allow-device-image-dependencies (L*X only), -fno-sycl-allow-device-image-dependencies (L*X only) — determines whether dependencies are allowed between device images when splitting device code. 🌈
- Arguments: None
- Default: -fno-sycl-allow-device-image-dependencies — Dependencies are not allowed between device images when splitting device code.
- Description: This option determines whether dependencies are allowed between device images when splitting device code.
- Option -fsycl-allow-device-image-dependencies allows dependencies between device images.
- Option -fno-sycl-allow-device-image-dependencies constructs complete self-contained device images with no dependencies.
- NOTE: When using this option, you must also specify -fsycl.
- This option only affects device-code compilation.
- Alternate Options: None
-fsycl-dead-args-optimization (L*X only), -fno-sycl-dead-args-optimization (L*X only) — enables elimination of SYCL dead kernel arguments. 🔥
- Arguments: None
- Default: OFF — SYCL dead kernel arguments are not eliminated. This default may change in the future.
- Description: This option enables elimination of SYCL dead kernel arguments. This optimization can improve performance.
- NOTE: When using this option, you must also specify option -fsycl.
- If you specify -fno-sycl-dead-args-optimization, this optimization is disabled.
- NOTE: When SYCL offloading is enabled, this option only applies to device-specific compilation.
- Alternate Options: None
-fsycl-device-code-split[=value] (L*X only) — specifies a SYCL* device code module assembly. 🧚
- Arguments: value — Can be only one of the following:
per_kernel — makes a separate device code module for each SYCL* kernel. Every one of those modules holds a kernel plus all of its dependencies, like the functions it calls and the variables it uses. 💅
- per_source — makes a separate device code module for each source (translation unit). Each module gets a whole lil collection of kernels grouped on a per-source basis, plus all their dependencies — all the used variables and called functions, including the SYCL_EXTERNAL macro-marked functions from other translation units. 🫶
- off — makes a single module for all kernels. If option -fsycl-no-rdc is specified, the behavior is the same as per_source. 💀
- auto — the compiler uses a heuristic to pick the best way of splitting device code. This is the same as specifying fsycl-device-code-split with no value. ✨

Default:

auto — this is the default whether you don't specify the compiler option at all, or you specify the compiler option but omit a value. The compiler uses a heuristic to select the best way of splitting device code. 👑

Description:

This option specifies a SYCL* device code module assembly.

CAUTION: if option -fno-sycl-rdc is also specified, option -fsycl-device-code-split=off is equivalent to -fsycl-device-code-split=per_source. Bestie, they are not the same thing at that point, okay? 🙈

NOTE: when using this option, you must also specify option -fsycl. no cap, it's required.

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

🌸 `-fsycl-device-lib=library[,library,...]` (L*X only)

🌸 `-fno-sycl-device-lib=library[,library,...]` (L*X only)

Enables or disables certain device libraries for a SYCL* target. it's giving "pick your fighters" 🎀

Arguments:

library — possible values are:
- libm-fp32 — enables linking to the fp32 device math library. ⭐
- libm-fp64 — enables linking to the fp64 device math library. ⭐
- libc — enables linking to the C library. 🍓
- all — enables linking to libraries libm-fp32, libm-fp-64, and libc.

To link more than one library, include a comma between the library names. For example, if you want to link both the libm-fp32 device library and the C library, specify: libm-fp32,libc.

Do not add spaces between library names. like, none. zero. 💀

Note that if you specify "all", it supersedes any additional value you may specify. it ate and left no crumbs 👑

Default:

OFF — disables linking to device libraries for this target.

Description:

This option enables or disables certain device libraries for a SYCL* target.

NOTE: when using this option, you must also specify option -fsycl.

If you specify fno-sycl-device-lib=library, linking to the specified library is disabled for the SYCL* target.

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

🦋 `-fsycl-device-obj=arg` (L*X only)

Lets you specify the format of device code stored in a resulting object. this one is an experimental feature, so like… proceed with the vibes in mind 🔥

Arguments:

arg — can be only one of the following:
- llvmir — creates Instruction Pointer (IP-based) fat objects. ✨
- spirv — creates Standard Portable Intermediate Representation (SPIR-V*-based) objects. ✨

Default:

-fsycl-device-obj=llvmir — if you do not specify option -fsycl-device-obj, the compiler will create IP-based fat objects. that's the default, periodt.

Description:

This option lets you specify the format of device code stored in a resulting object. It is an experimental feature.

NOTE: this compiler option is specific for the target binary type when it is bundled with the host object or generated independently with -fsycl-device-only.

Alternate Options:

None

🧚 `-fsycl-device-only` (L*X only)

Tells the compiler to generate a device-only binary. literally just the device part, no host, main character energy only 👑

Arguments:

None

Default:

OFF — no device-only binary is generated.

Description:

This option tells the compiler to generate a device-only binary.

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

🌈 `-fsycl-early-optimizations` (L*X only)

🌈 `-fno-sycl-early-optimizations` (L*X only)

Enables LLVM-related optimizations before SPIR-V* generation. glow-up before the SPIR-V moment, iykyk 💅

Arguments:

None

Default:

ON — LLVM-related optimizations are enabled before SPIR-V* generation.

Description:

This option enables LLVM-related optimizations before SPIR-V* generation. These optimizations can improve performance. 🔥

NOTE: when using this option, you must also specify option -fsycl.

If you specify -fno-sycl-early-optimizations, these optimizations are disabled.

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

💜 `-fsycl-enable-function-pointers` (L*X only)

Enables function pointers and support for virtual functions for SYCL kernels and device functions. this is an experimental feature, bestie 🧪✨

Arguments:

None

Default:

OFF — function pointers are not enabled and virtual functions for SYCL kernels and device functions are not supported.

Description:

This option enables function pointers and support for virtual functions for SYCL kernels and device functions. This is an experimental feature.

This enhanced support is limited to CPU-device only and cannot currently be used for GPU devices. 😭 sorry GPU girlies, not yet.

NOTE: when using this option, you must also specify option -fsycl.

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

🎀 `-fsycl-esimd-force-stateless-mem` (L*X only)

🎀 `-fno-sycl-esimd-force-stateless-mem` (L*X only)

Determines whether the compiler enforces stateless memory accesses within ESIMD kernels on the target device. also experimental 🙈

Arguments:

None

Default:

OFF — memory accesses that are stateful are not converted to stateless.

Description:

This option determines whether the compiler enforces stateless memory accesses within ESIMD kernels on the target device. This is an experimental feature.

Option -fsycl-esimd-force-stateless-mem uses SYCL* accessors to convert stateful memory to stateless memory. SIMD intrinsics that cannot be automatically converted are disabled and reported during the compilation phase. so like, it tells you when it can't do the thing. 💅

In cases where a target does not support stateful accesses, option -fsycl-esimd-force-stateless-mem may be helpful to avoid issues caused by the 4Gb-per-surface limitation in programs written with SYCL accessors. yes, the 4Gb-per-surface limitation is real and it is the villain of this story 😤

NOTE: when using this option, you must also specify option -fsycl.

If you specify -fno-sycl-esimd-force-stateless-mem, the compiler does not enforce stateless memory accesses.

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

🍓 `-fsycl-explicit-simd` (L*X only)

🍓 `-fno-sycl-explicit-simd` (L*X only)

Enables or disables the experimental "Explicit SIMD" SYCL* extension.

heads up: this is a deprecated option that may be removed in a future release. it's giving "senior year, one foot out the door" 💀 don't build your whole personality on it.

Arguments:

None

Default:

-fno-sycl-explicit-simd — the explicit SIMD SYCL* extension is disabled.

Description:

This option enables or disables the experimental "Explicit SIMD" SYCL* extension.

If you specify option -fsycl-explicit-simd, it enables the experimental "Explicit SIMD" SYCL* extension for lower-level Intel GPU programming. It allows you to write explicitly vectorized device code. Note that APIs for this feature may change in the future. ⚠️ so, like, don't get too attached, bestie.

NOTE: when using this option, you must also specify option -fsycl.

-fsycl-force-target=triple (L*X only) — forces the compiler to use the target triple device you name when it's pulling device code out of whatever objects you handed it on the command line 💅

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Arguments:

triple — a target triple device name. It literally tells the compiler which target should be unbundled or extracted out of fat objects or archives that have already been generated. The following triplets are supported:
- spir64 — tells the compiler the target is a SPIR64-based device ✨
- spir64_x86_64 — tells the compiler the target is Intel(R) CPU 🧚
- spir64_fpga — tells the compiler the target is Intel(R) FPGA 🎀
- spir64_gen — tells the compiler the target is Intel(R) Processor Graphics 🌸

Default:

OFF — if you don't specify this option, the compiler will unbundle or extract based on the setting of option -fsycl-targets.

Description:

This option forces the compiler to use the specified target triple device when extracting device code from any given objects on the command line.

You can have both spir64 and spir64_gen in your objects, bestie. When -fsycl-force-target is specified, the compiler will use the target specified in that option. It will not use the value specified in -fsycl-targets, even if it exists. like, it's not even a little tempted 😭

NOTE: when using this option, you must also specify option -fsycl.

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

-fsycl-fp64-conv-emu (L*X only) — tells the compiler to use fp64 partial emulation for kernels that only do fp64 conversion ops and no fp64 computation ops. It requires an Intel GPU that supports fp64 partial emulation 🦋

Arguments:

None

Default:

OFF — if this option is not specified, the compiler will not try to use fp64 partial emulation for any fp64 conversion operations.

Description:

This option tells the compiler to use fp64 partial emulation for kernels with only fp64 conversion operations and no fp64 computation operations. It requires an Intel GPU that supports fp64 partial emulation. no cap, check your hardware first 🙈

NOTE: when using this option, you must also specify option -fsycl.

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

-fsycl-help[=arg] (L*X only) — causes help information to be emitted from the device compiler backend 🫶

Arguments:

arg — can be one of "x86_64", "fpga", "gen", or "all". Option -fsycl-help=all outputs help for "x86_64", "fpga", and "gen". Specifying "all" is the same as specifying fsycl-help with no arg.

Default:

OFF — no help information is emitted from the device compiler backend.

Description:

This option causes help information to be emitted from the device compiler backend. it's giving "ask the backend itself" energy 💖

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

-fsycl-host-compiler=arg (L*X only) — tells the compiler to use the compiler you pick for the host compilation of the overall offloading compilation that's performed 👑

Arguments:

arg — is the compiler that will be the host for compilation. It can be the name of a compiler or the specific path to the compiler.

Default:

OFF — the host compilation will be performed by the Intel(R) DPC++ Compiler.

Description:

This option tells the compiler to use the specified compiler for the host compilation of the overall offloading compilation that is performed. yes, you're the main character choosing your own host compiler 💅

NOTE: when using this option, you must also specify option -fsycl.

Alternate Options:

None

-fsycl-host-compiler-options="opts" (L*X only) — passes options to the compiler specified by option fsycl-host-compiler 🌈

Arguments:

opts — is a string of compatible compiler options to be passed. The string must appear within quotes. If there is more than one compiler option, a space must appear between each option name.

Default:

OFF — no options are passed to the compiler specified by -fsycl-host-compiler.

NOTE: if -fsycl-host-compiler=cl is specified, the host compilation will be performed by the Microsoft* __cplusplus preprocessor macro, which depends on the setting of option /Qstd (or MSVC-compatible option /std). In this case, the default is /Zc:__cplusplus. To override this default, specify option /fsycl-host-compiler-options=/Zc:cplusplus-. For more information about macro /Zc:__cplusplus, see the Microsoft documentation.

Description:

This option tells the compiler to pass options to the compiler specified by option fsycl-host-compiler. The options must be compatible with the compiler specified by fsycl-host-compiler.

NOTE: specifying any kind of phase limiting options (such as -c, -E, or -S) may interfere with the expected output set during the host compilation. This can cause undefined behavior. 💀 seriously, don't do it.

NOTE: when using this option, you must also specify option -fsycl.

Alternate Options:

None

-fsycl-id-queries-fit-in-int (L*X only)
-fno-sycl-id-queries-fit-in-int (L*X only) — tells the compiler to assume that SYCL ID queries fit within MAX_INT ⭐

Arguments:

None

Default:

ON — the compiler assumes that SYCL ID queries fit within MAX_INT.

Description:

This option tells the compiler to assume that SYCL ID queries fit within MAX_INT. It assumes that the following values fit within MAX_INT:

id class get() member function and operator[]
item class get_id() member function and operator[]
nd_item class get_global_id()/get_global_linear_id() member functions

For more information about these values, see the Khronos* Group SYCL* 1.2.1 Specification.

If you need to use a larger number of work items, use the OFF setting for this option, which is -fno-sycl-id-queries-fit-in-int.

CAUTION: you should carefully evaluate whether you should use the OFF setting when you have a larger number of work items. Truncating to data type int is often incorrect in such circumstances. If the OFF setting is used when the values fit within MAX_INT, it can lead to unexpected performance issues. 😬 so like, actually think about it, bestie.

NOTE: when using this option, you must also specify option -fsycl.

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

-fsycl-instrument-device-code (L*X only)
-fno-sycl-instrument-device-code (L*X only) — enables or disables linking of the Instrumentation and Tracing Technology (ITT) device libraries for VTune(TM) 🔥

Arguments:

None

Default:

ON — the device libraries needed for Instrumentation and Tracing Technology (ITT) are enabled.

Description:

This option enables or disables linking of the Instrumentation and Tracing Technology (ITT) device libraries for VTune(TM). This provides annotations to intercept various events inside kernels generated by Just in Time (JIT) compilation. it's giving spyware but make it profiling 🕵️‍♀️

NOTE: when using this option, you must also specify option -fsycl.

If you specify -fno-sycl-instrument-device-code, no linking occurs to the Instrumentation and Tracing Technology (ITT) device libraries.

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

-fsycl-link[=value] (L*X only) — tells the compiler to perform a partial link of device binaries to be used with Field Programmable Gate Array (FPGA) 🎀

Arguments:

value — can be one of the following:
- early — tells the compiler to generate an HTML report when the partial link is created. This capability lets you check the program if need be. You can resume from this point and generate an FPGA image by specifying option -fintelfpga with the generated binary.
- image — tells the compiler to generate an FPGA bitstream. It will then be ready to be linked and used on an FPGA board.

image takes much longer to generate than does early. 🐌✨

Default

OFF — No partial link of device binaries is performed.

Description

This option tells the compiler to perform a partial link of device binaries to be used with FPGA. 🛠️

This partial link is then wrapped by the offload wrapper, allowing the device binaries to be linked by the host compiler or linker. 🫶

If you do not specify a value, the following occurs:

When used with just -fsycl (-fsycl -fsycl-link), the driver will generate a host linkable device object.
When also used with -fintelfpga (-fsycl -fintelfpga -fsycl-link), the behavior is the same as specifying -fsycl-link=early.

NOTE: When using this option, you must also specify option -fsycl.

NOTE: When SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options

None

`-fsycl-max-parallel-link-jobs=n` (`L*X only`)

Tells the compiler that it can simultaneously spawn up to the specified number of processes to perform actions required to link SYCL applications. This is an experimental feature. 🧪🔥

Arguments

n — Is the number of processes to spawn to.

Default

-fsycl-max-parallel-link-jobs=1 — One process is simultaneously spawned to perform actions necessary to link SYCL applications.

Description

This option tells the compiler that it can simultaneously spawn up to the specified number of processes to perform actions required to link SYCL applications. This is an experimental feature. 👑

Note the following limitations when using this option:

This option has no effect if compiler options such as c or E are specified.
The option does not take effect when device code split is turned off by option -fsycl-device-code-split=off.
The number of processes spawned by -fsycl-max-parallel-link-jobs will not exceed the number of device code modules stemming from the application. For example, if the application contains m kernels, per_kernel device code split is requested, and n > m processes are requested by -fsycl-max-parallel-link-jobs, m processes will be the spawned maximum.
It is not guaranteed that n processes will always be active. For example, the current implementation does not enforce that the additional process will be instantly re-assigned to the next device code module after it has finished operating on the current one.
It is not guaranteed that spawning device link processes can be safely combined with the build system-level parallelization. Whenever specifying a large number of processes to be spawned for device code linkage, you need to beware of increased RAM usage, oversubscription risks, etc., which may cause performance and possibly compilation issues.

NOTE: When using this option, you must also specify option -fsycl.

NOTE: When SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options

None

`-fsycl-optimize-non-user-code` (`L*X only`)

Tells the compiler to optimize SYCL framework utility functions and to leave the kernel code unoptimized for further debugging. 🐛💅

Arguments

None

Default

OFF — SYCL framework functions and methods are not optimized.

Description

This option tells the compiler to optimize SYCL framework utility functions and to leave the kernel code unoptimized for further debugging. 🔍

To use this option, you must also specify option -O0 (Linux) or /Od (Windows). Do not specify any other optimization setting or you will get a compilation error. ⚠️

NOTE: When using this option, you must also specify option -fsycl.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options

None

`-fsycl-pstl-offload[=arg]` (`LX only`) / `-fno-sycl-pstl-offload` (`LX only`)

Enables the automatic offloading of C++ standard parallel algorithms to a SYCL device. 🚀✨

Arguments

arg is one of the following:

cpu — Tells the compiler to perform offloading to a SYCL CPU device.
gpu — Tells the compiler to perform offloading to a SYCL GPU device.

Default

-fno-sycl-pstl-offload — C++ standard parallel algorithms are not offloaded automatically.

Description

This option enables the automatic offloading of C++ standard parallel algorithms that were called with std::execution::par_unseq policy to a SYCL device. The offloaded algorithms are implemented via the oneAPI Data Parallel C++ Library (oneDPL). 💖

If you do not specify arg, it tells the compiler to perform offloading to the default SYCL device.

oneDPL is required for offloading support. See the oneDPL documentation for information about how to make it available in the environment. 📚

NOTE: When using this option, you must also specify option -fsycl.

The following are restrictions, requirements, and limitations when using option fsycl-pstl-offload:

Parallel algorithms callable objects restrictions — Parallel algorithms callable objects have the same limitations as SYCL kernels:
- Exceptions are not allowed.
- Dynamic memory allocation is not allowed.
- There can be unsupported API from std.

For the complete list of kernel limitations, see the SYCL 2020 specification.

Data placement requirements
- Only heap memory allocated with C++ standard dedicated facilities can be passed to the standard algorithms for offloading.
- std::vector can also be used with parallel algorithms for offloading since it dynamically allocated memory underneath.
- Stack allocated on the host cannot be used in offloaded parallel algorithms as well as std::array and C-style array on the stack. The solution for such a situation is to make a deep copy by capturing it in an algorithm callable by value or by allocating std::array or C-style array on the heap.
Other limitations:
- Only a subset of standard C++ APIs can be used in parallel algorithms callable objects. For the complete list, see the oneDPL documentation on Tested Standard C++ APIs.
- Option -fsycl-pstl-offload with the same argument must be applied to all Translation Units (TU) in an executable or a dynamic library.

Performance

If the performance is not satisfactory, the following environment variables may help:

Performance of memory allocations may be improved by using the SYCL_PI_LEVEL_ZERO_USM_ALLOCATOR environment variable.
Launch time performance of the algorithms may be improved by SYCL_CACHE_PERSISTENT environment variable.

For more information about these environment variables, see Environment Variables on GitHub.

NOTE: This option allows you to offload to NVIDIA* and AMD* GPUs, in addition to an Intel GPU.

To use an AMD GPU (Linux only):

Read the oneAPI for AMD GPUs Guide from Codeplay.
Download oneAPI for AMD GPUs.

To use a NVIDIA GPU (Linux and Windows):

Read the oneAPI for NVIDIA(R) GPUs Guide from Codeplay.
Visit the Download oneAPI for NVIDIA(R) GPUs.

Alternate Options

None

`-fsycl-rdc` (`LX only`) / `-fno-sycl-rdc` (`LX only`)

Determines whether the compiler generates relocatable device code during SYCL* offload target compilation. 🧩

Arguments

None

Default

-fsycl-rdc — The compiler generates relocatable device code during SYCL offload target compilation.

Description

This option determines whether the compiler generates relocatable device code (RDC) during SYCL* offload target compilation.

Option -fno-sycl-rdc disables relocatable device code during SYCL offload target compilation. It allows the compiler to link device code on a per-translation-unit basis. When this option is specified, device code cannot use SYCL_EXTERNAL functions.

Option -fno-sycl-rdc may improve compile time and compiler memory usage.

If you specify both option -fno-sycl-rdc and option -c (Linux) or /c (Windows), the compiler will produce final device binaries within the generated fat object.

If you specify both option -fno-sycl-rdc and option -fsycl-max-parallel-link-jobs, it enables additional device linking parallelism for fat static archives.

Option -fno-sycl-rdc can affect option -fsycl-device-code-split. If you specify both options, -fsycl-device-code-split=off is equivalent to -fsycl-device-code-split=per_source.

NOTE: When using this option, you must also specify option -fsycl.

NOTE: When SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options

None

`-fsycl-remove-unused-external-funcs` (`LX only`) / `-fno-sycl-remove-unused-external-funcs` (`LX only`)

Determines whether unused SYCL_EXTERNAL functions are removed during compilation of SYCL device code. 🧹✨

Arguments

None

Default

-fsycl-remove-unused-external-funcs — Unused SYCL_EXTERNAL functions are removed during compilation.

Description:

This option determines whether unused SYCL_EXTERNAL functions are removed during compilation of SYCL device code.

Specify -fno-sycl-remove-unused-external-funcs to disable this removal. This option may improve performance because it prevents SYCL_EXTERNAL functions from being treated as entry points for SYCL device code.

NOTE: When using this option, you must also specify option -fsycl.

NOTE: When SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

-fsycl-targets=T1,...,Tn (L*X only) — Tells the compiler to generate code for specified device targets.

Arguments:

T — Is a target triple device name. If you specify more than one T, they must be separated by commas. The following triplets are supported:
- spir64 — Tells the compiler to use default heuristics for SPIR64-based devices. This is the default. You can also specify this value as spir64-unknown-unknown.
- spir64_x86_64 — Tells the compiler to generate code for Intel(R) CPUs. You can also specify this value as spir64_x86_64-unknown-unknown.
- x86_64 — Tells the compiler to generate code ahead of time for x86_64 CPUs; it provides better debuggability. This triplet can also be specified as x86_64-unknown-unknown.
- spir64_fpga — Tells the compiler to generate code for Intel(R) FPGA. You can also specify this value as spir64_fpga-unknown-unknown.
- spir64_gen — Tells the compiler to generate code for Intel(R) Processor Graphics. You can also specify this value as spir64_gen-unknown-unknown.

Default:

spir64 — The compiler will use default heuristics for SPIR64-based devices.

Description:

This option tells the compiler to generate code for specified device targets.

Normally, option -fsycl-targets is specified when linking an application, in which case the Ahead of Time (AOT) compiled device binaries are embedded within the application's fat executable.

However, this option can also be used in combination with option -c (Linux) or /c (Windows) and option -fno-sycl-rdc when compiling a source file. In this case, the AOT compiled device binaries are embedded within the fat object file.

NOTE: The long syntax values that include -sycldevice, such as spir64-unknown-unknown-sycldevice, are still supported, but they are deprecated.

NOTE: When using this option, you must also specify option -fsycl.

NOTE: When SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

-fsycl-unnamed-lambda (L*X only), -fno-sycl-unnamed-lambda (L*X only) — Enables unnamed SYCL* lambda kernels.

Arguments:

None

Default:

ON — Unnamed SYCL lambda kernels are enabled.

Description:

This option enables unnamed SYCL kernels that are defined as lambdas.

NOTE: When using this option, you must also specify option -fsycl.

If you specify -fno-sycl-unnamed-lambda, unnamed SYCL lambda kernels are disabled.

NOTE: When SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

-fsycl-use-bitcode (L*X only) — Tells the compiler to produce device code in LLVM Intermediate Representation (IR) bitcode format into fat objects.

Arguments:

None

Default:

ON — LLVM IR bitcode format is emitted.

Description:

This option tells the compiler to produce device code in LLVM Intermediate Representation (IR) bitcode format into fat objects.

NOTE: When using this option, you must also specify option -fsycl.

NOTE: When SYCL offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

-fsyntax-only (L*X only) — Tells the compiler to check only for correct syntax.

Arguments:

None

Default:

OFF — Normal compilation is performed.

Description:

This option tells the compiler to check only for correct syntax. No object file is produced.

Alternate Options:

None

-fsystem-debug (L*X only), -fno-system-debug (L*X only) — Enables or disables generation of debug information for declarations in system headers.

Arguments:

None

Default:

-fsystem-debug — Debug information is generated for declarations in system headers.

Description:

This option enables or disables generation of debug information for declarations in system headers.

Specify option -fno-system-debug to disable generation of debug information for declarations in system headers. This option can be used to reduce the amount of debug information generated by Linux debug option -g or a MSVC debug option such as /Z7.

Alternate Options:

None

-ftarget-compile-fast (L*X only) — Tells the compiler to perform less aggressive optimizations to reduce compilation time at the expense of generating less optimal target code. This is an experimental feature.

Arguments:

None

Default:

OFF — Less aggressive optimizations to reduce compilation time are not performed.

Description:

This option tells the compiler to perform less aggressive optimizations to reduce compilation time at the expense of generating less optimal target code. This is an experimental feature.

It may be useful to specify this option in these cases:

When you are in a development period and want a fast turnaround time while testing
When you are specifying options O2 or O3 for a product with Just-in-Time (JIT) compilation, and both compile-time and execution performance are important

This option is not recommended when you are specifying options O2 or O3 for a product with Ahead-of-Time (AOT) compilation, where long but one-time compilation may be tolerable in order to achieve the best performance.

NOTE: This compiler option is not recommended if you plan to ship object files as part of a final product.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

-ftarget-export-symbols (L*X only), -fno-target-export-symbols (L*X only) — Exposes exported symbols in a generated target library to allow for visibility to other modules.

Arguments:

None

Default:

fno-target-export-symbols — Exported symbols in a generated target library are not exposed.

Description:

This option exposes exported symbols in a generated target library to allow for visibility to other modules.

It can be used to prevent unresolved symbols at runtime.

NOTE: When SYCL or OpenMP offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

-ftarget-register-alloc-mode=device-name:reg-mode[,device-name:reg-mode][,...] (L*X only) — Specifies a register allocation mode for specific hardware for use by supported target backends.

Arguments:

device-name — Is the device name. Currently, you can only specify the following:
- pvc — Indicates a Ponte Vecchio (PVC) device.
- More devices may be added in the future.
reg-mode — Is the register allocation mode. It can be any of the following:
- default — Tells the target backend to not impose any specification when choosing a register allocation mode.
- small — Tells the target backend to select small register allocation mode (for PVC, this means to use the 128 register file).
- large — Tells the target backend to select large register allocation mode (for PVC, this means to use the 256 register file).

auto — tells the target backend to use its own internal heuristics to pick a register allocation mode based on kernel analysis. iconic little autopilot behavior ✨

🌸 Default:

The following is the default behavior on PVC hardware:

Linux: -ftarget-register-alloc-mode=pvc:auto — tells the target backend to use internal heuristics to select a register allocation mode based on kernel analysis. slay, let the compiler read the room 💅
Windows: /Qtarget-register-alloc-mode=pvc:default — tells the target backend to not impose any specification when choosing a register allocation mode. no notes, just default energy 🎀

🦋 Description:

This option specifies a register allocation mode for specific hardware for use by supported target backends. Currently, it has no effect if you are targeting hardware other than Ponte Vecchio (PVC). PVC only, bestie 🫶

CAUTION: When compiling a SYCL program or an OMP-offload program for PVC, or if the program will run on PVC, you should not specify the register allocation mode using IGC (Intel Graphics Compiler) options such as -ze-opt-large-register-file in the -Xs high-level option. You should instead use option -ftarget-register-alloc-mode (Linux) or /Qtarget-register-alloc-mode (Windows). fr fr, use the right flag ⚠️

However, when you are targeting other hardware, you should use the IGC option. different hardware, different rules 🌈

NOTE: When SYCL offloading is enabled, this option only applies to device-specific compilation. device-specific only, iykyk 💀

⭐ Alternate Options:

None

-ftz (L*X only) — flushes denormal results to zero. bye-bye tiny denormals 🧚
-no-ftz (L*X only) — the paired option for that same denormal-flush behavior; full details below. the other half of the duo 💜

🍓 Arguments:

None

✨ Default:

-ftz — denormal results are flushed to zero.
Every optimization option O level, except O0, sets [Q]ftz. noted, bestie ✅

🌸 Description:

This option flushes denormal results to zero when the application is in the gradual underflow mode. It may improve performance if the denormal values are not critical to your application's behavior. performance wig, but only if denormals don't matter to you 🔥

The [Q]ftz option has no effect during compile-time optimization. compile-time said not today 🙈

The [Q]ftz option sets or resets the FTZ and the DAZ hardware flags. If FTZ is ON, denormal results from floating-point calculations will be set to the value zero. If FTZ is OFF, denormal results remain as is. If DAZ is ON, denormal values used as input to floating-point instructions will be treated as zero. If DAZ is OFF, denormal instruction inputs remain as is. Systems using Intel(R) 64 architecture have both FTZ and DAZ. hardware flags doing their little thing ⚙️

If you specify option -no-ftz (Linux) or option /Qftz- (Windows), it prevents the compiler from inserting any code that might set FTZ or DAZ. no sneaky flag-setting code 🫶

Option [Q]ftz only has an effect when the main program is being compiled. It sets the FTZ/DAZ mode for the process. The initial thread and any threads subsequently created by that process will operate in FTZ/DAZ mode. process-wide vibe check 🌈

If this option produces undesirable results of the numerical behavior of your program, you can turn the FTZ/DAZ mode off by specifying -no-ftz or /Qftz- in the command line while still benefiting from the O3 optimizations. you can still keep the O3 sparkle ✨

NOTE: Option [Q]ftz is a performance option. Setting this option does not guarantee that all denormals in a program are flushed to zero. The option only causes denormals generated at runtime to be flushed to zero. performance option only — no blanket promise ⚠️

⭐ Alternate Options:

None

-funsigned-char (L*X only) — sets the default character type to unsigned. char, but make it unsigned 💅

🎀 Arguments:

None

🦋 Default:

OFF — the default character type is signed. signed by default, bestie 🫶

🌸 Description:

This option sets the default character type to unsigned. This option has no effect on character values that are explicitly declared signed. This option sets _CHAR_UNSIGNED = 1. explicit signed chars stay signed, periodt ✅

⭐ Alternate Options:

None

-fuse-ld=keyword (L*X only) — tells the compiler to use a different linker instead of the default linker, which is ld on Linux and link on Windows. linker switch-up era 🔗

🍓 Arguments:

keyword — tells the compiler which non-default linker to use. Possible values are:
- bfd — tells the compiler to use the bfd linker. This setting is only available for Linux. Linux-only bfd moment 🐧
- gold — tells the compiler to use the gold linker. This setting is only available for Linux. Linux-only gold moment ✨
- lld — tells the compiler to use the lld linker. lld said hi 👋
- llvm-lib — tells the compiler to use the LLVM librarian. This setting is only available for Windows. Windows-only librarian behavior 🪟

💜 Default:

Linux: ld — the compiler uses the ld linker by default. classic Linux default 🐧
Windows: link — the compiler uses the link linker by default. classic Windows default 🪟

🌈 Description:

This option tells the compiler to use a different linker instead of the default linker, which is ld on Linux and link on Windows. same link, different linker energy 💅

On Linux, this option is provided for compatibility with gcc. gcc compatibility, we love to see it 🫶

NOTE: On Windows, option /Qipo automatically sets option -fuse-ld=lld. auto-set, no cap ⚠️

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. host only — offload is doing its own thing 💀

⭐ Alternate Options:

None

-fvec-allow-scalar-stores (L*X only) — ensures vectorization of an explicit simd loop. vectorize it, bestie ⚡
-fno-vec-allow-scalar-stores (L*X only) — the paired option for the same explicit simd loop vectorization behavior; details below. the other side of the vector vibe 🦋

🎀 Arguments:

None

🌸 Default:

-fno-vec-allow-scalar-stores — vectorization of explicit simd loops is not ensured. not guaranteed by default 🙈

✨ Description:

This option ensures vectorization of an explicit simd loop, such as one specified by #pragma omp simd. explicit simd loop got the memo 📝

This vectorization will occur even if the simd loop contains a store to a scalar variable that is not marked as private, lastprivate, or reduction. yes, even then 👀

The OpenMP* specification indicates that any store to a scalar variable in an explicit simd loop must be identified in the corresponding directive as either private, lastprivate, or reduction. Vectorization of a loop where this rule is violated may result in incorrect code being generated, especially if the scalar variable is reused within the loop. It is highly recommended that you follow the specification. However, if you are confident that this loop is safe to vectorize (i.e., you have received an incorrect error message), you can force vectorization to occur by specifying this option. forcing it can be risky — read the caution energy ⚠️

⭐ Alternate Options:

None

-fvec-non-loop-argument-load (L*X only) — determines whether the non-loop vectorizer combines loads for optimization. load-combining decision time 🧠
-fno-vec-non-loop-argument-load (L*X only) — the paired option for that same non-loop vectorizer load-combining behavior; details below. same topic, opposite switch 💜

🦋 Arguments:

None

🌸 Default:

-fvec-non-loop-argument-load — the non-loop vectorizer combines loads when profitable. if it pays off, it combines 💸

✨ Description:

When this option is set (default), the non-loop vectorizer combines loads when it appears to be profitable. profit check, then load-combine ✅

When this option is disabled, the non-loop vectorizer will not combine loads from an address passed as a parameter to the function being optimized when those loads are very near the beginning of the function. In rare cases, this is useful to prevent processor stalls when the function's caller has recently modified at least one of the same storage locations. rare edge case, but real 🌀

This option has no effect on the loop vectorizer. loop vectorizer said not my section 💅

⭐ Alternate Options:

None

-fvec-peel-loops (L*X only) — enables peel loop vectorization. peel loops, but make them vectorized 🍌
-fno-vec-peel-loops (L*X only) — the paired option for that same peel loop vectorization behavior; details below. opposite switch, same peel loop lore 🦋

🎀 Arguments:

None

🌸 Default:

-fno-vec-peel-loops — no peel loop vectorization occurs. peel loops stay unvectorized by default 🙈

✨ Description:

This option enables vectorization of peeling loops created during loop vectorization. It causes the compiler to perform additional steps to vectorize a peel loop that was created to improve alignment of memory references in the main vectorized loop. extra steps, extra alignment sparkle ✨

The peel loop can be vectorized only when the masked mode of vectorization is enabled by specifying option -fvec-with-mask or /Qvec-with-mask. masked mode is required, no cap 🎭

The vectorization of a peel loop cannot be enforced because the compiler uses the cost model to determine whether it should be done. cost model has the final say ⚖️

⭐ Alternate Options:

None

-fvec-remainder-loops (L*X only) — enables remainder loop vectorization. remainder loops getting the vector treatment 🌀
-fno-vec-remainder-loops (L*X only) — the paired option for that same remainder loop vectorization behavior; details below. same loop, opposite switch 💜

🦋 Arguments:

None

🌸 Default:

-fno-vec-remainder-loops — no remainder loop vectorization occurs. remainder loops stay unvectorized by default 🙈

✨ Description:

This option enables vectorization of remainder loops created during loop vectorization. It causes the compiler to perform additional steps to vectorize the remainder loop that was created for the vectorized main loop. main loop gets a vectorized little sibling 🫶

The compiler uses the cost model to determine vector factor and mode of vectorization for remainder loops. cost model chooses the vector factor and mode 🧠

The vectorization of remainder can be enforced using #pragma vector vecremainder on the loop. this one can be enforced, iykyk 🔥

⭐ Alternate Options:

None

-fvec-with-mask (L*X only) — enables vectorization for short trip-count loops with masking. short loops, masked and vectorized 🎭
-fno-vec-with-mask (L*X only) — the paired option for that same masked short trip-count loop vectorization behavior; details below. same masking moment, opposite switch 🦋

🎀 Arguments:

None

🌸 Default:

-fno-vec-with-mask — no vectorization for short trip-count loops with masking occurs. Like, none at all, bestie. 💅
- Description: This option enables a special mode of vectorization, which is applicable for loops with small number of iterations known at compile time. The peeling and remainder loops created during vectorization also fit into this category.
- In this mode, the compiler uses a vector factor that is the lowest power-of-two integer greater than the known (maximum) number of loop iterations. Usually, such vectorized loops have one iteration with most of operations masked.
- Alternate Options: None
-fverbose-asm (L*X only) — produces an assembly listing with compiler comments, including options and version information. ✨
- Arguments: None
- Default: -fno-verbose-asm — no source code annotations appear in the assembly listing file, if one is produced.
- Description: This option produces an assembly listing file with compiler comments, including options and version information.
- To use this option, you must also specify -S, which sets -fverbose-asm.
- If you do not want this default when you specify -S, specify -fno-verbose-asm.
- NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None
-fno-verbose-asm (L*X only) — the no-annotations side of things: no source code annotations appear in the assembly listing file, if one is produced. 🎀
-fvisibility=arg (L*X only) — specifies the default visibility for global symbols or the visibility for symbols in declarations, functions, or variables. This is the main-character visibility knob. 👑
- Arguments: arg — specifies the visibility setting. Possible values are:
  - default — sets visibility to default. The symbol is visible outside this shared object. This means that other components can reference the symbols, and the symbol definitions can be overridden (preempted) by a definition of the same name in another component.
  - hidden — sets visibility to hidden. The symbol is not visible outside this shared object. This means that other components cannot directly reference the symbol.
  - internal — this is the same as specifying hidden.
  - protected — sets visibility to protected. The symbol is seen by the dynamic linker but always dynamically resolves to an object within this shared object. This means that other components can reference the symbol, but it cannot be overridden by a definition of the same name in another component. This value is not supported on all targets.
- Default: -fvisibility=default — the compiler sets visibility of symbols to default.
- Description: This option specifies the default visibility for global symbols (syntax -fvisibility=arg) or the visibility for symbols in declarations, functions, or variables.
- The following table shows supported -fvisibility options:
  - -fvisibility=arg — sets visibility of symbols for all global declarations. As specified above in Arguments, arg can be one of the following: hidden internal default protected.
  - -fvisibility-global-new-delete-hidden — sets hidden visibility for global C++ operator new and delete declarations.
  - -fvisibility-inlines-hidden — sets hidden visibility by default for inline C++ member functions.
  - -fvisibility-inlines-hidden-static-local-var and -fno-visibility-inlines-hidden-static-local-var — when -fvisibility-inlines-hidden is enabled, static variables in inline C++ member functions will also be given hidden visibility by default. To disable option -fvisibility-inlines-hidden-static-local-var, specify option -fno-visibility-inlines-hidden-static-local-var.
  - -fvisibility-ms-compat — sets default visibility for global types and sets hidden visibility for global functions and variables.
- If an -fvisibility option is specified more than once on the command line, the last specification takes precedence over any others.
- The following shows the precedence of the visibility settings (from greatest to least visibility):
  1. default
  2. protected
  3. hidden
- NOTE: Clang fvisibility options are also supported. For more information on these options, see the Clang documentation.
- Alternate Options: None
-fvisibility-global-new-delete-hidden (L*X only) — sets hidden visibility for global C++ operator new and delete declarations. 🫶
-fvisibility-inlines-hidden (L*X only) — sets hidden visibility by default for inline C++ member functions. 💜
-f[no]visibility-inlines-hidden-static-local-var (L*X only) — when -fvisibility-inlines-hidden is enabled, static variables in inline C++ member functions will also be given hidden visibility by default. To disable option -fvisibility-inlines-hidden-static-local-var, specify option -fno-visibility-inlines-hidden-static-local-var. 🌸
-fvisibility-ms-compat (L*X only) — sets default visibility for global types and sets hidden visibility for global functions and variables. 🦋
-fzero-initialized-in-bss (L*X only) — determines whether the compiler places in the DATA section any variables explicitly initialized with zeros. Zero-init vibe check! ✨
- Arguments: None
- Default: -fno-zero-initialized-in-bss — variables explicitly initialized with zeros are placed in the BSS section. This can save space in the resulting code.
- Description: This option determines whether the compiler places in the DATA section any variables explicitly initialized with zeros.
- If option -fno-zero-initialized-in-bss (Linux*) or /Qzero-initialized-in-bss- (Windows*) is specified, the compiler places in the DATA section any variables that are initialized to zero.
- Alternate Options: None
-fno-zero-initialized-in-bss (L*X only) — the default: variables explicitly initialized with zeros are placed in the BSS section, which can save space in the resulting code. 💖
-g[n] (L*X only) — tells the compiler to generate a level of debugging information in the object file. Debug info era. 🎀
- Arguments: n — is the level of debugging information to be generated. Possible values are:
  - 0 — disables generation of symbolic debug information.
  - 1 — produces minimal debug information for performing stack traces.
  - 2 — produces complete debug information. This is the same as specifying -g with no n.
  - 3 — produces extra information that may be useful for some tools.
- Default: -g or -g2 — the compiler produces complete debug information.
- Description: Option -g tells the compiler to generate symbolic debugging information in the object file, which increases the size of the object file.
- The compiler does not support the generation of debugging information in assemblable files. If you specify this option, the resulting object file will contain debugging information, but the assemblable file will not.
- This option turns off option -O2 and makes option -O0 the default unless option -O2 (or higher) is explicitly specified in the same command line.
- Specifying the -g or -O0 option sets the -fno-omit-frame-pointer option.
- Linux: For C++, the -debug inline-debug-info option will be enabled by default if you compile with optimizations (option -O2 or higher) and debugging is enabled with option -g.
- NOTE: When option -g is specified, debugging information is generated in the DWARF Version 4 format. Older versions of some analysis tools may require applications to be built with the -gdwarf-2 option to ensure correct operation.
- Alternate Options:
  - Linux: None
  - Windows: /Zi, /Z7, /ZI
--gcc-toolchain=dir (L*X only) — lets you specify the location of the base toolchain. Toolchain location, unlocked. 🧚
- Arguments: dir — is the location of the base toolchain.
- Default: OFF — the compiler uses heuristics to locate the base toolchain.
- Description: This option lets you specify the location of the base toolchain.
- NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None
-gdwarf-n (L*X only) — lets you specify a DWARF Version format when generating debug information. 🌈
- Arguments: n — is a value denoting the DWARF Version format to use. Possible values are:

2 — generates debug information using the DWARF Version 2 format. 🎀

3 — generates debug information using the DWARF Version 3 format. 🎀

4 — generates debug information using the DWARF Version 4 format. 🎀

5 — generates debug information using the DWARF Version 5 format. 🎀

Default:

OFF — no debug information is generated. Except bestie, plot twist: if compiler option -g is specified, debugging information is generated in the DWARF Version 4 format. 🙈

Description:

This option lets you specify a DWARF Version format when generating debug information. iconic behavior honestly.

Heads up though: older versions of some analysis tools may require applications to be built with the -gdwarf-2 option to ensure correct operation. like, they're vintage, let them have it 💅

Alternate Options:

None

-grecord-gcc-switches (L*X only) — causes the command line options that were used to invoke the compiler to be appended to the DW_AT_producer attribute in DWARF debugging information. 🦋

Arguments:

None

Default:

OFF — the command line options that were used to invoke the compiler are not appended to the DW_AT_producer attribute in DWARF debugging information.

Description:

This option causes the command line options that were used to invoke the compiler to be appended to the DW_AT_producer attribute in DWARF debugging information.

The options are concatenated with whitespace separating them from each other and from the compiler version. cute little receipt of exactly how this thing got built ✨

Alternate Options:

None

-gsplit-dwarf (L*X only) — creates a separate object file containing DWARF debug information. no cap, it just splits it off 🌸

Arguments:

None

Default:

OFF — no separate object file containing DWARF debug information is created.

Description:

This option creates a separate object file containing DWARF debug information. It causes debug information to be split between the generated object (.o) file and the new DWARF object (.dwo) file. 💫

The DWARF object file is not used by the linker, so this reduces the amount of debug information the linker must process and it results in a smaller executable file. smaller exe = self-care, periodt.

For this option to perform correctly, you must use binutils-2.24 or higher. To debug the resulting executable, you must use gdb-7.6.1 or higher. 🔥 read that again bestie, it's a whole requirement, not a suggestion.

NOTE: if you use the split executable with a tool that does not support the split DWARF format, it will behave as though the DWARF debug information is absent. like the info's just gone, vibe check failed 💀

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 💅

Alternate Options:

None

-H (L*X only) — tells the compiler to display the include file order and continue compilation. she shows her work and keeps going 👑

Arguments:

None

Default:

OFF — compilation occurs as usual.

Description:

This option tells the compiler to display the include file order and continue compilation. yes bestie, it keeps compiling after the little flex 🎀

Alternate Options:

None

-help (L*X only) — displays a list of supported compiler options in alphabetical order. alphabetized bestie, she organized 🗂️

Arguments:

None

Default:

OFF — no list is displayed unless this compiler option is specified.

Description:

This option displays a list of supported compiler options in alphabetical order. lowkey the most useful thing when you're lost ngl 🌈

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 💅

Alternate Options:

None

-Idir (L*X only) — specifies an additional directory to search for include files. 🍓

Arguments:

dir — is the additional directory for the search.

Default:

OFF — the default directory is searched for include files.

Description:

This option specifies an additional directory to search for include files. To specify multiple directories on the command line, repeat the include option for each directory. literally just stack 'em, one per directory, no merging 🫶

Alternate Options:

None

-idirafterdir (L*X only) — adds a directory to the second include file search path. she's the understudy, she goes after -I 💜

Arguments:

dir — is the name of the directory to add.

Default:

OFF — include file search paths include certain default directories.

Description:

This option adds a directory to the second include file search path (after -I). the way that ordering MATTERS 😭

Alternate Options:

None

-imacros filename (L*X only) — allows a header to be specified that is included in front of the other headers in the translation unit. front of the line energy 👑✨

Arguments:

filename — name of header file.

Default:

OFF

Description:

Allows a header to be specified that is included in front of the other headers in the translation unit.

Alternate Options:

None

-inline-forceinline (L*X only) — tells the compiler to treat inline routines as forceinline. she's not asking, she's telling 💅

Default:

OFF — the compiler uses default heuristics for inline routine expansion.

Description:

This option tells the compiler to treat inline routines as forceinline. It forces inlining of functions suggested for inlining.

CAUTION: when you use this option to change the meaning of inline to be "forceinline", the compiler will aggressively inline these functions, so it may run out of memory and terminate with an "out of memory" message. 💀 she ate and then literally ran out of room. this is a real risk, not a drill bestie.

Alternate Options:

None

-ipo (L*X only)
-no-ipo (L*X only)

Enables interprocedural optimization between files. 🔥

Arguments:

None

Default:

-no-ipo or /Qipo- — multifile interprocedural optimization is not enabled.

Description:

This option enables interprocedural optimization between files. This is also called multifile interprocedural optimization (multifile IPO) or Whole Program Optimization (WPO). yeah it has three names, main character things ✨

When you specify this option, the compiler performs inline function expansion and other interprocedural optimizations for calls to functions defined in separate files. It then creates one object file. You cannot specify a name for the object file that is created. 🙈 nope, no naming rights, that's not your moment.

Linux

Option -ipo automatically sets option -flto.

Windows

Option /Qipo automatically sets option -fuse-ld=lld.

NOTE: when you specify option [Q]ipo with option [q or Q]opt-report, an optimization report will be generated during the compilation step for each of the files that are compiled, and for the link time compilation.

Files generated during the compilation step are named <file-name>.optrpt. The file generated during the link step is called ipo_out.optprt. 📄 (yes, that's spelled differently, copy it exactly, do not "fix" it bestie, iykyk)

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 💅

Alternate Options:

None

-ipp-link[=lib] (L*X only) — controls whether the compiler links to static or dynamic threaded Intel(R) Integrated Performance Primitives (Intel(R) IPP) runtime libraries. 🎀

Arguments:

lib — specifies the Intel(R) IPP library to use. Possible values are:

static — tells the compiler to link to the set of static runtime libraries.
dynamic — tells the compiler to link to the set of dynamic threaded runtime libraries.

Default:

dynamic — the compiler links to the Intel(R) IPP set of dynamic runtime libraries. However, if Linux* option -static is specified, the compiler links to the set of static runtime libraries.

Description:

This option controls whether the compiler links to static or dynamic threaded Intel(R) Integrated Performance Primitives (Intel(R) IPP) runtime libraries.

To use this option, you must also specify the [Q]ipp option. 🫶 don't forget, she needs her friend.

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 💅

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

-iprefix prefix (L*X only) — lets you indicate the prefix for referencing directories that contain header files. 🌸

Arguments:

prefix — is the prefix to use.

Default:

OFF — no prefix is included.

Description:

Options for indicating the prefix for referencing directories containing header files. Use prefix with option -iwithprefix as a prefix. 🦋

🎀 `-iquote dir` (L*X only)

Adds a directory to the front of the include file search path, but literally only for files that get pulled in with quotes — not the bracket ones. Bestie, quotes only. Respect the distinction. 💅

Arguments:

dir — the name of the directory to add.

Default:

OFF — the compiler does not add a directory to the front of the include file search path.

Description:

Add directory to the front of the include file search path for files included with quotes but not brackets.

Alternate Options:

None

🦋 `-isystemdir` (L*X only)

Specifies a directory to add to the start of the system include path. Like a VIP entrance but for headers. ✨

Arguments:

dir — the directory to add to the system include path.

Default:

OFF — the default system include path is used.

Description:

This option specifies a directory to add to the system include path. The compiler searches the specified directory for include files after it searches all directories specified by the -I compiler option but before it searches the standard system directories.

On Linux* systems, this option is provided for compatibility with gcc.

Alternate Options:

None

🌸 `-iwithprefixdir` (L*X only)

Appends a directory to the prefix that got passed in by -iprefix, then puts it on the include search path at the end of the include directories. It's giving "last but literally on the list". 🫶

Arguments:

dir — the include directory.

Default:

OFF

Description:

This option appends a directory to the prefix passed in by -iprefix and puts it on the include search path at the end of the include directories.

Alternate Options:

None

💜 `-iwithprefixbeforedir` (L*X only)

Same energy as -iwithprefix, except the include directory gets placed in the same place as -I command-line include directories. Not at the back this time — she moved up front. 👑

Arguments:

dir — the include directory.

Default:

OFF

Description:

Similar to -iwithprefix except the include directory is placed in the same place as -I command-line include directories.

Alternate Options:

None

🔥 `-lstring` (L*X only)

Tells the linker to go hunt down a specific library when linking. Scavenger hunt but make it binaries. 💀

Arguments:

string — specifies the library (libstring) that the linker should search.

Default:

OFF — the linker searches for standard libraries in standard directories.

Description:

This option tells the linker to search for a specified library when linking.

When resolving references, the linker normally searches for libraries in several standard directories, in directories specified by the L option, then in the library specified by the l option.

The linker searches and processes libraries and object files in the order they are specified. So, you should specify this option following the last object file it applies to. Order matters, no cap. 🙈

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

🌈 `-Ldir` (L*X only)

Tells the linker to search for libraries in a specified directory before hitting up the standard directories. Cutting the line, respectfully. ✨

Arguments:

dir — the name of the directory to search for libraries.

Default:

OFF — the linker searches the standard directories for libraries.

Description:

This option tells the linker to search for libraries in a specified directory before searching for them in the standard directories.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

🧚 `-mcode` (L*X only)

Tells the compiler which instruction set extensions based on CPUID bits it may generate. She's picking her outfits (instructions) for the night. 💅

Arguments:

code — indicates the instruction set extensions based on CPUID bits that the compiler may generate.

Many of the Clang settings for option -m are supported. For more information on Clang settings for option -m, see the Clang documentation.

Default:

varies — if option arch is not specified, the default target architecture supports Intel(R) SSE2 instructions.

Description:

This option tells the compiler which instruction set extensions based on CPUID bits it may generate.

Code generated with these options should execute on any compatible, non-Intel processor with support for the corresponding instruction set.

NOTE: Options -m and /Qm enable specific sets of instructions based on CPUID bits. If you want to enable all instructions supported by a named microarchitecture, you should use option -march (Linux) or /arch (Windows).

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

🍓 `-M` (L*X only)

Tells the compiler to generate makefile dependency lines for each source file. Makefile girlies, this one's for you. 😭

Arguments:

None

Default:

OFF — the compiler does not generate makefile dependency lines for each source file.

Description:

This option tells the compiler to generate makefile dependency lines for each source file, based on the #include lines found in the source file.

Alternate Options:

None

💀 `-m64` (L*X only)

Tells the compiler to generate code for a specific architecture. It is a legacy option that is deprecated, and it will be removed in a future release. Ok so she's literally retiring, we're just here to witness. 🙈

Arguments:

None

Default:

-m64 — the compiler generates code for Intel(R) 64 architecture. The compiler does this whether or not this option is specified.

Description:

These options currently are legacy options, which will be removed in a future release. They do nothing.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

⭐ `-m80387` (L*X only)

⭐ `-mno-80387` (L*X only)

Specifies whether the compiler can use x87 instructions. Yes or no, bestie — pick a lane. 🦋

Arguments:

None

Default:

-m80387 — the compiler may use x87 instructions.

Description:

This option specifies whether the compiler can use x87 instructions.

If you specify option -mno-80387, it prevents the compiler from using x87 instructions. If the compiler is forced to generate x87 instructions, it issues an error message.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

-m[no-]x87

👑 `-march=processor` (L*X only)

Tells the compiler to generate code using the CPU feature set of a specific processor as the baseline. It's giving "dress for the architecture you want, not the one you have". 🔥

Arguments:

processor — tells the compiler which CPU features it can use. Possible values are:
- nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, gracemont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, common-avx512, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, rocketlake, icelake-server, tigerlake, sapphirerapids, alderlake, raptorlake, meteorlake, sierraforest, grandridge, graniterapids, emeraldrapids — generates code using the CPU feature set of the specified Intel(R) processor or microarchitecture code name.
- x86-64 — generates code for a generic CPU with 64-bit extensions.
- x86-64-v2 — generates code for Intel(R) SSE4.3, SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3.
- x86-64-v3 — generates code for Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2), Intel(R) AVX, Intel(R) SSE4.3, SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3.

`x86-64-v4` 💅

Okay so this -march value is giving full AVX-512 energy, no cap. It generates code for Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512) Foundation instructions, Intel(R) AVX-512 Conflict Detection Instructions (CDI), Intel(R) AVX-512 Doubleword and Quadword Instructions (DQI), Intel(R) AVX-512 Byte and Word Instructions (BWI) and Intel(R) AVX-512 Vector Length Extensions (VLE). ✨

Default:

OFF — if option -march is not specified, the compiler may generate Intel(R) SSE2 and SSE instructions.

Description:

This option tells the compiler to generate code using the CPU feature set of a specific processor as the baseline.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 🫶

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

`-masm=dialect` (L*X only) 🎀

Tells the compiler to generate the assembler output file using a selected dialect. Basically: pick your assembly flavor, bestie. 🍓

Arguments:

dialect — is the dialect to use for the assembler output file. Possible values are:
- att — tells the compiler to generate the assembler output file using AT&T* syntax.
- intel — tells the compiler to generate the assembler output file using Intel syntax.

Default:

-masm=att — the compiler generates the assembler output file using AT&T* syntax.

Description:

This option tells the compiler to generate the assembler output file using a selected dialect.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 💖

Alternate Options:

None

`-mauto-arch=value` (L*X only) 🦋

Tells the compiler to generate multiple, feature-specific auto-dispatch code paths for x86 architecture processors if there is a performance benefit. It's giving "one binary, many vibes." 👑

Arguments:

value — is any setting you can specify for option [Q]ax.

Default:

OFF — no additional execution path is generated.

Description:

This option tells the compiler to generate multiple, feature-specific auto-dispatch code paths for x86 architecture processors if there is a performance benefit. It also generates a baseline code path.

This option cannot be used together with any options that may require Intel-specific optimizations (such as [Q]x or [Q]ax).

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 🌸

Alternate Options:

None

`-mbranches-within-32B-boundaries` (LX only) + `-mno-branches-within-32B-boundaries` (LX only) 🔥

Tells the compiler to align branches and fused branches on 32-byte boundaries for better performance. Fancy alignment moment, fr fr. ✨

Arguments:

None

Default:

-mno-branches-within-32B-boundaries — branches and fused branches are not aligned on 32-byte boundaries.

Description:

This option tells the compiler to align branches and fused branches on 32-byte boundaries for better performance.

NOTE: When you use this option, it may affect binary utilities usage experience, such as debugability. 😭

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 💜

Alternate Options:

None

`-mcmodel=mem_model` (L*X only) 🌈

Tells the compiler to use a specific memory model to generate code and store data. Memory model era, bestie. 🎀

Arguments:

mem_model — is the memory model to use. Possible values are:
- small — tells the compiler to restrict code and data to the first 2GB of address space. All accesses of code and data can be done with Instruction Pointer (IP)-relative addressing.
- medium — tells the compiler to restrict code to the first 2GB; it places no memory restriction on data. Accesses of code can be done with IP-relative addressing, but accesses of data must be done with absolute addressing.
- large — places no memory restriction on code or data. All accesses of code and data must be done with absolute addressing.

Default:

-mcmodel=small — on systems using Intel(R) 64 architecture, the compiler restricts code and data to the first 2GB of address space. Instruction Pointer (IP)-relative addressing can be used to access code and data.

Description:

This option tells the compiler to use a specific memory model to generate code and store data. It can affect code size and performance. If your program has global and static data with a total size smaller than 2GB, -mcmodel=small is sufficient. Global and static data larger than 2GB requires -mcmodel=medium or -mcmodel=large. Allocation of memory larger than 2GB can be done with any setting of -mcmodel.

IP-relative addressing requires only 32 bits, whereas absolute addressing requires 64-bits. IP-relative addressing is somewhat faster. So, the small memory model has the least impact on performance.

NOTE: This content does not apply to SYCL. 🫶

When you specify option -mcmodel=medium or -mcmodel=large, it sets option -shared-intel. This ensures that the correct dynamic versions of the Intel runtime libraries are used.

If you specify option -static-intel while -mcmodel=medium or -mcmodel=large is set, an error will be displayed.

Alternate Options:

None

`-MD` (L*X only) 🧚

Preprocess and compile, generating output file containing dependency information ending with extension .d. Dependency-info slay. 💅

Arguments:

None

Default:

OFF — the compiler does not generate dependency information.

Description:

Preprocess and compile, generating output file containing dependency information ending with extension .d.

Alternate Options:

None

`-MFfilename` (L*X only) 🍓

Tells the compiler to generate makefile dependency information in a file. Put the makefile dependency lore in a specific file, iykyk. 📁

Arguments:

filename — is the name of the file where the makefile dependency information should be placed.

Default:

OFF — the compiler does not generate makefile dependency information in files.

Description:

This option tells the compiler to generate makefile dependency information in a file. To use this option, you must also specify /QM or /QMM.

Alternate Options:

None

`-MG` (L*X only) 👑

Tells the compiler to generate makefile dependency lines for each source file. It is similar to /QM, but it treats missing header files as generated files. No cap, it's giving "makefile dependency lines for every source file." 🌟

Arguments:

None

Default:

OFF — the compiler does not generate makefile dependency information in files.

Description:

This option tells the compiler to generate makefile dependency lines for each source file. It is similar to /QM, but it treats missing header files as generated files.

Alternate Options:

None

`-mintrinsic-promote` (L*X only) 💀

Enables functions containing calls to intrinsics that require a specific CPU feature to have their target architecture automatically promoted to allow the required feature. It's literally auto-promoting the target architecture so the intrinsic can exist. ✨

Arguments:

None

Default:

OFF — if this option is not specified and you call an intrinsic that requires a CPU feature not provided by the specified (or default) target processor, an error will be reported.

Description:

This option enables functions containing calls to intrinsics that require a specific CPU feature to have their target architecture automatically promoted to allow the required feature.

All code within the function will be compiled with that target architecture, and the resulting code for such functions will not execute correctly on processors that do not support the required feature.

WARNING: You are responsible for guarding the execution path at runtime so that such functions are not dynamically reachable when the program is run on processors that do not support the required feature. Like, actually responsible. 😭

Alternate Options:

None

💡 NOTE: We recommend that you use __attribute__((target(<required target>))) to mark functions that are intended to be executed on specific target architectures instead of using this option. This attribute will provide significantly better compile time error checking.

💡 NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None — okay bestie, that one’s wrapped, and we’re sliding right into the next options. 💅

-MM (L*X only) — tells the compiler to generate makefile dependency lines for each source file.
- Arguments: None
- Default: OFF — the compiler does not generate makefile dependency information in files.
- Description: This option tells the compiler to generate makefile dependency lines for each source file. It is similar to /QM, but it does not include system header files.
- Alternate Options: None
-MMD (L*X only) — tells the compiler to generate an output file containing dependency information.
- Arguments: None
- Default: OFF — the compiler does not generate an output file containing dependency information.
- Description: This option tells the compiler to preprocess and compile a file, then generate an output file (with extension information. It is similar to /QMD, but it does not include system header files.
- Alternate Options: None
-mno-gather (L*X only) — disables the generation of gather instructions in auto-vectorization.
- Arguments: None
- Default: OFF — gather instructions are enabled in auto-vectorization.
- Description: This option disables the generation of gather instructions in auto-vectorization.
- NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None
-mno-scatter (L*X only) — disables the generation of scatter instructions in auto-vectorization.
- Arguments: None
- Default: OFF — scatter instructions are enabled in auto-vectorization.
- Description: This option disables the generation of scatter instructions in auto-vectorization.
- NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None
-momit-leaf-frame-pointer (L*X only) and -mno-omit-leaf-frame-pointer (L*X only) — determine whether the frame pointer is omitted or kept in leaf functions.
- Arguments: None
- Default: Varies — if you specify option -fomit-frame-pointer (or it is set by default), the default is -momit-leaf-frame-pointer. If you specify option -fno-omit-frame-pointer, the default is -mno-omit-leaf-frame-pointer.
- Description: This option determines whether the frame pointer is omitted or kept in leaf functions. It is related to option -f[no-]omit-frame-pointer and the setting for that option has an effect on this option.
- Consider the following option combinations:
  - -fomit-frame-pointer -momit-leaf-frame-pointer or -fomit-frame-pointer -mno-omit-leaf-frame-pointer — both combinations are the same as specifying -fomit-frame-pointer. Frame pointers are omitted for all routines.
  - -fno-omit-frame-pointer -momit-leaf-frame-pointer — in this case, the frame pointer is omitted for leaf routines, but other routines will keep the frame pointer. This is the intended effect of option -momit-leaf-frame-pointer.
  - -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer — in this case, -mno-omit-leaf-frame-pointer is ignored since -fno-omit-frame-pointer retains frame pointers in all routines. This combination is the same as specifying -fno-omit-frame-pointer.
- This option is provided for compatibility with gcc.
- NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None
-MQtarget (L*X only) — changes the default target rule for dependency generation.
- Arguments: target — is the target rule to use.
- Default: OFF — the default target rule applies to dependency generation.
- Description: This option changes the default target rule for dependency generation. It is similar to -MT (and /QMT), but quotes special Make characters.
- Alternate Options: None
-MTtarget (L*X only) — changes the default target rule for dependency generation.
- Arguments: target — is the target rule to use.
- Default: OFF — the default target rule applies to dependency generation.
- Description: This option changes the default target rule for dependency generation.
- Alternate Options: None
-mtune=processor (L*X only) — performs optimizations for specific processors but does not cause extended instruction sets to be used (unlike -march).
- Arguments: processor — is the processor for which the compiler should perform optimizations. Possible values are:
  - generic — optimizes code for the compiler’s default behavior.
  - alderlake broadwell cannonlake cascadelake cooperlake goldmont goldmont-plus haswell icelake-server ivybridge rocketlake sandybridge sapphirerapids silvermont skylake skylake-avx512 tigerlake tremont — optimizes code for processors that support the specified Intel(R) processor or microarchitecture code name.
  - core-avx2 — optimizes code for processors that support Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2), Intel(R) AVX, SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions.
  - core-avx-i — optimizes code for processors that support Float-16 conversion instructions and the RDRND instruction, Intel(R) Advanced Vector Extensions (Intel(R) AVX), Intel(R) SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions.
  - corei7-avx — optimizes code for processors that support Intel(R) Advanced Vector Extensions (Intel(R) AVX), Intel(R) SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions.
  - corei7 — optimizes code for processors that support Intel(R) SSE4 Efficient Accelerated String and Text Processing instructions. May also generate code for Intel(R) SSE4 Vectorizing Compiler and Media Accelerator, Intel(R) SSE3, SSE2, SSE, and SSSE3 instructions.
  - atom — optimizes code for processors that support MOVBE instructions. May also generate code for SSSE3 instructions and Intel(R) SSE3, SSE2, and SSE instructions.
  - core2 — optimizes for the Intel(R) Core(TM)2 processor family, including support for MMX(TM), Intel(R) SSE, SSE2, SSE3, and SSSE3 instruction sets.
- Default: generic — code is generated for the compiler’s default behavior.
- Description: This option performs optimizations for specific processors but does not cause extended instruction sets to be used (unlike -march). The resulting executable is backwards compatible and generated code is optimized for specific processors. For example, code generated with -mtune=core2 or /tune:core2 runs correctly on 4th Generation Intel(R) Core(TM) processors, but it might not run as fast as if it had been generated using -mtune=haswell or /tune:haswell.
- Alternate Options: None

...and honestly? that's the iconic part. Code you generate with -mtune=haswell (/tune:haswell) or -mtune=core-avx2 (/tune:core-avx2) will also run correctly on Intel(R) Core(TM)2 processors, bestie — it just might not run as fast as if it had been generated using -mtune=core2 or /tune:core2. 💅

And that is so in contrast to code generated with -march=core-avx2, which will not run correctly on older processors such as Intel(R) Core(TM)2 processors. like, not even a little. 💀

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 🫶

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at

                  www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

-nodefaultlibs (L*X only) — Prevents the compiler from using standard libraries when linking.

Arguments:

None

Default:

OFF — The standard libraries are linked.

Description:

This option prevents the compiler from using standard libraries when linking.

On Linux* systems, this option is provided for GNU compatibility.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 🫶

Alternate Options:

None

-no-intel-lib[=library] (L*X only) — Disables linking to specified Intel(R) libraries, or to all Intel(R) libraries.

Arguments:

library — Indicates which Intel(R) library should not be linked. Possible values are:

libirc — Disables linking to the Intel(R) C/C++ library.
libimf — Disables linking to the Intel(R) oneAPI DPC++/C++ Compiler Math library.
libm — This setting is only available on Windows. It is equivalent to specifying libimf.
libsvml — Disables linking to the Intel(R) Short Vector Math library.
libirng — Disables linking to the Random Number Generator library.

If you specify more than one library, they must be separated by commas.

If library is omitted, the compiler will not link to any of the Intel(R) libraries shown above. 🙈

Default:

OFF — If this option is not specified, the compiler uses default heuristics for linking to libraries.

Description:

This option disables linking to specified Intel(R) libraries, or to all Intel(R) libraries.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 🫶

Alternate Options:

None

-nolib-inline (L*X only) — Disables inline expansion of standard library or intrinsic functions.

Arguments:

None

Default:

OFF — The compiler inlines many standard library and intrinsic functions.

Description:

This option disables inline expansion of standard library or intrinsic functions. It prevents the unexpected results that can arise from inline expansion of these functions. 😭 (like, no more surprise plot twists, ok?)

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 🫶

Alternate Options:

None

-nolibsycl (L*X only) — Disables linking of the SYCL* runtime library.

Arguments:

None

Default:

OFF — The SYCL* runtime library is linked.

Description:

This option disables linking of the SYCL* runtime library.

When using the icx/icpx compiler driver, this option is only effective if you have specified option -fsycl. 🔥

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 🫶

Alternate Options:

None

-nostartfiles (L*X only) — Prevents the compiler from using standard startup files when linking.

Arguments:

None

Default:

OFF — The compiler uses standard startup files when linking.

Description:

This option prevents the compiler from using standard startup files when linking.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 🫶

Alternate Options:

None

-nostdinc++ (L*X only) — Do not search for header files in the standard directories for C++, but search the other standard directories.

Arguments:

None

Default:

OFF

Description:

Do not search for header files in the standard directories for C++, but search the other standard directories. 🎀

Alternate Options:

None

-nostdlib (L*X only) — Prevents the compiler from using standard libraries and startup files when linking.

Arguments:

None

Default:

OFF — The compiler uses standard startup files and standard libraries when linking.

Description:

This option prevents the compiler from using standard libraries and startup files when linking.

This option is provided for GNU compatibility.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 🫶

Alternate Options:

None

-o filename (L*X only) — Specifies the name for an output file.

Arguments:

filename — Is the name for the output file. The space before filename is optional. (yes bestie, you can vibe without the space 💅)

Default:

OFF — The compiler uses the default file name for an output file.

Description:

This option specifies the name for an output file as follows:

If -c is specified, it specifies the name of the generated object file.
If -S is specified, it specifies the name of the generated assembly listing file.
If -P is specified, it specifies the name of the generated preprocessor file.

Otherwise, it specifies the name of the executable file.

Alternate Options:

Linux: None

Windows: /Fe

-O[n] (L*X only) — Specifies the code optimization for applications. ⭐

Arguments:

n — Is the optimization level. Possible values are 1, 2, or 3. On Linux* systems, you can also specify 0.

Default:

O2 — Optimizes for code speed.

However, on Linux* systems, if option -g is specified, the default is -O0 unless option -O2 (or higher) is also explicitly specified in the command line. 👀

Description:

This option specifies the code optimization for applications.

O (Linux*) — This is the same as specifying O2.
O0 (Linux) — Disables all optimizations.

This option may set other options. This is determined by the compiler, depending on which operating system and architecture you are using. The options that are set may change from release to release. 🦋

O1 — Enables optimizations for speed and disables some optimizations that increase code size and affect speed.

To limit code size, this option disables optimizations that may duplicate code, such as automatic function inlining, loop unrolling, and function cloning.

This option may set other options. This is determined by the compiler, depending on which operating system and architecture you are using. The options that are set may change from release to release.

The O1 option may improve performance for applications with very large code size, many branches, and execution time not dominated by code within loops.

O2 — Enables optimizations for speed. This is the generally recommended optimization level. Vectorization is enabled at O2 and higher levels. 👑

This option also enables:

Inlining of intrinsics
Intra-file interprocedural optimization, which includes:
- inlining
- constant propagation
- forward substitution
- routine attribute propagation
- variable address-taken analysis
- dead static function elimination
- removal of unreferenced variables
The following capabilities for performance gain:
- constant propagation
- copy propagation
- dead-code elimination

global register allocation
global instruction scheduling and control speculation
loop unrolling
optimized code selection
partial redundancy elimination
strength reduction/induction variable simplification
variable renaming
exception handling optimizations
tail recursions
peephole optimizations
structure assignment lowering and optimizations
dead store elimination

okay so this option may set other options, especially options that optimize for code speed. This is determined by the compiler, depending on which operating system and architecture you are using. The options that are set may change from release to release.

This content does not apply to SYCL. On Linux systems, the -debug inline-debug-info option will be enabled by default if you compile with optimizations (option -O2 or higher) and debugging is enabled (option -g).

Many routines in the shared libraries are more highly optimized for Intel(R) microprocessors than for non-Intel microprocessors.

NOTE: On Windows, the Microsoft Visual Studio C++ compiler currently supports option /O2 as the highest optimization level. The Intel compilers support additional optimizations under the /O3 option, which is described below.

🔥 `O3`

Performs O2 optimizations and enables more aggressive loop transformations such as Fusion, Block-Unroll-and-Jam, and collapsing IF statements.

This option may set other options. This is determined by the compiler, depending on which operating system and architecture you are using. The options that are set may change from release to release.

The O3 optimizations may not cause higher performance unless loop and memory access transformations take place. The optimizations may slow down code in some cases compared to O2 optimizations.

The O3 option is recommended for applications that have loops that heavily use floating-point calculations and process large data sets.

Many routines in the shared libraries are more highly optimized for Intel(R) microprocessors than for non-Intel microprocessors.

The last O option specified on the command line takes precedence over any others.

Alternate Options:

O0 — Linux: None; Windows: /Od

🦋 `-Ofast` (L*X only)

Sets certain aggressive options to improve the speed of your application.

Arguments: None

Default: OFF — The aggressive optimizations that improve speed are not enabled.

Description: This option improves the speed of your application.

This option is provided for compatibility with gcc.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

🌸 `-Os` (L*X only)

Enables optimizations that do not increase code size; it produces smaller code size than O2.

Arguments: None

Default: OFF — Optimizations are made for code speed. However, if O1 is specified, Os is the default.

Description: This option enables optimizations that do not increase code size; it produces smaller code size than O2. It disables some optimizations that increase code size for a small speed benefit.

This option tells the compiler to favor transformations that reduce code size over transformations that produce maximum performance.

Alternate Options: None

🎀 `-P` (L*X only)

Tells the compiler to stop the compilation process and write the results to a file.

Arguments: None

Default: OFF — Normal compilation is performed.

Description: This option tells the compiler to stop the compilation process after C or C++ source files have been preprocessed and write the results to files named according to the compiler's default file-naming conventions.

On Linux systems, this option causes the preprocessor to expand your source module and direct the output to a stdout. Unlike the -E option, the output from -P on Linux does not include #line number directives. By default, the preprocessor creates the name of the output file using the prefix of the source file name with a by using the -o option.

Alternate Options:

Linux: -F
Windows: None

💅 `-pcn` (L*X only)

Enables control of floating-point significand precision.

Arguments:

n — Is the floating-point significand precision. Possible values are:
- 32 — Rounds the significand to 24 bits (single precision).
- 64 — Rounds the significand to 53 bits (double precision).
- 80 — Rounds the significand to 64 bits (extended precision).

Default: -pc80 — On Linux* systems, the floating-point significand is rounded to 64 bits.

Description: This option enables control of floating-point significand precision.

Some floating-point algorithms are sensitive to the accuracy of the significand, or fractional part of the floating-point value. For example, iterative operations like division and finding the square root can run faster if you lower the precision with this option.

Note that a change of the default precision control or rounding mode, for example, by using the [Q]pc32 option or by user intervention, may affect the results returned by some of the mathematical functions.

Alternate Options: None

🌈 `-pie` (LX only) / `-no-pie` (LX only)

Determines whether the compiler generates position-independent code that will be linked into an executable.

Arguments: None

Default: -no-pie — The compiler does not generate position-independent code that will be linked into an executable.

Description: This option determines whether the compiler generates position-independent code that will be linked into an executable. To enable generation of position-independent code that will be linked into an executable, specify -pie.

To disable generation of position-independent code that will be linked into an executable, specify -no-pie.

Alternate Options: None

🧚 `-pthread` (L*X only)

Tells the compiler to use the pthread library for multithreading support.

Arguments: None

Default: OFF — The compiler does not use the pthread library for multithreading support.

Description: Tells the compiler to use pthread library for multithreading support. This option can also be spelled as -pthreads.

Linking in with the pthread library is also set by the following options:

-fiopenmp (for OpenMP)
-qmkl
-debug=parallel
-fortlib

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

👑 `-qactypes` (LX only) / `-qno-actypes` (LX only)

Determines whether the compiler includes the Algorithmic C (AC) data type folder for header searches and links to the AC data types libraries for Field Programmable Gate Array (FPGA) and CPU compilations.

Arguments: None

Default: OFF — The compiler does not search the Algorithmic C (AC) data type folders for headers and doesn’t link to AC data type libraries for FPGA and CPU compilations. As a result, AC data types cannot be used in the source program.

Description: This option determines whether the compiler includes the Algorithmic C (AC) data type folder when searching for headers, and links to the AC data types libraries for Field Programmable Gate Array (FPGA) and CPU compilations.

AC data types provide support for arbitrary precision integers, fixed precision integers and arbitrary precision floating-point data types. They are built on top of the _ExtInt extended-integer type class.

When you specify option [q or Q]actypes, dynamic linking is the default. You cannot link to the AC data type libraries statically.

When option -fintelfpga is used on the command line, option [q or Q]actypes is enabled by default. To override this, specify option -qno-actypes or /Qactypes-, which disables compile and link support for the Algorithmic C data types.

🐧 Linux

…and on Linux the driver has to be handed those library names explicitly on the link command. You gotta use option -qactypes to actually do the link and pull in those dependent libraries. 💅

Windows

Over here it's a whole different vibe — this option just drops directives into the compiled code, and the linker reads them with zero further input from the driver. No separate link command needed, bestie. ✨

NOTE: this option may impact target compilations, because of the way it enables headers and libraries. So like… be aware. 😭

Alternate Options:

None

`-qdaal[=lib]` (L*X only)

Tells the compiler to link to certain libraries in the Intel(R) oneAPI Data Analytics Library (oneDAL). Honestly? A slay. 🧚

Arguments:

lib — tells it which oneDAL library files should get linked. The possible values are:
- parallel — link using the threaded oneDAL libraries. This is the default if the option is specified with no lib.
- sequential — link using the non-threaded oneDAL libraries.

Default:

OFF — the compiler does not link to the oneDAL.

Description:

This option tells the compiler to link to certain libraries in the Intel(R) oneAPI Data Analytics Library (oneDAL).

On Linux* systems, the associated oneDAL headers are included when you specify this option. 🎀

NOTE: on Windows* systems, this option adds directives to the compiled code, which the linker then reads without further input from the driver. You do not need to specify a separate link command.

On Linux* systems, the driver must add the library names explicitly to the link command. You must use option -qdaal to perform the link to pull in the dependent libraries.

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

Linux: -daal (this is a deprecated option — yes, legacy, tread carefully 💀)

`-qipp[=lib]` (L*X only)

Tells the compiler to link to some or all of the Intel(R) Integrated Performance Primitives (Intel(R) IPP) libraries. Iconic behaviour, no cap. 👑

Arguments:

lib — indicates the Intel(R) IPP libraries the compiler should link to. The possible values are:
- common — link using the main libraries set. This is the default if the option is specified with no lib.
- crypto — link using the Intel(R) Cryptography Primitives Library.
- nonpic — (Linux* only) link using the version of the libraries that do not have position-independent code.
- nonpic_crypto — (Linux only) link using the Intel(R) Cryptography Primitives Library. It uses the version of the libraries that do not have position-independent code.

Default:

OFF — the compiler does not link to the Intel(R) IPP libraries.

Description:

The option tells the compiler to link to some or all of the Intel(R) IPP libraries and include the Intel(R) IPP headers. 🦋

The [Q]ipp-link option controls whether the compiler links to static, dynamic threaded, or static threaded Intel(R) IPP runtime libraries.

NOTE: on Windows* systems, this option adds directives to the compiled code, which the linker then reads without further input from the driver. You do not need to specify a separate link command.

On Linux* systems, the driver must add the library names explicitly to the link command. You must use option qipp to perform the link to pull in the dependent libraries.

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

`-qmkl[=lib]` (L*X only)

Tells the compiler to link to certain libraries in the Intel(R) oneAPI Math Kernel Library (oneMKL). On Windows systems, you must specify this option at compile time. ⭐

Arguments:

lib — indicates which oneMKL library files should be linked. The possible values are:
- parallel — link using the threaded libraries in oneMKL. This is the default if the option is specified with no lib.
- sequential — link using the sequential libraries in oneMKL.
- cluster — link using the cluster-specific libraries and the sequential libraries in oneMKL.

Default:

OFF — the compiler does not link to the oneMKL library.

Description:

This option tells the compiler to link to certain libraries in the Intel(R) oneAPI Math Kernel Library (oneMKL).

On Linux* systems, dynamic linking is the default when you specify -qmkl. To link with oneMKL statically, you must specify:

-qmkl -static-intel

On Windows* systems, static linking is the default when you specify /Qmkl. To link with oneMKL dynamically, you must specify:

/Qmkl /MD

If both option -qmkl (or /Qmkl) and -qmkl-ilp64 (or /Qmkl-ilp64) are specified on the command line, the rightmost specified option takes precedence. (Rightmost wins. Periodt. 💅)

For more information about using oneMKL libraries, see the article titled: Intel(R) oneAPI Math Kernel Library Link Line Advisor.

NOTE: if you specify options [q or Q]mkl and -fsycl on the command line, you link to the combined oneMKL* SYCL library.

To link to a specific oneMKL SYCL library, specify options [q or Q]mkl, -fsycl, and [q or Q]mkl-sycl-impl.

NOTE: on Windows* systems, this option adds directives to the compiled code, which the linker then reads without further input from the driver. You do not need to specify a separate link command.

On Linux* systems, the driver must add the library names explicitly to the link command. You must use option -qmkl to perform the link to pull in the dependent libraries.

NOTE: if you specify option [q or Q]mkl, or [q or Q]qmkl=parallel, and you also specify option [Q]tbb, the compiler links to the standard threaded version of oneMKL. However, if you specify [q or Q]mkl, or [q or Q]qmkl=parallel, and you also specify option [Q]tbb and option [q or Q]openmp, the compiler links to the OpenMP* threaded version of oneMKL. Big difference, iykyk. 🔥

Alternate Options:

None

`-qmkl-ilp64[=lib]` (L*X only)

Tells the compiler to link to the ILP64-specific version of the Intel(R) oneAPI Math Kernel Library (oneMKL). On Windows systems, you must specify this option at compile time. 🌸

Arguments:

lib — indicates which ILP64-specific oneMKL library files should be linked. The possible values are:
- parallel — link using the threaded libraries in oneMKL. This is the default if the option is specified with no lib.
- sequential — link using the sequential libraries in oneMKL.
- cluster — link using the cluster-specific libraries and the sequential libraries in oneMKL.

Default:

OFF — the compiler does not link to the oneMKL library.

Description:

This option tells the compiler to link to the ILP64-specific version of the Intel(R) oneAPI Math Kernel Library (oneMKL).

If both option -qmkl-ilp64 (or /Qmkl-ilp64) and -qmkl (or /Qmkl) are specified on the command line, the rightmost specified option takes precedence. Again: rightmost. Always rightmost. 👑

For more information about using oneMKL libraries, see the article titled: Intel(R) oneAPI Math Kernel Library Link Line Advisor.

Linux

Dynamic linking is the default when you specify -qmkl-ilp64. To link with oneMKL statically, you must specify:

-qmkl-ilp64 -static-intel

The driver must add the library names explicitly to the link command. You must use option -qmkl-ilp64 to perform the link to pull in the dependent libraries.

Windows

Static linking is the default when you specify /Qmkl-ilp64. Wanna link with oneMKL dynamically instead? Then you gotta say:

/Qmkl-ilp64 /MD

This option drops directives into the compiled code, and the linker just reads them, no extra input from the driver needed. You do not have to specify a separate link command. Slay, honestly. 💅

Alternate Options:

None

-qmkl-sycl-impl=arg[,arg,...] (L*X only) — lets you link to one or more specific Intel® oneAPI Math Kernel Library (oneMKL) SYCL libraries. Obsessed with the granularity here. 🦋

Arguments:

arg — tells the compiler which oneMKL SYCL-specific library to link to. Possible values are:
- blas — links to the BLAS SYCL library.
- dft — links to the Discrete Fourier Transform (DFT) SYCL library.
- lapack — links to the LAPACK SYCL library.
- rng — links to the Random Number Generator (RNG) SYCL library.
- sparse — links to the Sparse BLAS SYCL library.
- stats — links to the Summary Statistic SYCL library.
- vm — links to the Vector Mathematics (VM) SYCL library.

Default:

OFF — you must specify this option to link to a specific oneMKL SYCL library.

Description:

So this option is literally your way to link to one or more specific oneMKL SYCL libraries. ✨

Heads up though: it is not supported for static linking.

NOTE: When using this option, you must also specify option -fsycl and -qmkl (Linux) or /Qmkl (Windows). No skipping, bestie. 🫶

Alternate Options:

None

-qopenmp (L*X only)
-qno-openmp (L*X only) — enables recognition of OpenMP* features, like parallel, simd, and offloading directives, and tells the parallelizer to generate multi-threaded code based on OpenMP* directives. It's an alternate name for compiler option -fiopenmp (and /Qiopenmp). Iconic behavior, fr fr. 🌈

Arguments:

None

Default:

-qno-openmp — no OpenMP* multi-threaded code is generated by the compiler.

Description:

This one enables recognition of OpenMP* features and tells the parallelizer to generate multi-threaded code based on OpenMP* directives. The code can run in parallel on both uniprocessor and multiprocessor systems. 👑

It works with any optimization level. Specifying no optimization (-O0 on Linux* or /Od on Windows*) helps to debug OpenMP applications.

Options -fiopenmp (and /Qiopenmp) are alternate names for options -qopenmp (and /Qopenmp).

NOTE: To enable offloading to a specified GPU target, you must also specify option -fopenmp-targets (Linux*) or /Qopenmp-targets (Windows).

NOTE: Options that use OpenMP* API are available for both Intel® microprocessors and non-Intel microprocessors, but these options may perform additional optimizations on Intel® microprocessors than they perform on non-Intel microprocessors.

The list of major, user-visible OpenMP constructs and features that may perform differently on Intel® microprocessors versus non-Intel microprocessors includes: locks (internal and user visible), the SINGLE construct, barriers (explicit and implicit), parallel loop scheduling, reductions, memory allocation, thread affinity, and binding. That's a whole vibe check right there. 💀

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

Linux: -fiopenmp
Windows: /Qiopenmp

-qopenmp-link=library (L*X only) — controls whether the compiler links to static or dynamic OpenMP* runtime libraries. Big decision energy. 🎀

Arguments:

library — specifies the OpenMP library to use. Possible values are:
- static — tells the compiler to link to static OpenMP runtime libraries. Note that static OpenMP libraries are deprecated. 👀
- dynamic — tells the compiler to link to dynamic OpenMP runtime libraries.

Default:

-qopenmp-link=dynamic — the compiler links to dynamic OpenMP* runtime libraries. However, if Linux* option -static is specified, the compiler links to static OpenMP runtime libraries.

Description:

This option controls whether the compiler links to static or dynamic OpenMP* runtime libraries.

To link to the static OpenMP runtime library (RTL) and create a purely static executable, you must specify -qopenmp-link=static. But we strongly recommend you use the default setting, -qopenmp-link=dynamic. Trust. 🙏

Option -qopenmp-link=dynamic cannot be used in conjunction with option -static. If you try to specify both options together, an error will be displayed. No cap, it will simply not let you. 😭

NOTE: Compiler options -static-intel and -shared-intel (Linux*) have no effect on which OpenMP runtime library is linked.

NOTE: On Linux systems, the OpenMP runtime library depends on using libpthread and libc (libgcc when compiled with gcc). Libpthread and libc (libgcc) must both be static or both be dynamic.

If both libpthread and libc (libgcc) are static, then the static version of the OpenMP runtime should be used. If both libpthread and libc (libgcc) are dynamic, then either the static or dynamic version of the OpenMP time may be used.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

-qopenmp-simd (L*X only)
-qno-openmp-simd (L*X only) — enables or disables OpenMP* SIMD compilation. Little toggle, big power. ⚡

Arguments:

None

Default:

-qno-openmp-simd — OpenMP* SIMD compilation is disabled.

Description:

This option enables or disables OpenMP* SIMD compilation.

You can use this option if you want to enable or disable the SIMD support with no impact on other OpenMP features. In this case, no OpenMP runtime library is needed to link and the compiler does not need to generate OpenMP runtime initialization code. Clean. ✨

When you specify [q or Q]openmp, it implies [q or Q]openmp-simd.

If you specify this option with the [q or Q]openmp option, it can impact other OpenMP features. Just so you know. 💅

Option -qopenmp-simd is equivalent to option -fiopenmp-simd; option /Qopenmp-simd is equivalent to option /Qiopenmp-simd.

NOTE: Advanced users who prefer to use OpenMP* as it is implemented by the LLVM community, can get most of that functionality by using options -fopenmp and -fopenmp-simd. Iykyk. 🧚

Alternate Options:

Linux: -fiopenmp-simd
Windows: /Qiopenmp-simd

-qopenmp-stubs (L*X only) — enables compilation of OpenMP* programs in sequential mode. Sequential era, honestly. 🌸

Arguments:

None

Default:

OFF — the library of OpenMP* function stubs is not linked.

Description:

This option enables compilation of OpenMP* programs in sequential mode. The OpenMP directives are ignored and a stub OpenMP library is linked.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

-qopt-assume-no-loop-carried-dep[=n] (L*X only) — lets you set a level of performance tuning for loops. Loops are the main character here, lowkey. 🔥

Arguments:

n — is the action for loop-carried dependencies. Possible values are:
- 0 — the compiler does not assume there are no loop carried dependencies. This is the default if this option is not specified.
- 1 — tells the compiler to assume there are no loop-carried dependencies for innermost loops. This is the default if the option is used but n is not specified.
- 2 — tells the compiler to assume there are no loop-carried dependencies for all loop levels.

Default:

[q or Q]qopt-assume-no-loop-carried-dep=0 — the compiler does not assume there are no loop carried dependencies.

Description:

This option lets you set a level of performance tuning for loops.

It's useful for C/C++ applications and benchmarks where pointers and arguments could be aliased. Why? Because when you specify level 1 or level 2, more loops will be vectorized or benefit from loop transformations. Slay, vectorization. 🦋

This option is applied to all loops in the file. It does not apply to code outside loops. Boundaries, bestie. 💅

Alternate Options:

None

-qopt-dword-index-for-array-of-structs[=val] (L*X only) —

Okay so this part of the option is literally this: it lets the compiler use dword indexes to access elements of arrays of structs that do not exceed a specified number of bytes. 🌀

Arguments:

val — is 16 or 32. If val is not specified, the compiler uses dword indexes to access elements of arrays of structs that do not exceed 16 bytes.

Default:

OFF — the compiler uses dword indexes only when it can determine it is safe to do so.

Description:

This option lets the compiler use dword indexes to access elements of arrays of structs that do not exceed val bytes.

The relevant arrays should contain no more than INT_MAX / sizeof(element) elements. 📏

Alternate Options:

None

🌈 `-qopt-dynamic-align` (LX only) / `-qno-opt-dynamic-align` (LX only)

Enables or disables dynamic data alignment optimizations. ✨

Arguments:

None

Default:

-qno-opt-dynamic-align — the compiler does not generate code dynamically dependent on alignment.

Description:

This option enables or disables dynamic data alignment optimizations.

If you specify -qno-opt-dynamic-align or /Qopt-dynamic-align-, the compiler generates no code dynamically dependent on alignment. It will not do any optimizations based on data location, and results will depend on the data values themselves. 👀

When you specify [q or Q]opt-dynamic-align, the compiler may implement conditional optimizations based on dynamic alignment of the input data. These dynamic alignment optimizations may result in different bitwise results for aligned and unaligned data with the same values. 😵‍💫

Dynamic alignment optimizations can improve the performance of some vectorized code, especially for long trip count loops, but there is an associated cost of increased code size and compile time. Disabling such optimizations can improve the performance of some other vectorized code. It may also improve bitwise reproducibility of results, factoring out data location from possible sources of discrepancy. 🎀

Alternate Options:

None

🔥 `-qopt-for-throughput=value` (L*X only)

Determines how the compiler optimizes for throughput depending on whether the program is to run in single-job or multi-job mode. 🏃‍♀️💨

Arguments:

value — is one of the values "multi-job" or "single-job".

Default:

OFF — if this option is not specified, the compiler will not optimize for throughput performance.

Description:

This option determines whether throughput performance optimization occurs for a program that is run as a single job or one that is run in a multiple job environment.

The memory optimizations for a single job versus multiple jobs can be tuned in different ways by the compiler. For example, the cost model for loop tiling and prefetching are different for a single job versus multiple jobs. When a single job is running, more memory is available and the tunings will be different. 🧠✨

Alternate Options:

None

💅 `-Qoption,string,options` (L*X only)

Passes options to a specified tool. 🛠️

Arguments:

string — is the name of the tool.
options — are one or more comma-separated, valid options for the designated tool.

Note that certain tools may require that options appear within quotation marks (" ").

Default:

OFF — no options are passed to tools.

Description:

This option passes options to a specified tool.

If an argument contains a space or tab character, you must enclose the entire argument in quotation marks (" "). You must separate multiple arguments with commas. 🫶

string can be any of the following:

cpp — indicates the preprocessor for the compiler.
c — indicates the Intel(R) oneAPI DPC++/C++ Compiler.
asm — indicates the assembler.
link — indicates the linker.
On Windows* systems, the following is also available:
- masm — indicates the Microsoft assembler.
On Linux* systems, the following are also available:
- as — indicates the assembler.
- gas — indicates the GNU assembler.
- ld — indicates the loader.
- gld — indicates the GNU loader.
- lib — indicates an additional library.
- crt — indicates the crt%.o files linked into executables to contain the place to start execution.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 🚨

Alternate Options:

None

🌸 `-qopt-mem-layout-trans[=n]` (LX only) / `-qno-opt-mem-layout-trans` (LX only)

Controls the level of memory layout transformations performed by the compiler. 🧚

Arguments:

n — is the level of memory layout transformations. Possible values are:
- 0 — disables memory layout transformations. This is the same as specifying -qno-opt-mem-layout-trans (Linux*) or /Qopt-mem-layout-trans- (Windows*).
- 1 — enables basic memory layout transformations.
- 2 — enables more memory layout transformations. This is the same as specifying [q or Q]opt-mem-layout-trans with no argument.
- 3 — enables more memory layout transformations like copy-in/copy-out of structures for a region of code. This setting should only be used when targeting systems that have more than 4GB of physical memory per core.
- 4 — enables more aggressive memory layout transformations. This setting should only be used when targeting systems that have more than 4GB of physical memory per core.

Default:

-qopt-mem-layout-trans=0 — no memory layout transformations are performed.

Description:

This option controls the level of memory layout transformations performed by the compiler. This option can improve cache reuse and cache locality. 💖

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn
more at
                  www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

🦋 `-qopt-multiple-gather-scatter-by-shuffles` (LX only) / `-qno-opt-multiple-gather-scatter-by-shuffles` (LX only)

Enables or disables the optimization for multiple adjacent gather/scatter type vector memory references. 🌪️

Arguments:

None

Default:

varies — when this option is not specified, the compiler uses default heuristics for optimization.

Description:

This option controls the optimization for multiple adjacent gather/scatter type vector memory references. This optimization hint is useful for performance tuning. It tries to generate more optimal software sequences using shuffles. ✨

If you specify this option, the compiler will apply the optimization heuristics. If you specify -qno-opt-multiple-gather-scatter-by-shuffles or /Qopt-multiple-gather-scatter-by-shuffles-, the compiler will not apply the optimization.

NOTE: Optimization is affected by optimization compiler options, such as [Q]x, -march (Linux*), and /arch (Windows*). 🚨

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn
more at
                  www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

🎀 `-qopt-prefetch[=n]` (LX only) / `-qno-opt-prefetch` (LX only)

Enables or disables prefetch insertion optimization. 👑

Arguments:

n — is the level of software prefetching optimization desired. Possible values are:
- 0 — disables software prefetching. This is the same as specifying -qno-opt-prefetch (Linux*) or /Qopt-prefetch- (Windows*).
- 1 to 5 — enables different levels of software prefetching. If you do not specify a value for n, the default is -qopt-prefetch=2 or /Qopt-prefetch:2. Use lower values to reduce the amount of prefetching.

Default:

Default: varies — yep, the default can shift around depending on certain option settings. 🌀

If you specify option -qno-opt-prefetch (or /Qopt-prefetch-), or you specify option O0 or O1 explicitly or implicitly, prefetch insertion optimization is disabled.
If you specify option O2 or above explicitly or implicitly, the default is option -qopt-prefetch=2 (or /Qopt-prefetch:2).

Description: This option enables or disables prefetch insertion optimization. The goal of prefetching is to reduce cache misses by providing hints to the processor about when data should be loaded into the cache. ✨

This option enables prefetching when higher optimization levels are specified.

Alternate Options: None.

-qopt-prefetch-distance=n (L*X only) — sets how far ahead the compiler-generated prefetches reach inside loops. 🎯

Arguments:

n — the prefetch distance, measured in number of (possibly-vectorized) iterations. Possible values are non-negative numbers >=0.
n = 0 turns off all compiler issued prefetches from memory to L1.

Default:

OFF — the compiler uses default heuristics to determine the prefetch distance.

Description: This option specifies the prefetch distance to be used for compiler-generated prefetches inside loops. The unit n is the number of iterations. If the loop is vectorized by the compiler, the unit is the number of vectorized iterations.

The value of n will be used as the distance for prefetches from memory to L1 (for example, the vprefetch0 instruction).

Linux: This option is ignored if option -qopt-prefetch=0 or option -qno-opt-prefetch is specified.

Windows: This option is ignored if option /Qopt-prefetch=0 or option /Qopt-prefetch- is specified.

Alternate Options: None.

-qopt-prefetch-loads-only (L*X only) — tells the compiler to prefetch only the loads inside the loop and ignore the stores, if any. 🛍️

Arguments: None.

Default: OFF — the compiler prefetches for both loads and stores.

Description: This option specifies that the compiler should only prefetch for loads inside the loop and ignore the stores, if any.

Linux: This option is ignored if option -qopt-prefetch=0 or option -qno-opt-prefetch is specified.

Windows: This option is ignored if option /Qopt-prefetch=0 or option /Qopt-prefetch- is specified.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None.

-qopt-report[=arg] (L*X only) — turns on a textual file full of optimization transformation tea. ☕👑

Arguments:

arg — determines the level of detail in the report. Possible values are:
- 0 — disables generation of an optimization report. This is the default when the option is not specified.
- 1 or low — tells the compiler to only emit positive remarks. That is, report only the transformations that actually happened.
- 2 or medium — tells the compiler to create a report with low details, plus emit negative remarks with a reason why the transformation did not happen. This is the default if you do not specify arg.
- 3 or high — tells the compiler to create a report with medium details, plus all other details.

Default: OFF — no optimization report is generated.

Description: This option enables the generation of a textual file that includes optimization transformation information.

The file provides the optimization information for the source file being compiled. For example:

icx -fiopenmp -qopt-report foo.c

This command will generate a file called foo.optrpt containing the optimization report messages.

When offloading is enabled, two optimization reports are generated:

A host-side optimization report named foo.optrpt, when there is only CPU compilation.
A device-side optimization report with the form foo-xxx-yyy.optrpt, where xxx is either "sycl" or "openmp" depending on the kind of offload, and "yyy" is the name of the offload target. For example, if option -fopenmp-targets=spir64 is specified on the compile, the report is named foo-openmp-spir64.optrpt.

NOTE: In releases prior to 2025.0, this option also produced a YAML-formatted optimization report containing LLVM community optimization remarks. Beginning with release 2025.0, the YAML file will no longer be produced by this option. However, you can still produce the YAML report using the Clang option -fsave-optimization-record.

Alternate Options: None.

-qopt-report-file=keyword (L*X only) — controls whether the optimization report output goes to a file, stderr, or stdout. 📬

Arguments:

keyword — specifies where the output for the report goes. You can specify one of the following:
- filename — specifies the name of the file where the generated report should go.
- stderr — indicates that the generated report should go to stderr.
- stdout — indicates that the generated report should go to stdout.
  - This setting can also be specified as -qopt-report-stdout (Linux) or /Qopt-report-stdout (Windows).

Default: OFF — no optimization report is generated.

Description: This option specifies whether the output for the generated optimization report goes to a file, stderr, or stdout.

If you use this option, you do not have to specify option [q or Q]opt-report.

Specifying -qopt-report-file=stdout (Linux) or /Qopt-report-file:stdout (Windows) is the same as specifying option -qopt-report-stdout (Linux) or /qopt-report-stdout (Windows).

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None.

-qopt-report-names=keyword (L*X only) — picks whether the optimization report shows mangled or unmangled names. 🏷️

Arguments:

keyword — specifies the form for the names. You can specify one of the following:
- mangled — indicates that the optimization report should contain mangled names.
- unmangled — indicates that the optimization report should contain unmangled names.

Default: unmangled — if this option is not specified and an optimization report is generated, unmangled names appear in the optimization report.

Description: This option specifies whether mangled or unmangled names should appear in the optimization report. If you use this option, you must specify either mangled or unmangled.

If you specify mangled, encoding (also known as decoration) is added to names in the optimization report. This is appropriate when you want to match annotations with the assembly listing.

If you specify unmangled, no encoding (or decoration) is added to names in the optimization report. This is appropriate when you want to match annotations with the source listing.

If you use this option, you do not have to specify option [q or Q]opt-report.

Alternate Options: None.

-qopt-report-phase[=list] (L*X only) — specifies one or more optimizer phases for which optimization reports are generated. 🧪

Arguments:

list — (optional) specifies one or more phases to generate reports for. If you specify more than one phase, they must be separated with commas. The values you can specify are:
- cg — the phase for code generation
- ipo — the phase for Interprocedural Optimization
- loop — the phase for loop nest optimization
- openmp — the phase for OpenMP*
- pgo — the phase for Profile Guided optimization

vec — the phase for vectorization ✨
all — all optimizer phases. This is the default if you do not specify list.

Default:

OFF — no optimization report is generated.

Description:

This option specifies one or more optimizer phases for which optimization reports are generated. 💅

For certain phases, you also need to specify other options:

If you specify phase cg, you must also specify option O1, O2 (default), or O3.
If you specify phase loop, you must also specify option O2 (default) or O3.
If you specify phase openmp, you must also specify option fiopenmp or option [q or Q]openmp.
If you specify phase pgo, you must also specify Clang option -fprofile-use or -fprofile-sample-use. For more information about Clang options, see the Clang documentation.
If you specify phase vec, you must also specify option O2 (default) or O3.

If you use this option, you do not have to specify option [q or Q]opt-report.

However, if you want to get more details for each phase, specify option [q or Q]opt-report=n along with this option and indicate the level of detail you want by specifying an appropriate value for n.

When optimization reporting is enabled, the default is -qopt-report-phase=all (Linux*) or /Qopt-report-phase:all (Windows*).

Alternate Options: none.

-qopt-report-stdout (L*X only) — specifies that the generated report should go to stdout. 🖨️✨

Arguments: none.

Default:

OFF — no optimization report is generated.

Description:

This option specifies that the output for the generated optimization report goes to stdout. It is the same as specifying -qopt-report-file=stdout (Linux).

If you use this option, you do not have to specify option [q or Q]opt-report.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: none.

-qopt-streaming-stores=keyword (L*X only) — enables generation of streaming stores for optimization. 🌊
-qno-opt-streaming-stores (L*X only) — the no-form; its effect is the same as specifying -qopt-streaming-stores=never or /Qopt-streaming-stores-. 🛑

Arguments:

keyword specifies whether streaming stores are generated. Possible values are:

always — enables generation of streaming stores for optimization. The compiler optimizes under the assumption that the application is memory bound.

When this option setting is specified, it is your responsibility to also insert any memory barriers (fences) as required to ensure correct memory ordering within a thread or across threads. See the Examples section for one way to do this. ⚠️

never — disables generation of streaming stores for optimization. Normal stores are performed.

This setting has the same effect as specifying -qno-opt-streaming-stores or /Qopt-streaming-stores-.

auto — lets the compiler decide which instructions to use.

Default:

-qopt-streaming-stores=auto — the compiler decides whether to use streaming stores or normal stores.

Description:

This option enables generation of streaming stores for optimization. This method stores data with instructions that use a non-temporal buffer, which minimizes memory hierarchy pollution.

This option may be useful for applications that can benefit from streaming stores.

Alternate Options: none.

-qopt-zmm-usage=keyword (L*X only) — defines a level of zmm registers usage. 🧮✨

Arguments:

keyword specifies the level of zmm registers usage. Possible values are:

low — tells the compiler that the compiled program is unlikely to benefit from zmm registers usage. It specifies that the compiler should avoid using zmm registers unless it can prove the gain from their usage.
high — tells the compiler to generate zmm code without restrictions.

Default: varies.

The default is low when you specify [Q]xCORE-AVX512.
The default is high when you specify [Q]xCOMMON-AVX512.

Description:

This option may provide better code optimization for Intel(R) processors that are on the Intel(R) microarchitecture formerly code-named Skylake.

This option defines a level of zmm registers usage. The low setting causes the compiler to generate code with zmm registers very carefully, only when the gain from their usage is proven. The high setting causes the compiler to use much less restrictive heuristics for zmm code generation.

It is not always easy to predict whether the high or the low setting will yield better performance. Programs that enjoy high performance gains from the use of xmm or ymm registers may expect performance improvement by moving to use zmm registers. However, some programs that use zmm registers may not gain as much or may even lose performance. We recommend that you try both option values to measure the performance of your programs.

This option is ignored if you do not specify an option that enables Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512), such as [Q]xCORE-AVX512 or option [Q]xCOMMON-AVX512.

This option has no effect on loops that use pragma omp simd simdlen(n) or on functions that are generated by vector specifications specific to CORE-AVX512.

Alternate Options: none.

-qtbb (L*X only) — tells the compiler to link to the Intel(R) oneAPI Threading Building Blocks (oneTBB) libraries. 🧵💖

Arguments: none.

Default:

OFF — the compiler does not link to the oneTBB libraries.

Description:

This option tells the compiler to link to the Intel(R) oneAPI Threading Building Blocks (oneTBB) libraries and include the oneTBB headers.

NOTE: On Windows* systems, this option adds directives to the compiled code, which the linker then reads without further input from the driver. You do not need to specify a separate link command.

On Linux* systems, the driver must add the library names explicitly to the link command. You must use option -qtbb to perform the link to pull in the dependent libraries.

Alternate Options:

Linux: -tbb (this is a deprecated option)

-qunknown-option-as-warning (L*X only) — tells the compiler to treat unknown compiler options on Linux* as a warning instead of an error. 🚨➡️💬
-qno-unknown-option-as-warning (L*X only) — the no-form; unknown compiler options on Linux are treated as errors. 🛑

Arguments: none.

Default:

-qno-unknown-option-as-warning — when unknown compiler options are encountered on Linux, the compiler emits diagnostic errors.

Description:

This option tells the compiler to treat unknown compiler options on Linux as a warning instead of an error.

If qno-unknown-option-as-warning is specified, unknown compiler options on Linux are treated as errors.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: none.

-regcall (L*X only) — tells the compiler that the __regcall calling convention should be used for functions that do not directly specify a calling convention. 📞✨

Arguments: none.

Default:

OFF — the __regcall calling convention will only be used if a function explicitly specifies it.

Description:

This option tells the compiler that the __regcall calling convention should be used for functions that do not directly specify a calling convention. This calling convention ensures that as many values as possible are passed or returned in registers.

It ensures that __regcall is the default calling convention for functions in the compilation, unless another calling convention is specified in a declaration.

This calling convention is ignored if it is specified for a function with variable arguments.

Note that all __regcall functions must have prototypes.

Alternate Options: none.

-reuse-exe=exe-filename (L*X only) — tells the compiler to speed up Field Programmable Gate Array (FPGA) target compile time by reusing a previously compiled FPGA hardware image. 🧩⚡

Arguments:

exe-filename is a previously compiled SYCL* binary.

Default:

okay so, picking up right where we left off:

Default (continued): OFF — there is no potential compile-time speed up by reusing the executable for the FPGA target.

Description: this option tells the compiler to speed up FPGA target compile time by reusing a previously compiled FPGA hardware image. This option is useful only when compiling for hardware.

It lets you minimize or avoid long Intel(R) Quartus(R) Prime Software compile times for FPGA targets when the device code is unchanged.

NOTE: when offloading is enabled, this option only applies to device-specific compilation.

Alternate Options: None

`-S` (`L*X` only)

Arguments: None

Default: OFF — normal compilation and linking occur.

Description: this option causes the compiler to compile to an assembly file only and not link.

On Linux* systems, the assembly file name has a .s suffix. On Windows* systems, the assembly file name has an .asm suffix.

Alternate Options: Linux: None

`-save-temps` (`LX` only) / `-no-save-temps` (`LX` only)

Arguments: None

Default: Linux systems: -no-save-temps. On Linux systems, the compiler deletes intermediate files after compilation is completed.

Description: this option tells the compiler to save intermediate files created during compilation. The names of the files saved are based on the name of the source file; the files are saved in the current working directory.

If option -save-temps (Linux) or option /Qsave-temps (Windows) is specified, the following occurs:

On Linux, the object .o file is saved.
On Windows, the .obj file object .o file is saved.

If -no-save-temps is specified on Linux systems, the following occurs:

The .o file is put into /tmp and deleted after calling ld.
The preprocessed file is not saved after it has been used by the compiler.

If /Qsave-temps- is specified on Windows systems, the following occurs:

The .obj file is not saved after the linker step.
The preprocessed file is not saved after it has been used by the compiler.

NOTE: this option only saves intermediate files that are normally created during compilation.

Alternate Options: None

`-shared` (`L*X` only)

Arguments: None

Default: OFF — the compiler produces an executable.

Description: this option tells the compiler to produce a dynamic shared object (DSO) instead of an executable. This includes linking in all libraries dynamically and passing -shared to the linker.

You must specify option fpic for the compilation of each object file you want to include in the shared library.

NOTE: when you specify option shared, the Intel(R) libraries are linked dynamically. If you want them to be linked statically, you must also specify option static-intel.

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

`-shared-intel` (`L*X` only)

Arguments: None

Default: OFF — Intel(R) libraries are linked in statically, with the exception of Intel's OpenMP* runtime support library, which is linked in dynamically unless you specify option -qopenmp-link=static.

Description: this option causes Intel-provided libraries to be linked in dynamically. It is the opposite of -static-intel.

This option is processed by the compiler driver command that initiates linking, adding library names explicitly to the link command.

If you specify option -mcmodel=medium or -mcmodel=large, it sets option -shared-intel.

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

`-shared-libgcc` (`L*X` only)

Arguments: None

Default: -shared-libgcc — the compiler links the libgcc library dynamically.

Description: this option links the GNU libgcc library dynamically. It is the opposite of option static-libgcc.

This option is processed by the compiler driver command that initiates linking, adding library names explicitly to the link command.

This option is useful when you want to override the default behavior of the static option, which causes all libraries to be linked statically.

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

`-sox[=keyword[,keyword]]` (`LX` only) / `-no-sox` (`LX` only)

Arguments: keyword is the routine information to include. Possible values are:

inline — includes a list of the functions that were inlined in each object.
profile — includes data when profile was used for functions that were compiled with Clang options that enable profile-guided optimization (PGO) such as -fprofile-use and -fprofile-instr-use.
secure — strips out directory names and the options that use them.

Default: -no-sox — the compiler does not save these informational strings in the object file.

Description: this option tells the compiler to save the compilation options in the executable file. The information is embedded as a string in each object file or assembly output.

If you specify option sox with no keyword, the compiler saves the compiler options and version number used in the compilation of the objects that make up the executable.

When you specify this option, the size of the executable on disk is increased slightly. When you link the object files into an executable file, the linker places each of the information strings into the header of the executable. It is then possible to use a tool, such as a strings utility, to determine what options were used to build the executable file.

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

`-static` (`L*X` only)

Arguments: None

Default: OFF — the compiler links with shared libraries except as otherwise specified by -static-intel or its default.

Description: this option prevents linking with shared libraries. It causes the executable to link all libraries statically.

NOTE: this option does not cause static linking of libraries for which no static version is available. These libraries can only be linked dynamically.

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

`-static-intel` (`L*X` only)

Arguments: None

Default: ON — Intel(R) libraries are linked in statically with the following exceptions:

The Intel OpenMP* runtime support library is linked in dynamically. To prevent this, specify option -qopenmp-link=static.
The Intel(R) libraries are linked in dynamically when you specify option shared. To prevent this, when you specify shared, you must also specify option static-intel.

Description: this option causes Intel-provided libraries to be linked in statically with certain exceptions (see the Default above). It is the opposite of -shared-intel.

This option is processed by the compiler driver command that initiates linking, adding library names explicitly to the link command.

If you specify option -static-intel while option -mcmodel=medium or -mcmodel=large is set, an error will be displayed.

If you specify option -static-intel and any of the Intel-provided libraries have no static version, a diagnostic will be displayed.

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

`-static-libgcc` (`L*X` only)

Arguments: None

Default: OFF — the compiler links the GNU libgcc library dynamically.

Description: bestie, this one links the GNU libgcc library statically. It's literally the opposite of -shared-libgcc. Iconic opposites energy. 💅

This option gets processed by the compiler driver command that initiates linking, and it adds library names explicitly to the link command. No cap.

It's the move when you wanna override the default behavior, which causes the library to be linked dynamically.

⚠️ NOTE: if you want to use traceback, you must also link to the static version of the libgcc library. That library is what enables printing of backtrace information. Don't skip it, ok? 😭

⚠️ NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. Periodt.

Alternate Options: None 🫶

💖 -static-libstdc++ (L*X only)

Links the GNU libstdc++ library statically. Slay.

Arguments: None

Default:

OFF — the compiler links the GNU libstdc++ library dynamically.

Description:

This option links the GNU libstdc++ library statically. Same vibe as the last one, different library. 🎀

This option is processed by the compiler driver command that initiates linking, adding library names explicitly to the link command.

This option is useful when you want to override the default behavior, which causes the library to be linked dynamically. (Not me repeating myself, the manual is like this, iykyk.)

⚠️ NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

🦋 -std=val (L*X only)

Tells the compiler to conform to a specific language standard. It's giving "pick your era." ✨

Arguments:

val — specifies the language standard to conform to.

The following values can be specified for both Linux* and Windows*:

c++2b — enables support for the Working Draft for ISO C++ 2023 DIS standard.
c++20 — enables support for the 2020 ISO C++ DIS standard.
c++17 — enables support for the 2017 ISO C++ standard with amendments.
c++14 — enables support for the 2014 ISO C++ standard with amendments.
c18 and c17 — both settings enable support for the 2017 ISO C standard.
- Support for c17 can also be enabled by value iso9899:2017.
- Support for c18 can also be enabled by value iso9899:2018.
c11 — enables support for the 2011 ISO C standard.
- Support for this standard can also be enabled by value iso9899:2011.

The following values can only be specified for Linux:

c++11 — enables support for the 2011 ISO C++ standard with amendments.
c++98 and c++03 — enables support for the 1998 ISO C++ standard with amendments.
c2x — enables support for the Working Draft for ISO C2x standard.
c99 — enables support for the 1999 ISO C standard.
- Support for this standard can also be enabled by value iso9899:1999.
c90 and c89 — enables support for the 1990 ISO C standard.
- Support for this standard can also be enabled by value iso9899:1990.
gnu++2b — enables support for the Working Draft for ISO C++ 2023 DIS standard plus GNU extensions.
gnu++20 — enables support for the 2020 ISO C++ DIS standard plus GNU extensions.
gnu++17 — enables support for the 2017 ISO C++ standard with amendments plus GNU extensions.
gnu++14 — enables support for the 2014 ISO C++ standard with amendments plus GNU extensions.
gnu++11 — enables support for the 2011 ISO C++ standard with amendments plus GNU extensions.
gnu++98 and gnu++03 — enables support for the 1998 ISO C++ standard with amendments plus GNU extensions.
gnu2x — enables support for the Working Draft for ISO C2x standard plus GNU extensions.
gnu18 and gnu17 — enables support for the 2017 ISO C standard plus GNU extensions.
gnu11 — enables support for the 2011 ISO C standard plus GNU extensions.
gnu99 — enables support for the 1999 ISO C standard plus GNU extensions.
gnu90 and gnu89 — enables support for the 1990 ISO C standard plus GNU extensions.

Default:

c++17 or c17 — for C++, the compiler conforms to the 2017 ISO C++ standard. For C, the compiler conforms to the 2017 ISO C standard.

Description:

This option tells the compiler to conform to a specific language standard. That's literally it, that's the whole thing. 💁‍♀️

Alternate Options: None

🌸 -strict-ansi (L*X only)

Tells the compiler to implement strict ANSI conformance dialect. So serious. So proper. 🎀

Arguments: None

Default:

OFF — the compiler conforms to default standards.

Description:

This option tells the compiler to implement strict ANSI conformance dialect. On Linux* systems, if you need to be compatible with gcc, use the -ansi option instead. (iykyk 👀)

This option sets option fmath-errno, which tells the compiler to assume that the program tests errno after calls to math library functions. This restricts optimization because it causes the compiler to treat most math functions as having side effects. Yeah. It's lowkey a performance hit, bestie. 💀

⚠️ NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

🌈 --sysroot=dir (L*X only)

Specifies the root directory where headers and libraries are located. Home base for your headers, fr fr. ✨

Arguments:

dir — specifies the local directory that contains copies of target libraries in the corresponding subdirectories.

Default:

Off — the compiler uses default settings to search for headers and libraries.

Description:

This option specifies the root directory where headers and libraries are located.

For example, if the headers and libraries are normally located in /usr/include and /usr/lib respectively, --sysroot=/mydir will cause the compiler to search in /mydir/usr/include and /mydir/usr/lib for the headers and libraries. See how it just slides the whole root under your dir? Iconic. 🫶

This option is provided for compatibility with gcc.

⚠️ NOTE: even though this option is not supported for a Windows-to-Windows native compiler, it is supported for a Windows-host to Linux-target compiler. Read that twice, it's a whole vibe check on its own. 👑

Alternate Options: None

🧚 -Tfilename (L*X only)

Tells the linker to read link commands from a file. Delegation queen. 💅

Arguments:

filename — is the name of the file.

Default:

OFF — the linker does not read link commands from a file.

Description:

This option tells the linker to read link commands from a file.

⚠️ NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

💜 -Uname (L*X only)

Undefines any definition currently in effect for the specified macro. Poof, gone, no notes. 🪄

Arguments:

name — is the name of the macro to be undefined.

Default:

OFF — macro definitions are in effect until they are undefined.

Description:

This option undefines any definition currently in effect for the specified macro. It is equivalent to an #undef preprocessing directive. Like, literally the same thing.

On Windows systems, use the /u option to undefine all previously defined preprocessor values. Different flag, different job — don't mix them up bestie. 🙈

Alternate Options: None

⭐ -u symbol (L*X only)

Tells the compiler the specified symbol is undefined. Main character symbol that refuses to be defined. 😌

Arguments: None

Default:

OFF — standard rules are in effect for variables.

Description:

This option tells the compiler the specified symbol is undefined.

Alternate Options: None

-undef (L*X only) — bestie, this one just yeets every predefined macro out the window.
- Arguments: None
- Default: OFF — Defined macros are in effect until they are undefined.
- Description: This option disables all predefined macros.
- Alternate Options: None
-unroll[=n] (L*X only) — tells the compiler the max number of times to unroll loops, no cap.
- Arguments:
  - n — Is the maximum number of times a loop can be unrolled. To disable loop enrolling, specify 0.
- Default: -unroll or /Qunroll — The compiler uses default heuristics when unrolling loops.
- Description: This option tells the compiler the maximum number of times to unroll loops. If you do not specify n, the optimizer determines how many times loops can be unrolled.
- Alternate Options: Linux: -funroll-loops
-use-intel-optimized-headers (L*X only) — controls whether the performance headers directory gets added to the include path search list. iconic behavior tbh.
- Arguments: None
- Default: -no-use-intel-optimized-headers — The performance headers directory is not added to the include path search list.
- Description: This option determines whether the performance headers directory is added to the include path search list. The performance headers directory is added if you specify [Q]use-intel-optimized-headers. Appropriate libraries are also linked in, as needed, for proper functionality.
- > Product and Performance Information 🫶

= = = = = = = = = = Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex. Notice revision #20201201 = = = = = = = = = =

Alternate Options: None

-use-msasm (L*X only) — unlocks blocks and entire functions of assembly code inside a C or C++ file. very main character.
- Arguments: None
- Default: OFF — The compiler allows a GNU*-style inline assembly format.
- Description: This option enables the use of blocks and entire functions of assembly code within a C or C++ file. It allows a Microsoft* MASM-style inline assembly block not a GNU*-style inline assembly block.
- Alternate Options: -fasm-blocks
-v [filename] (L*X only) — says the driver tool commands should be displayed and executed, periodt.
- Arguments:
  - filename — Is the name of a source file to be compiled. A space must appear before the file name.
- Default: OFF — No tool commands are shown.
- Description: This option specifies that driver tool commands should be displayed and executed. If you use this option without specifying a source file name, the compiler displays only the version of the compiler.
- Alternate Options: None
-vec (L*X only) / -no-vec (L*X only) — enables or disables loop vectorization, slay.
- Arguments: None
- Default: -vec — Loop vectorization is enabled if option O2 or higher is in effect.
- Description: This option enables or disables loop vectorization. To disable loop vectorization, specify -no-vec (Linux*) or /Qvec- (Windows*).

NOTE: Using this option enables vectorization at default optimization levels for both Intel(R) microprocessors and non-Intel microprocessors. Vectorization may call library routines that can result in additional performance gain on Intel microprocessors than on non-Intel microprocessors. NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

-vec-assume-index-overflow (L*X only) / -no-vec-assume-index-overflow (L*X only) — toggles between modes, with the less conservative mode as the default. lowkey chill.
- Arguments: None
- Default: Less conservative mode — This option toggles between modes, leaving the less conservative mode on by default.
- Description: When this option is set, assume overflow of integer indices may happen, disabling additional optimization of loads and stores.
- Alternate Options: None
-vec-threshold[n] (L*X only) — sets a threshold for the vectorization of loops, based on the probability of profitable parallel execution. math girlie moment.
- Arguments:
  - n — Is an integer whose value is the threshold for the vectorization of loops. Possible values are 0 through 100. If n is 0, loops get vectorized always, regardless of computation work volume. If n is 100, loops get vectorized when performance gains are predicted based on the compiler analysis data. Loops get vectorized only if profitable vector-level parallel execution is almost certain. The intermediate 1 to 99 values represent the percentage probability for profitable speed-up. For example, n=50 directs the compiler to vectorize only if there is a 50% probability of the code speeding up if executed in vector form.
- Default: -vec-threshold100 — Loops get vectorized only if profitable vector-level parallel execution is almost certain. This is also the default if you do not specify n.
- Description: This option sets a threshold for the vectorization of loops based on the probability of profitable execution of the vectorized loop in parallel. This option is useful for loops whose computation work volume cannot be determined at compile-time. The threshold is usually relevant when the loop trip count is unknown at compile-time. The compiler applies a heuristic that tries to balance the overhead of creating multiple threads versus the amount of work available to be shared amongst the threads.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options: None

-vecabi=keyword (L*X only) — determines which vector function application binary interface (ABI) the compiler uses to create or call vector functions. very ABI-core 💅
- Arguments:
  - keyword — Specifies which vector function ABI to use. Possible values are:
    - cmdtarget — Tells the compiler to generate an extended set of vector functions. Vector variants are created for all targets specified by compiler options [Q]x and/or [Q]ax. No change needs to be made to the source code.
    - gcc — Tells the compiler to use the gcc vector function ABI.
- Default: gcc — The compiler uses the gcc-compatible vector function ABI.
- Description: This option determines which vector function application binary interface (ABI) the compiler uses to create or call vector functions. All files in an application that define or use vector functions must make identical use of -vecabi=cmdtarget (and /Qvecabi:cmdtarget); otherwise, link-time or runtime errors may occur. For all files where -vecabi=cmdtarget (or /Qvecabi:cmdtarget) is specified, options [Q]x and/or [Q]ax must have identical values. Similarly, link errors may occur if you attempt to link code compiled with -vecabi=cmdtarget (or /Qvecabi:cmdtarget) with libraries or other program modules/routines that contain vector function definitions that have not or cannot be recompiled. When cmdtarget is specified, the additional vector function versions are created by copying each vector specification and changing target processor in the copy. The number of vector functions is determined by the settings specified in options [Q]x and/or [Q]ax. For example, suppose we have the following function declaration:

#pragma omp declare simd (ompx_processor(core_2_duo_sse4_1)) int foo(int a);

and the following options are specified: -axAVX, CORE-AVX2. The following table shows the different results for the above declaration and option specifications when setting gcc or setting cmdtarget is used:

gcc — A vector version is created for each of the following targets:
- Intel(R) SSE2
- Intel(R) AVX
- Intel(R) AVX2
- Intel(R) AVX512
cmdtarget — These variants are always created independently of target options. A vector version is created for each of the following targets:
- Intel(R) SSE2 (default because no -x option is used)
- Intel(R) SSE4.1 (by vector function specification)

Alternate Options: None

avx2 — Intel(R) AVX2 (by the ax option value) ✨

⚠️ NOTE: bestie, listen — to avoid possible link-time and runtime errors, use identical [Q]vecabi settings when compiling all files in an application that define or use vector functions, including libraries. And if setting cmdtarget is specified, options [Q]x and/or [Q]ax must have identical values. No mixing, no matching, periodt. 💅

For more info about the Intel(R)-compatible vector functions ABI, see the downloadable PDF titled Vector Function Application Binary Interface.

For more info about the GCC vector functions ABI, see the item Libmvec - vector math library document in the GLIBC wiki at sourceware.org.

🫶 Product and Performance Information 🫶

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn
more at
                  www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

`--version` (L*X only) 👑

Tells the compiler to display GCC-style version information.

Arguments:

None

Default:

OFF

Description:

Tells the compiler to display GCC-style version information. That's literally it, that's the whole vibe.

⚠️ NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

`-w` (L*X only) 🤫

Disables all warning messages.

Arguments:

None

Default:

OFF — Default warning messages are enabled.

Description:

This option disables all warning messages. Shhh. 🙈

Alternate Options:

Linux: None
Windows: /W0

`-Wa,option1[,option2,...]` (L*X only) 🔧

Passes options to the assembler for processing.

Arguments:

option — Is an assembler option. This option is not processed by the driver and is directly passed to the assembler.

Default:

OFF — No options are passed to the assembler.

Description:

This option passes one or more options to the assembler for processing. If the assembler is not invoked, these options are ignored. ✨

⚠️ NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

`-Wabi` (L*X only)

`-Wno-abi` (L*X only)

Determines whether a warning is issued if generated code is not C++ ABI compliant.

Arguments:

None

Default:

Wno-abi — No warning is issued when generated code is not C++ ABI compliant.

Description:

This option determines whether a warning is issued if generated code is not C++ ABI compliant.

Alternate Options:

None

`-Wall` (L*X only) 🚨

Enables warning and error diagnostics.

Arguments:

None

Default:

OFF — Only default warning diagnostics are enabled.

Description:

This option enables many warning and error diagnostics. It's giving "turn on the whole warning section of the group chat." 😭

On Windows* systems, this option is equivalent to the /W4 option. It enables diagnostics for all level 3 warnings plus informational warnings and remarks.

However, on Linux* systems, this option is similar to gcc option -Wall. It displays all errors and some of the warnings that are typically reported by gcc option -Wall. If you want to display all warnings, specify the -w2 or -w3 option. 👀

The Wall, -wn, and /Wn options can override each other. The last option specified on the command line takes precedence. Last one in wins, no cap.

Alternate Options:

None

`-Wcheck-unicode-security` (L*X only) 🕵️‍♀️

`-Wno-check-unicode-security` (L*X only)

Determines whether the compiler performs source code checking for Unicode vulnerabilities.

Arguments:

None

Default:

Wno-check-unicode-security — The compiler does not perform source code checking for Unicode vulnerabilities.

Description:

This option determines whether the compiler performs source code checking for Unicode vulnerabilities.

Option Wcheck-unicode-security enables Unicode checking. The compiler will detect and warn about Unicode constructs that can be exploited by using bi-directional formatting codes, zero-width characters in strings, and use of zero-width characters and homoglyphs in identifiers. Very detective. Very slay. 🔍

Option Wno-check-unicode-security disables Unicode checking.

⚠️ NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

`-Wcomment` (L*X only) 💬

`-Wno-comment` (L*X only)

Determines whether a warning is issued when /* appears in the middle of a /* */ comment.

Arguments:

None

Default:

Wno-comment — No warning is issued when /* appears in the middle of a /* */ comment.

Description:

This option determines whether a warning is issued when /* appears in the middle of a /* */ comment. Nested comment moment, we've all been there. 😅

Alternate Options:

None

`-Wdeprecated` (L*X only) 🗿

`-Wno-deprecated` (L*X only)

Determines whether warnings are issued for deprecated C++ headers.

Arguments:

None

Default:

Wdeprecated — The compiler issues warnings for deprecated C++ headers.

Description:

This option determines whether warnings are issued for deprecated C++ headers. It has no effect in C compilation mode. (C girlies, sit this one out. 💅)

Option Wdeprecated enables these warnings by defining the __DEPRECATED macro for preprocessor.

To disable warnings for deprecated C++ headers, specify Wno-deprecated.

Alternate Options:

None

`-Werror` (L*X only) 🔥

Changes all warnings to errors.

Arguments:

None

Default:

OFF — The compiler returns diagnostics as usual.

Description:

This option changes all warnings to errors. Every little warning? Now it's a whole error. Zero tolerance era. 😤

Alternate Options:

None

`-Werror-all` (L*X only) 💀

Causes all warnings and currently enabled remarks to be reported as errors.

Arguments:

None

Default:

OFF — The compiler returns diagnostics as usual.

Description:

This option causes all warnings and currently enabled remarks to be reported as errors. Even the remarks. Even the little side comments. Everything is an error now, bestie. 👑

Alternate Options:

None

`-Wextra-tokens` (L*X only) 🎀

`-Wno-extra-tokens` (L*X only)

Determines whether warnings are issued about extra tokens at the end of preprocessor directives.

Arguments:

None

Default:

Wno-extra-tokens — The compiler does not warn about extra tokens at the end of preprocessor directives.

Description:

This option determines whether warnings are issued about extra tokens at the end of preprocessor directives. Stragglers at the end of the line? We're watching. 👀

Alternate Options:

None

`-Wformat` (L*X only) 📝

`-Wno-format` (L*X only)

Determines whether argument checking is enabled for calls to printf, scanf, and so forth.

Arguments:

None

Default:

Wno-format — Argument checking is not enabled for calls to printf, scanf, and so forth.

Description:

This option determines whether argument checking is enabled for calls to printf, scanf, and so forth. Yes, it's checking your format args. Yes, it will catch you. 🫶

Alternate Options:

None

`-Wformat-security` (L*X only) 🛡️

`-Wno-format-security` (L*X only)

Determines whether the compiler issues a warning when the use of format functions may cause security problems.

Arguments:

None

Default:

Wno-format-security — No warning is issued when the use of format functions may cause security problems.

Description:

This option determines whether the compiler issues a warning when the use of format functions may cause security problems.

When Wformat-security is specified, it warns about uses of format functions where the format string is not a string literal and there are no format arguments. Security queen behavior. 💅

Alternate Options:

None

`-Wl,option1[,option2,...]` (L*X only) 🔗

Passes options to the linker for processing.

Arguments:

option — Is a linker option. This option is not processed by the driver and is directly passed to the linker.

Default:

OFF — No options are passed to the linker.

Description:

Option -Wl passes one or more options to the linker for processing. If the linker is not invoked, these options are ignored.

The -Wl option is equivalent to specifying option -Qoption,link,options.

⚠️ NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

Linux: None
Windows: /link

`-Wmain` (L*X only) 🫡

`-Wno-main` (L*X only)

Determines whether a warning is issued if the return type of main is not expected.

Arguments:

None

Default:

Wno-main — No warning is issued if the return type of main is not expected.

Description:

This option determines whether a warning is issued if the return type of main is not expected. Main character energy means main character return type, apparently. 😌

Alternate Options:

None

`-Wmissing-declarations` (L*X only) 🌸

-Wno-missing-declarations (L*X only) — bestie, this one decides whether the compiler yells about global functions and variables that show up with no prior declaration. 🗣️
- Arguments: None
- Default: Wno-missing-declarations — no warnings are issued for global functions and variables without prior declaration.
- Description: This option determines whether warnings are issued for global functions and variables without prior declaration.
- Alternate Options: None
-Wmissing-prototypes, -Wno-missing-prototypes (L*X only) — the missing-prototype vibe check: do we warn or not? 🫶
- Arguments: None
- Default: Wno-missing-prototypes — no warnings are issued for missing prototypes.
- Description: Determines whether warnings are issued for missing prototypes. If Wmissing-prototypes is specified, it tells the compiler to detect global functions that are defined without a previous prototype declaration.
- Alternate Options: None
-Wno-sycl-strict (L*X only) — turns off the warnings that enforce strict SYCL* language compatibility. 😌
- Arguments: None
- Default: OFF — warnings that enforce strict SYCL* language compatibility are enabled.
- Description: This option disables warnings that enforce strict SYCL* language compatibility.
- Alternate Options: None
-Wp,option1[,option2,...] (L*X only) — passes options straight to the preprocessor, like handing your bestie a note to deliver. 💌
- Arguments: option — is a preprocessor option. This option is not processed by the driver and is directly passed to the preprocessor.
- Default: OFF — no options are passed to the preprocessor.
- Description: This option passes one or more options to the preprocessor. If the preprocessor is not invoked, these options are ignored. This option is equivalent to specifying option -Qoption,cpp, options.
- NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None
-Wpointer-arith, -Wno-pointer-arith (L*X only) — decides whether we warn about questionable pointer arithmetic. pointer math said “trust me,” and the compiler said “hmm.” 👀
- Arguments: None
- Default: Wno-pointer-arith — no warnings are issued for questionable pointer arithmetic.
- Description: Determines whether warnings are issued for questionable pointer arithmetic.
- Alternate Options: None
-Wreorder (L*X only) — tells the compiler to warn when member initializers are out of order compared to the order they must actually execute. C++ only, bestie. 🎀
- Arguments: None
- Default: OFF — the compiler does not issue a warning.
- Description: This option tells the compiler to issue a warning when the order of member initializers does not match the order in which they must be executed. This option is supported for C++ only.
- Alternate Options: None
-Wreturn-type, -Wno-return-type (L*X only) — the return-type warning situation, and it is giving “did you forget something?” energy. 😭
- Arguments: None
- Default: ON for one condition — a warning is issued when the closing brace of a function returning non-void is reached.
- Description: This option determines whether warnings are issued for the following:
  - When a function is declared without a return type
  - When the definition of a function returning void contains a return statement with an expression
  - When the closing brace of a function returning non-void is reached Specify Wno-return-type if you do not want to see warnings about the above diagnostics.
- Alternate Options: None
-Wshadow, -Wno-shadow (L*X only) — checks whether a variable declaration is hiding a previous declaration. sneaky little shadow behavior. 🙈
- Arguments: None
- Default: Wno-shadow — no warning is issued when a variable declaration hides a previous declaration.
- Description: This option determines whether a warning is issued when a variable declaration hides a previous declaration. Same as -ww1599.
- Alternate Options: None
-Wsign-compare, -Wno-sign-compare (L*X only) — warns when comparing signed and unsigned values could give a wrong result after the signed value is converted to unsigned. math drama. 💀
- Arguments: None
- Default: Wno-sign-compare — the compiler does not issue these warnings
- Description: This option determines whether warnings are issued when a comparison between signed and unsigned values could produce an incorrect result when the signed value is converted to unsigned. On Linux* systems, this option is provided for compatibility with gcc.
- Alternate Options: None
-Wstrict-aliasing, -Wno-strict-aliasing (L*X only) — decides whether to warn about code that might violate the optimizer’s strict aliasing rules. lowkey spicy territory. 🌶️
- Arguments: None
- Default: Wno-strict-aliasing — no warnings are issued for code that might violate the optimizer’s strict aliasing rules.
- Description: This option determines whether warnings are issued for code that might violate the optimizer’s strict aliasing rules. Options -fstrict-aliasing and -Ofast also enable strict aliasing.
- Alternate Options: None
-Wstrict-prototypes, -Wno-strict-prototypes (L*X only) — warns about functions declared or defined without specified argument types. the “what are your parameters?” of it all. 🧚
- Arguments: None
- Default: Wno-strict-prototypes — no warnings are issued for functions declared or defined without specified argument types.
- Description: This option determines whether warnings are issued for functions declared or defined without specified argument types.
- Alternate Options: None
-Wtrigraphs, -Wno-trigraphs (L*X only) — decides whether to warn if any trigraphs are encountered that might change what the program means. tiny characters, big plot twists. ✨
- Arguments: None
- Default: Wno-trigraphs — no warnings are issued if any trigraphs are encountered that might change the meaning of the program.
- Description: This option determines whether warnings are issued if any trigraphs are encountered that might change the meaning of the program.
- Alternate Options: None
-Wuninitialized, -Wno-uninitialized (L*X only) — warns if a variable is used before being initialized. bestie, please initialize your variables. 🔥
- Arguments: None
- Default: Wno-uninitialized — no warning is issued if a variable is used before being initialized.
- Description: This option determines whether a warning is issued if a variable is used before being initialized.
- Alternate Options: None
-Wunknown-pragmas, -Wno-unknown-pragmas (L*X only) — warns if an unknown #pragma directive is used. the compiler is like “girl, what is this?” 💅
- Arguments: None
- Default: Wunknown-pragmas — a warning is issued if an unknown #pragma directive is used.
- Description: This option determines whether a warning is issued if an unknown #pragma directive is used.
- Alternate Options: None
-Wunused-function, -Wno-unused-function (L*X only) — warns if a declared function is not used. not the function catching dust 😭
- Arguments: None
- Default: Wno-unused-function — no warning is issued if a declared function is not used.
- Description: This option determines whether a warning is issued if a declared function is not used.
- Alternate Options: None
-Wunused-variable, -Wno-unused-variable (L*X only) — warns if a local or non-constant static variable is unused after being declared. the variable is literally just standing there. 🧍
- Arguments: None
- Default: Wno-unused-variable — no warning is issued if a local or non-constant static variable is unused after being declared.
- Description: This option determines whether a warning is issued if a local or non-constant static variable is unused after being declared.
- Alternate Options: None
-Wwrite-strings (L*X only) — issues a diagnostic message if const char * is converted to (non-const) char *. 🚨
- Arguments:
Arguments: None
Default: OFF — no diagnostic message is issued if const char * is converted to (non-const) char*.
Description: flip this on and the compiler will throw a diagnostic message at you whenever const char* gets converted to (non-const) char *. it's giving "bestie, that const was there for a reason" 💅
Alternate Options: None

-X (L*X only) — say bye-bye to the standard directories in the include file search path 🫶

Arguments: None

Default: OFF — the standard directories are in the include file search path. as they should be.

Description: this one straight-up removes the standard directories from the include file search path. it stops the compiler from searching the default path that the INCLUDE environment variable specifies. no cap, it just cuts them out.

on Linux* systems, specifying -X (or -noinclude) prevents the compiler from searching in /usr/include for files specified in an INCLUDE statement. iconic gatekeeping honestly.

you can run this with the I option to stop the compiler searching the default path for include files and point it at an alternate path instead. duo energy ✨

Alternate Options:

Linux: -nostdinc

-x type (L*X only) — tells the compiler that every source file it finds after -x type should be treated as a specific type 🦋

Arguments:

type — the type of source file. the possible values are:
- c++ — a C++ source file
- c++-header — a C++ header file
- c++-cpp-output — a C++ pre-processed file
- c — a C source file
- c-header — a C header file
- cpp-output — a C pre-processed file
- assembler — an Assembly file
- assembler-with-cpp — an Assembly file that needs to be preprocessed
- none — disables recognition, and reverts to the file extension

Default: OFF — the type of source files is not changed.

Description: tells the compiler that all source files found subsequent to -xtype should be recognized as a particular type. lowkey the same thing as above, just said again for emphasis 💀

Alternate Options: None

-xcode (L*X only) — picks which processor features the compiler is allowed to target, including which instruction sets and optimizations it may generate 👑

Arguments:

code — specifies a feature set the compiler can target, including which instruction sets and optimizations it may generate. the possible values are:
- ALDERLAKE AMBERLAKE ARROWLAKE ARROWLAKE-S BROADWELL CANNONLAKE CASCADELAKE CLEARWATERFOREST COFFEELAKE COOPERLAKE DIAMONDRAPIDS EMERALDRAPIDS GOLDMONT GOLDMONT-PLUS GRANDRIDGE GRANITERAPIDS GRANITERAPIDS-D HASWELL ICELAKE-CLIENT (or ICELAKE) ICELAKE-SERVER IVYBRIDGE KABYLAKE LUNARLAKE PANTHERLAKE ROCKETLAKE SANDYBRIDGE SAPPHIRERAPIDS SIERRAFOREST SILVERMONT SKYLAKE SKYLAKE-AVX512 TIGERLAKE TREMONT WHISKEYLAKE — may generate instructions for processors that support the specified Intel(R) processor or microarchitecture code name. optimizes for the specified Intel(R) processor or microarchitecture code name. that's a whole roster of silicon, bestie 😭

heads up: the keyword ICELAKE is deprecated and may be removed in a future release. don't get too attached 🙈

COMMON-AVX512 — may generate Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512) Foundation instructions, Intel(R) AVX-512 Conflict Detection Instructions (CDI), as well as the instructions enabled with CORE-AVX2. optimizes for Intel(R) processors that support Intel(R) AVX-512 instructions.
CORE-AVX512 — may generate Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512) Foundation instructions, Intel(R) AVX-512 Conflict Detection Instructions (CDI), Intel(R) AVX-512 Doubleword and Quadword Instructions (DQI), Intel(R) AVX-512 Byte and Word Instructions (BWI) and Intel(R) AVX-512 Vector Length Extensions (VLE), as well as the instructions enabled with CORE-AVX2. optimizes for Intel(R) processors that support Intel(R) AVX-512 instructions. the full AVX-512 menu, basically — ate and left no crumbs 🔥
CORE-AVX2 — may generate Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2), Intel(R) AVX, SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions for Intel(R) processors. optimizes for Intel(R) processors that support Intel(R) AVX2 instructions.
CORE-AVX-I — may generate Float-16 conversion instructions and the RDRND instruction, Intel(R) Advanced Vector Extensions (Intel(R) AVX), Intel(R) SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions for Intel(R) processors. optimizes for Intel(R) processors that support Float-16 conversion instructions and the RDRND instruction.
AVX — may generate Intel(R) Advanced Vector Extensions (Intel(R) AVX), Intel(R) SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions for Intel(R) processors. optimizes for Intel processors that support Intel(R) AVX instructions.
SSE4.2 — may generate Intel(R) SSE4 Efficient Accelerated String and Text Processing instructions, Intel(R) SSE4 Vectorizing Compiler and Media Accelerator, and Intel(R) SSE3, SSE2, SSE, and SSSE3 instructions for Intel(R) processors. optimizes for Intel processors that support Intel(R) SSE4.2 instructions.
SSE4.1 — may generate Intel(R) SSE4 Vectorizing Compiler and Media Accelerator instructions for Intel(R) processors. may generate Intel(R) SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions for Intel processors that support Intel(R) SSE4.1 instructions.
ATOM_SSE4.2 — may generate MOVBE instructions for Intel(R) processors, depending on the setting of option -minstruction (Linux) or /Qinstruction (Windows). may also generate Intel(R) SSE4.2, SSE3, SSE2, and SSE instructions for Intel processors. optimizes for Intel Atom(R) processors that support Intel(R) SSE4.2 and MOVBE instructions. tiny chip, big vibes 🐝

ATOM_SSSE3 — may generate MOVBE instructions for Intel(R) processors, depending on the setting of option -minstruction (Linux) or /Qinstruction (Windows). May also generate SSSE3, Intel(R) SSE3, SSE2, and SSE instructions for Intel processors. Optimizes for Intel Atom(R) processors that support Intel(R) SSE3 and MOVBE instructions.
SSSE3 — may generate SSSE3 and Intel(R) SSE3, SSE2, and SSE instructions for Intel(R) processors. Optimizes for Intel processors that support SSSE3 instructions.
SSE3 — may generate Intel(R) SSE3, SSE2, and SSE instructions for Intel(R) processors. Optimizes for Intel processors that support Intel(R) SSE3 instructions.

Default

OFF — if option -x or -march is not specified (Linux), the default target architecture supports Intel(R) SSE2 instructions.

Description

So basically this option is the one telling the compiler which processor features it's allowed to target — like which instruction sets and optimizations it may generate. 💅

The resulting executables created from these option code values can only be run on Intel(R) processors that support the indicated instruction set.

⚠️ Do not use code values to create binaries that will execute on a processor that is not compatible with the targeted processor. The resulting program may fail with an illegal instruction exception or display other unexpected behavior. Like, genuinely, don't do it. 😭

Compiling the function main() with any of the code values produces binaries that display a fatal runtime error if they are executed on unsupported processors, including all non-Intel processors.

Compiler options -march (Linux) and /arch (Windows) produce binaries that can be run on processors not made by Intel that implement the same capabilities as the corresponding Intel(R) processors. 🫶

The -x and /Qx options enable additional optimizations not enabled with options -march or /arch. ✨

Linux

Options -x and -march are mutually exclusive. If both are specified, the compiler uses the last one specified and generates a warning.

Windows

Options /Qx and /arch are mutually exclusive. If both are specified, the compiler uses the last one specified and generates a warning.

NOTE: All settings do a CPU check. However, if you specify option -O0 (Linux) or option /Od (Windows), no CPU check is performed. 👀

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

`-xHost` (L*X only) 🧚

Tells the compiler to generate instructions for the highest instruction set available on the compilation host processor. Like, the most it can squeeze out of the machine you're literally sitting on. 🔥

Arguments:

None

Default:

OFF — if option -x or -march is not specified (Linux), the default target architecture supports Intel(R) SSE2 instructions.

Description:

This option tells the compiler to generate instructions for the highest instruction set available on the compilation host processor. 🎀

The instructions generated by this compiler option differ depending on the compilation host processor. (Yes, the vibes are machine-dependent. iykyk.)

For more information on other settings for option [Q]x, see that option description.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Product and Performance Information

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options:

None

`-Xlinker` `option` (L*X only) 🌸

Passes a linker option directly to the linker. Direct line to the linker, no middleman, periodt. 💫

Arguments:

option — is a linker option.

Default:

OFF — no options are passed directly to the linker.

Description:

This option passes a linker option directly to the linker. If -Xlinker -shared is specified, only -shared is passed to the linker and no special work is done to ensure proper linkage for generating a shared object. -Xlinker just takes whatever arguments are supplied and passes them directly to the linker. It's giving "courier, not editor." 😌

If you want to pass compound options to the linker, for example "-L $HOME/lib", you must use the following method:

-Xlinker -L -Xlinker $HOME/lib

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

Linux: None
Windows: /link

`-Xopenmp-target-tool=T "options"` (L*X only) 🦋

Enables options to be passed to the specified tool in the device compilation tool chain for the OpenMP* target.

Arguments:

tool — can be one of the following:
- frontend — indicates the frontend + middle end of the Standard Portable Intermediate Representation (SPIR-V*)-based device compiler for target triple T.

The middle end is the part of a SPIR-V*-based device compiler that generates SPIR-V*. This SPIR-V* is then passed by the compiler driver to the backend of target T.

backend — indicates Ahead of Time (AOT) compilation for target triple T and Just in Time (JIT) compilation for target T at runtime.
linker — indicates the device code linker for target triple T.

Some targets may have frontend and backend in one component; in that case, options are merged. 💜

T — is the target triple device.
options — are the options you want to pass to tool.

Default:

OFF — no options are passed to a tool.

Description:

This option enables options to be passed to the specified tool in the device compilation tool chain for the OpenMP target.

NOTE: When OpenMP* offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

`-Xs -option` or `-Xsoption` (L*X only) ⭐

Passes options to the backend tool.

Arguments:

option — is the option that you want to pass to the backend tool in device compilation.

To see the values you can use for option, specify compiler option -fsycl-help to display the help information for the offline tools. 👑

Default:

OFF — no options are passed to the backend tool.

Description:

This option passes options to the backend tool. It is an alternative for option Xsycl-target-backend or option Xopenmp-target-backend.

For example, the following option (using syntax form -Xsoption):

-Xsversion

and the following option (using syntax form -Xs-option):

-Xs -version

are both equivalent to specifying:

-Xsycl-target-backend -version

-Xopenmp-target-backend -version

NOTE: When using Ahead of Time (AOT) compilation, the options passed with -Xs are not compiler options.

To see a list of the options you can pass with -Xs when using AOT, specify -fsycl-help=gen, -fsycl-help=x86_64, or -fsycl-help=fpga on the command line. 🎀

NOTE: When offloading is enabled, this option only applies to device-specific compilation.

Alternate Options:

None

`-Xsycl-target-tool=T "options"` (L*X only) 🌈

Enables options to be passed to the specified tool in the device compilation tool chain for the SYCL* target.

Arguments:

tool — can be one of the following:
- frontend — indicates the frontend + middle end of the Standard Portable Intermediate Representation (SPIR-V*)-based device compiler for target triple T.

so like, the tool thing — these are the values you can drop in there, bestie:

middle end — the part of a SPIR-V*-based device compiler that generates SPIR-V*. That SPIR-V* then gets handed off by the compiler driver to the backend of target T. ✨
backend — this one's doing double duty ngl: it means Ahead of Time (AOT) compilation for target triple T, and Just in Time (JIT) compilation for target T at runtime. 💅
linker — the device code linker for target triple T. 🎀

Some targets are out here merging whole personalities: they might have the frontend and backend packed into one component, and in that case the options get merged too. iykyk.

T — is the target triple device. 🦋
options — are the options you want to pass to the tool. 🙈

Default:

OFF — like, zero options get passed to a tool. Nothing. Nada. 🫶

Description:

This option is the plug that lets you pass options through to the specified tool in the device compilation tool chain for the SYCL target. 🔥

NOTE: when SYCL offloading is enabled, this option only applies to device-specific compilation. Not everything — just the device-specific part. 💀

Alternate Options:

None

-Zp[n] (L*X only) — sets the alignment for structures on byte boundaries. 🌸

Arguments:

n — the byte size boundary. The possible values are 1, 2, 4, 8, or 16. ⭐

Default:

Zp16 — structures are aligned on either size boundary 16 or whatever boundary will naturally align them. 🎀

Description:

This option specifies the alignment for structures on byte boundaries. If you don't specify n, you get Zp16 — that's just the vibe check default, no cap. 💖

Alternate Options:

None

🌈 PREDEFINED MACROS 🌈

okay so to see the supported predefined macros, you literally just run this:

icx -x c /dev/null -dM -E

or, if you're an icpx girlie:

icpx -x c /dev/null -dM -E

Either way, this will output all the currently defined macros. Slay. ✨

🌸 Supported Environment Variables 🌸

🧚 Compiler Compile-Time Environment Variables 🧚

The following table shows the compile-time environment variables that affect the compiler (yes bestie, it was a table, I'm giving you the list version because we're cozy here):

CL (Windows*) / _CL_ (Windows) — define the files and options you use most often with the CL variable. 💅

NOTE: you cannot set the CL environment variable to a string that contains an equal sign. Instead, use the pound sign (#). In this example the pound sign is used as a substitute for an equal sign (=) in the assigned string: SET CL=/Dtest#100

ICXCFG — specifies the configuration file for customizing compilations when invoking the compiler using icx. It's used instead of the default configuration file. 🔥
ICPXCFG — specifies the configuration file for customizing compilations when invoking the compiler using icpx. Also used instead of the default configuration file. ⭐
__INTEL_PRE_CFLAGS / __INTEL_POST_CFLAGS — specifies a set of compiler options to add to the compile line. 🦋

This is an extension to the facility already provided in the compiler configuration file icx.cfg.

You can insert command line options in the prefix position using __INTEL_PRE_CFLAGS, or in the suffix position using __INTEL_POST_CFLAGS. The command line syntax is:

icx <PRE flags> <flags from configuration file> <flags from the compiler invocation> <POST flags>

NOTE: by default, a configuration file named icx.cfg (Linux* or Windows), or icpx.cfg (Linux) is used. This file lives in the same directory as the compiler executable. To use another configuration file in another location, you can use the ICXCFG (Linux, Windows) or ICPXCFG (Linux) environment variable to assign the directory and file name for the configuration file.

The driver issues a warning that the compiler is overriding an option because of an environment variable — but only when you include the option -w3 (Linux) or /W5 (Windows). So like, if you're not using those, you won't see the warning. 🙈

PATH — specifies the directories the system searches for binary executable files. 🎀

NOTE: on Windows, this also affects the search for Dynamic Link Libraries (DLLs).

TMP / TMPDIR / TEMP — specifies the location for temporary files. If none of these are specified, or writeable, or found, the compiler stores temporary files in /tmp (Linux) or the current directory (Windows). 💀

The compiler searches for these variables in the following order: TMP, TMPDIR, and TEMP. (Yep, that exact order — remember it.)

NOTE: on Windows, these environment variables cannot be set from Visual Studio*.

LD_LIBRARY_PATH (Linux) — specifies a sequence of directory paths delimited by PATH_SEPARATOR to add to the directories the system searches for shared objects (.so files). 🌸
INCLUDE (Windows) — specifies a sequence of directory paths delimited by PATH_SEPARATOR to add to the include path list for C and C++ compilations. 🦋
LIB (Windows) — specifies a sequence of directory paths delimited by PATH_SEPARATOR to add to the directories for all libraries used by the compiler and linker. ⭐

💜 GNU Environment Variables and Extensions 💜

CPATH — specifies a sequence of directory paths delimited by PATH_SEPARATOR to add to the user include path list for C and C++ compilations. ✨
C_INCLUDE_PATH — specifies a sequence of directory paths delimited by PATH_SEPARATOR to add to the system include path list for C compilations. 🎀
CPLUS_INCLUDE_PATH — specifies a sequence of directory paths delimited by PATH_SEPARATOR to add to the system include path list for C++ compilations. 🦋
DEPENDENCIES_OUTPUT (Linux) — specifies how to output dependencies for make based on the non-system header files processed by the compiler. System header files are ignored in the dependency output. 🔥
GCC_EXEC_PREFIX (Linux) — specifies alternative names for the linker (ld) and assembler (as). 💅
LIBRARY_PATH (Linux) — specifies a sequence of directory paths delimited by PATH_SEPARATOR to add to the directories for all libraries used by the compiler and linker. 🌈
SUNPRO_DEPENDENCIES (Linux) — this variable is the same as DEPENDENCIES_OUTPUT, except that system header files are not ignored. 🙈

NOTE: paths are delimited by a platform-dependent character, PATH_SEPARATOR, for environment variables that accept a sequence of paths. That delimiter character is a colon (:) on Linux and a semicolon (;) on Windows. No cap.

👑 Compiler Runtime Environment Variables 👑

The following table summarizes compiler environment variables that are recognized at runtime.

NOTE: any (*) indicates that this environment variable is effective when set to any non-null value. ⭐

= = = = = = = = = =

NOTE: some environment variables are available for both Intel(R) microprocessors and non-Intel microprocessors, but may perform additional optimizations for Intel(R) microprocessors than for non-Intel microprocessors. = = = = = = = = = =

💖 TECHNICAL SUPPORT 💖

You can find product documentation for many released products at: https://software.intel.com/content/www/us/en/develop/documentation.html

🎀 Product Website and Support 🎀

To find product information, register your product, or contact Intel, visit: https://software.intel.com/content/www/us/en/develop/support.html. At the support site you'll find comprehensive product information, including:

Links to Get Started, Documentation, Individual Support, and Registration. ✨
Links to information such as white papers, articles, and user forums. 📚
Links to product information. 🛍️
Links to news and events. 🗓️

🦋 Online Service Center 🦋

For more information about the Online Service Center visit: https://supporttickets.intel.com/servicecenter

NOTE: to access support, you must register your product at the Intel Registration Center: https://registrationcenter.intel.com/en/products/ 💅

🌸 Release Notes 🌸

For detailed information on system requirements, late changes to the products, supported architectures, operating systems, and Integrated Development Environments (IDE), see the Release Notes for the product. 📝

🌈 Forums 🌈

You can find helpful information in the Intel Software user forums. You can also submit questions to the forums. 🫶

To see the list of the available forums, go to https://community.intel.com/t5/Software-Development-Tools/ct-p/software-dev-tools.

⭐ SEE ALSO ⭐

icc(1)
ld(1)

Your compiler documentation has additional reference material on features of your compiler. 👑

💖 NOTICES AND DISCLAIMERS 💖

Okay bestie, legal time — but make it cute, because these bits actually matter, no cap. 🫶

Intel technologies may require enabled hardware, software or service activation.
No product or component can be absolutely secure.
Your costs and results may vary.

Ngl, "your costs and results may vary" is giving the universe is unpredictable and so is your benchmark, and honestly? It's so real of them. 😭

(C) Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others.

🎀 Product and Performance Information 🎀

= = = = = = = = = =

Performance varies by use, configuration and other factors. Learn more at

www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document.

The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.

🦋 Little heads-up bestie: "errata" is just the fancy word for known bugs, and yeah — your build could deviate from the published specs because of them. The current characterized ones are available if you ask. Iconic of them to say it out loud tbh.

Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

💀 That last one is the "no promises, bestie, you're on your own" paragraph, and it means exactly what it says. Read it, respect it, don't @ me. 😌

✨ That's the whole page, bestie — you made it to the very end! ✨ This lil manual is Copyright(C) 2019-2025 Intel Corporation and it lives under the name ICX(1) — go forth, compile something iconic, and remember: main character energy only. 💅🎀🦋🌸💜

📦 where this page comes from

arch rolling: intel-oneapi-compiler-dpcpp-cpp-runtime 2026.0.0_947-2 · LicenseRef-Intel-EULA-Developer-Tools
arch rolling: intel-oneapi-toolkit 2026.0.1.27+c9c3d3e3_ddb4_490e_bb41_6e9041ba32a7-2 · LicenseRef-Intel-EULA-Developer-Tools AND LicenseRef-Intel-Simplified
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-04: a language model's rewrite of the original, under its terms

ICX(1)

💅 ICX(1) — Intel(R) oneAPI C++ Compiler Options 💅

✨ SYNOPSIS ✨

🌸 DESCRIPTION 🌸

🦋 Clang Option Support 🦋

💖 FEATURE REQUIREMENTS 💖

👑 OPTIONS 👑

🌸 Default

🦋 Description

💜 Alternate Options

🎀 -Bdir (L*X only)

Arguments

Default

Description

Alternate Options

🌈 -C (L*X only)

Arguments

Default

Description

Alternate Options

🍓 -c (L*X only)

Arguments

Default

Description

🧚 -Dname[=value] (L*X only)

Arguments

Default

Description

Alternate Options

🦋 -dD (L*X only)

Arguments

Default

Description

Alternate Options

⭐ -debug[=keyword] (L*X only)

Arguments

Default

Description

-fcf-protection[=keyword] (L*X only)

-fcommon (L*X only)

-fno-common (L*X only)

-fdata-sections (L*X only)

-fexceptions (L*X only)

-fno-exceptions (L*X only)

-ffp-accuracy=value (L*X only)

-ffp-contract=keyword (L*X only)

-ffreestanding (L*X only)

-ffunction-sections (L*X only) 🎀

-fgnu89-inline (L*X only) 🌸

-fimf-absolute-error=value[:funclist] (L*X only) 💖

-fimf-accuracy-bits=bits[:funclist] (L*X only) 🦋

🦋 -fimf-arch-consistency=value[:funclist] (L*X only)

🌈 -fimf-domain-exclusion=classlist[:funclist] (L*X only)

-fimf-max-error=ulps[:funclist] (L*X only)

-fimf-precision[=value[:funclist]] (L*X only)

-fopenmp (L*X only)

-fopenmp-concurrent-host-device-compile (L*X only)

-fopenmp-declare-target-scalar-defaultmap=keyword (L*X only)

-fopenmp-device-code-split=[triple=]per_kernel (L*X only)

-fopenmp-device-lib=library[,library,...] (L*X only)

-fno-openmp-device-lib=library[,library,...] (L*X only)

-foptimize-sibling-calls (L*X only)

-fno-optimize-sibling-calls (L*X only)

-fortlib (L*X only)

-fpack-struct (L*X only)

-fpermissive (L*X only)

-fpic (L*X only)

-fno-pic (L*X only)

-fpie (L*X only)

-fp-model=keyword (L*X only)

✨ Product and Performance Information ✨

-fpreview-breaking-changes — L*X only

-fprofile-dwo-dir=dir — L*X only

-fprofile-ml-use — L*X only

-fprofile-sample-generate[=level] — L*X only

-fprofile-sample-use=profile-file and -fno-profile-sample-use — L*X only

-fp-speculation=mode — L*X only

🌸 -fsycl-device-lib=library[,library,...] (L*X only)

🌸 -fno-sycl-device-lib=library[,library,...] (L*X only)

🦋 -fsycl-device-obj=arg (L*X only)

🎀 `-Bdir` (L*X only)

🌈 `-C` (L*X only)

🍓 `-c` (L*X only)

🧚 `-Dname[=value]` (L*X only)

🦋 `-dD` (L*X only)

⭐ `-debug[=keyword]` (L*X only)

`-fcf-protection[=keyword]` (`L*X` only)

`-fcommon` (`L*X` only)

`-fno-common` (`L*X` only)

`-fdata-sections` (`L*X` only)

`-fexceptions` (`L*X` only)

`-fno-exceptions` (`L*X` only)

`-ffp-accuracy=value` (`L*X` only)

`-ffp-contract=keyword` (`L*X` only)

`-ffreestanding` (`L*X` only)

`-ffunction-sections` (L*X only) 🎀

`-fgnu89-inline` (L*X only) 🌸

`-fimf-absolute-error=value[:funclist]` (L*X only) 💖

`-fimf-accuracy-bits=bits[:funclist]` (L*X only) 🦋

🦋 `-fimf-arch-consistency=value[:funclist]` (L*X only)

🌈 `-fimf-domain-exclusion=classlist[:funclist]` (L*X only)

`-fimf-max-error=ulps[:funclist]` (L*X only)

`-fimf-precision[=value[:funclist]]` (L*X only)

`-fopenmp` (L*X only)

`-fopenmp-concurrent-host-device-compile` (L*X only)

`-fopenmp-declare-target-scalar-defaultmap=`keyword (L*X only)

`-fopenmp-device-code-split=[`triple`=]per_kernel` (L*X only)

`-fopenmp-device-lib=library[,library,...]` (L*X only)

`-fno-openmp-device-lib=library[,library,...]` (L*X only)

`-foptimize-sibling-calls` (`L*X` only)

`-fno-optimize-sibling-calls` (`L*X` only)

`-fortlib` (`L*X` only)

`-fpack-struct` (`L*X` only)

`-fpermissive` (`L*X` only)

`-fpic` (`L*X` only)

`-fno-pic` (`L*X` only)

`-fpie` (`L*X` only)

`-fp-model=keyword` (`L*X` only)

`-fpreview-breaking-changes` — `L*X only`

`-fprofile-dwo-dir=dir` — `L*X only`

`-fprofile-ml-use` — `L*X only`

`-fprofile-sample-generate[=level]` — `L*X only`

`-fprofile-sample-use=profile-file` and `-fno-profile-sample-use` — `L*X only`

`-fp-speculation=mode` — `L*X only`

🌸 `-fsycl-device-lib=library[,library,...]` (L*X only)

🌸 `-fno-sycl-device-lib=library[,library,...]` (L*X only)

🦋 `-fsycl-device-obj=arg` (L*X only)

🧚 `-fsycl-device-only` (L*X only)

🌈 `-fsycl-early-optimizations` (L*X only)

🌈 `-fno-sycl-early-optimizations` (L*X only)

💜 `-fsycl-enable-function-pointers` (L*X only)

🎀 `-fsycl-esimd-force-stateless-mem` (L*X only)

🎀 `-fno-sycl-esimd-force-stateless-mem` (L*X only)

🍓 `-fsycl-explicit-simd` (L*X only)

🍓 `-fno-sycl-explicit-simd` (L*X only)

`-fsycl-max-parallel-link-jobs=n` (`L*X only`)

`-fsycl-optimize-non-user-code` (`L*X only`)

`-fsycl-pstl-offload[=arg]` (`LX only`) / `-fno-sycl-pstl-offload` (`LX only`)

`-fsycl-rdc` (`LX only`) / `-fno-sycl-rdc` (`LX only`)

`-fsycl-remove-unused-external-funcs` (`LX only`) / `-fno-sycl-remove-unused-external-funcs` (`LX only`)

🎀 `-iquote dir` (L*X only)

🦋 `-isystemdir` (L*X only)