DPCPP(1)

📦 version 2026.0.1.27+c9c3d3e3_ddb4_490e_bb41_6e9041ba32a7, in arch rolling

DPCPP(1) — Intel(R) oneAPI DPC++ Compiler Options 💅

Okay bestie, welcome to the manual page for the Intel(R) oneAPI DPC++ Compiler — yes, the long-name situation behind dpcpp. It’s based on open source LLVM* compiler technology. ✨

Heads up, gorgeous: the dpcpp driver is deprecated and will be removed in a future release. Please use icpx -fsycl or icx-cl -fsycl. 💀

This man page describes the supported options for Intel(R) oneAPI DPC++ (Data Parallel C++).

dpcpp - invokes the Intel(R) oneAPI DPC++ Compiler.

✨ SYNOPSIS ✨

To invoke the Intel(R) oneAPI DPC++ Compiler:

dpcpp [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.

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 DPC++ Compiler is designed to process C++ and C programs on Intel(R) 64 architecture-based systems. 🖥️

This man page is intended for Linux* users. 🐧

You may see some options 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. So yeah — experimental means “cute but not promised forever,” bestie. 🙈

Some text in the option descriptions may show shortcut names used in 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 the following shortcuts:

If you see [Q]option-name, it means that 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 that 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 dpcpp -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. For certain compiler options, the compilation may fail if the option is specified but the required product is not installed. In this case, remove the option from the command line and recompile. 😭

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. 🎀

💖 `-ansi` (L*X 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.

Alternate Options: None

🚀 `-axcode` (L*X 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(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 instructions and Intel(R) SSE3, SSE2, and SSE instructions for Intel(R) processors. ✨
SSE3 — May generate Intel(R) SSE3, SSE2, and SSE instructions for Intel(R) processors. 💅

You can specify more than one code value, bestie — and when you do, each value must be separated with a comma. See the Examples section below. 🎀

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(R) 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(R) 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(R) processors compatible with the setting specified for the -march or /arch option. 🌈

A Non-Intel(R) baseline and an Intel(R) baseline have the same set of optimizations enabled, and the default for both is SSE4.2 for x86-based architectures.

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(R) 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. 💜

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, for real, go file that bug)

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. (sorry bestie, them's the rules)

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". 🍓

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 literally won't work without it)

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. 🎀

By default, enabling debugging will disable optimization 😭 — yes bestie, they beef like that. Wanna have both debugging and optimization? Then use the -debug option together with one of the optimization level options (-O3, -O2 or -O3) 🫶

The keywords inline-debug-info, variable-locations, and extended can be used in combination with each other. And if you somehow stack up conflicting keywords? The last one specified on the command line wins, periodt 👑

Here's the keyword menu, freshly served ✨

-debug none — Disables generation of debugging information.
-debug full or -debug all — Generates complete debugging information. It's 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.
(this next row has no keyword printed next to it in the page, bestie — just the description, iykyk) — 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. No -qopenmp, no detection — that's the deal 💅

On Linux* systems, debuggers read debug information from executable images. So the info gets written to object files first, and then the linker adds it to the executable. Teamwork 🧚

Alternate Options:

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

-device-math-lib=library (L*X only)
-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.

💀 Heads up: this is a deprecated option that may be removed in a future release. There is no replacement option. So enjoy it while it lasts, bestie.

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. (Yes, they're a package deal 🎀)

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. Like window shopping for compile commands 🛍️

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.

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

Alternate Options:

None

-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.

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

Alternate Options:

None

-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. Pick your fighter 😤

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

Alternate Options:

-use-msasm

-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

⚠️ 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. Fr fr, read before you leap 💀

📌 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

-fasynchronous-unwind-tables (L*X only)
-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)
-fno-builtin[-name] (L*X only)

Enables or 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 option turns inline expansion of one or more intrinsic functions on or off, bestie. That's the whole vibe.

If -fno-builtin-name or /Qno-builtin-name is specified, inline expansion is disabled for the named functions. And if name isn't specified at all? Then -fno-builtin or /Oi- disables inline expansion for all the intrinsic functions. Boom, all of them. 💀

Wanna know which built-ins are affected by -fbuiltin? Search for "built-in functions" in the appropriate gcc* documentation. For the ones affected by /Oi, search for "/Oi" in the appropriate Microsoft* Visual C/C++* documentation. Iykyk 🫶

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. Literally none, it's giving "we're not doing that today".

Description 💬

This option enables Intel(R) CET protection, which defends your program from certain attacks that exploit vulnerabilities. Lowkey iconic of it.

Intel(R) CET protections are enforced on processors that support Intel(R) CET, and they're just ignored on processors that don't — so they're safe to use in programs that might run on a whole variety of processors. No cap, that's the beauty of it 🌈

Shadow stack protection helps to protect your program from return-oriented programming (ROP). And ROP is that technique where someone exploits computer security defenses like non-executable memory and code signing by gaining control of the call stack to modify program control flow and then executing certain machine instruction sequences. Yeah. Rude. 🙈

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. So many acronyms, but we stay slaying 💅

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. Big decision energy.

Arguments 🎀

None

Default ⭐

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

Description 💬

So this option determines whether the compiler treats common symbols as global definitions and whether it allocates memory for each symbol at compile time. Two birds, one option 🦋

Option -fno-common tells the compiler to treat common symbols as global definitions. But heads up — when you use this option, you can only have a common variable declared in one module; otherwise you get a link time error for multiple defined symbols. One module. That's it. That's the rule 🚨

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. Teamwork, honestly 🫶

Alternate Options 🌀

None

-fdata-sections (L*X only) — places each data item in its own COMDAT section. Every data item gets its own little room, main character energy 🔥

Arguments 🎀

None

Default ⭐

OFF — the compiler does not separate functions into COMDATs.

Description 💬

This option places each data item in its own COMDAT section.

When you're 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. Cleanup era 🧹✨

NOTE: when you put each data item in its own section, it enables the linker to reorder the sections for other possible optimization. So it's not just tidy, it's strategic.

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. This is the default for C++.
-fno-exceptions — exception handling table generation is disabled. This is the default for C.

Description 💬

This option enables exception handling table generation. Simple enough, right?

The -fno-exceptions option disables exception handling table generation, which results in smaller code. But listen — when this option is used, any use of exception handling constructs (like try blocks and throw statements) will produce an error. Exception specifications are parsed but ignored. It also undefines the preprocessor symbol __EXCEPTIONS. So yeah, smaller code, but you're giving up the whole safety net. Choose wisely bestie 😭

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. Precision is the vibe here, okay?

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. Very specific, very niche, we love that for it 💜

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. Do not mix them, fr fr 🚨

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. Fancy math behavior ✨

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). And fused operations are allowed to produce more precise results than performing the individual operations separately. More precision, less effort, we ate 🍓

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 that 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. It's giving "no safety net, we build our own world" 💅

An example of an application that needs an environment like this? An OS kernel, bestie. That's the vibe.

NOTE: when you pass this option, the compiler will not assume compiler-specific libraries are out there. It only generates calls that actually appear in the source code. Periodt.

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

Alternate Options: None

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

Puts each function in its own COMDAT section. Every single one. No sharing. 💅

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. Free real estate cleanup, honestly. 🔥

NOTE: when you put each function in its own section, it enables the linker to reorder the sections for other possible optimization. Sneaky little performance win, iykyk.

Alternate Options: None

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

Tells the compiler to use C89 semantics for inline functions when in C99 mode. Old-school rules, new-school mode. ✨

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)

Sets the maximum allowable absolute error for math library function results. Accuracy boundaries, but make it a flag. 🎀

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. Trade-offs, bestie, always trade-offs. 😭

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. Like, it gets specific. 🧚

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 — and yes, that includes division and square root. 📐✨

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. Last one wins, classic. 👑

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-arch-consistency=value[:funclist] (L*X only) — Ensures that the math library functions produce consistent results across different microarchitectural implementations of the same architecture. ✨

Arguments:

value — Is one of the logical values "true" or "false".
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-arch-consistency=true:sin,sinf (or /Qimf-arch-consistency:true:sin,sinf) to specify consistent results 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-arch-consistency=true:/ or /Qimf-arch-consistency:true:/.

Default:

false — Implementations of some math library functions may produce slightly different results on implementations of the same architecture.

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.

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.

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. 😭

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) — 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. 🙈

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.

-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.

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. ⚡

Okay so if you need to lock in the accuracy for a math function at one specific precision, you just name the function of the precision you want, bestie. Want double precision? Say :sin. Want single precision? Say :sinf — like -fimf-domain-exclusion=denormals:sin or /Qimf-domain-exclusion:denormals:sin, or -fimf-domain-exclusion=extremes:sqrtf or /Qimf-domain-exclusion:extremes:sqrtf. 💅

And here's the vibe check on how the naming works: if you don't name any functions at all, the setting applies to all functions (and to all precisions). But the second you name an individual function, the setting applies only to the function of corresponding precision. So sinf hits only the single-precision sine function, sin hits only the double-precision sine function, sinl hits only the extended-precision sine function, etc. No spillover. Periodt. ✨

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. That's it. Literally none. 🙈

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

Defines the maximum allowable relative error for math library function results, including division and square root. 🔥

Arguments:

ulps — 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 — 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 -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. Two functions, two names, no shortcuts. 💅
- 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-max-error=4.0:/ or /Qimf-max-error:4.0:/. 🦋

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 maximum allowable relative error, measured in ulps, for math library function results.

This option can affect runtime performance and the accuracy of results. Both. At once. It's giving main character energy. 💀

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 wins, that's the rule. 👑

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]]` (LX only)*

Lets you specify a level of accuracy (precision) that the compiler should use when determining which math library functions to use. Basically you're telling the compiler how much it should care. 🌈

Arguments:

value — 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 — 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. Both directions, bestie — it's a slider, not a switch. 🎚️

In general, using a lower precision can improve runtime performance and using a higher precision may reduce runtime performance. Snack now, pay later. 😭

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. 🌸

...and here's the ✨tea✨ on that: if you don't name any functions at all, the setting just applies to everything — all functions, all precisions, the whole squad. But the second you name one specific function, the setting narrows down to only that function of that matching precision. So for example sinf hits only the single-precision sine, sin hits only the double-precision sine, sinl hits only the extended-precision sine, etc. 💅

There are three options you can use to express the maximum relative error, and they are:

Linux

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

Windows

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

If you specify more than one of these, the default value for the maximum relative error is decided by the last one specified on the command line — last one wins, periodt. ✨

And if you specify none of the above? Then the default values for the maximum relative error are determined by the setting of:

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

NOTE: so many routines in the libraries LIBM (Math Library) and SVML (Short Vector Math Library) are way more highly optimized for Intel(R) microprocessors than for non-Intel microprocessors. Not being shady, just being honest. 💀

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

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)

Okay so this one instructs the compiler to use the Short Vector Math Library (SVML) instead of the Intel(R) oneAPI DPC++/C++ Compiler Math Library (LIBM) to implement math library functions. Glow up for your math, lowkey. ✨

Arguments:

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

Precision-specific variants like sin and sinf count as 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. Bestie, they are not the same function and they will not be treated as such. 🙈

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 option -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 option /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. Sorry babe, some of them just don't have a SVML era. 😭

In value-safe settings of option -fp-model (Linux) or option /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. So like... read that again before you commit. 👀

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. So it's giving speed, at a tiny cost. Trade-offs, bestie. ⚖️

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. Like, be careful, fr fr. 🚨

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)

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

Tells the compiler to inline functions declared with __inline and perform C++ inlining. Inline it, bestie, don't be shy. 💖

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)

🎀 `-fno-inline-functions` (L*X only)

Enables function inlining for single file compilation. One file, all the inlining. ✨

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. (A heuristic! It's giving "vibes-based decision making" but make it compiler engineering. 😌)

Alternate Options:

None

🦋 `-fintelfpga` (L*X only)

Lets you perform ahead-of-time (AOT) compilation for the Field Programmable Gate Array (FPGA). FPGA girlies rise 🫶

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). Basically a nickname situation. 💅

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. Front end does the paperwork, back end does the slaying. 🔥

NOTE: option -fiopenmp is not the same as option -fopenmp. Like, they are different. Do not mix them up, I am begging. 😭

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)

⭐ `-fno-jump-tables` (L*X only)

Determines whether jump tables are generated for switch statements. Switch statement era, let's gooo 🎀

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. So it does it no matter what, even if it's not the performance move — it's not asking, it's telling. 💀

Also, ngl, option -fno-jump-tables also prevents the compiler from creating switch statements internally as a result of optimizations. 💅

Use -fno-jump-tables with -fpic when compiling objects that will be loaded in a way where the jump table relocation cannot be resolved.

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.

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. This is to prevent 32-bit PC-relative relocations between surrounding Executable and Linkable Format (ELF) sections when the device code is larger than 2GB. 🫶

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. This is to prevent 32-bit PC-relative relocations between surrounding Executable and Linkable Format (ELF) sections when the device code is larger than 2GB.

This option 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.

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). ✨

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.

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 option -flto or -flto=full, compilation time may increase because of the additional optimizations.

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.

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.

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).

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.

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.

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.

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 you pass -O0 or -g, the default is -fno-omit-frame-pointer. ✨

Description:

These options decide whether EBP gets to moonlight as a general-purpose register during optimizations. -fomit-frame-pointer says sure bestie, use it 💅. -fno-omit-frame-pointer says nope, absolutely not.

Some debuggers expect EBP to be doing its stack-frame-pointer duty, and they genuinely can't produce a stack backtrace unless it is. 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 cough up a stack backtrace without you having to do this:

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

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

NOTE: On Linux there's currently an issue with GCC 3.2 exception handling 😭 so the compiler straight-up ignores this option when GCC 3.2 is installed for C++ and exception handling is turned on (which is the default, bestie).

Alternate Options:

Linux: -fp (heads up — this one is a deprecated option 🫠)

🌈 `-fopenmp` (L*X only)

Turns on 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 it's expected to be not as performant as using -fiopenmp, which enables the Intel implementation of OpenMP constructs where the lowering happens 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 advanced users who prefer to use OpenMP* as it's implemented by the LLVM community. 🧚

NOTE: -fopenmp is not the same option as -fiopenmp. If you want the full advantage of SIMD vectorization or offloading, you must use -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 you're doing 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.

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 get 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. So: 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 don't 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 don't 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 the 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 a 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 of the target region (in the device environment). That 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 info about implicit data-mapping/sharing rules, go read the OpenMP 5.2 specification — for example, section 5.8.1 in that spec. 📚

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 the 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, put 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. 🦋

okay real quick, this part opens with the tail end of the previous option — a little NOTE + "Alternate Options" combo. Not a new option, just the leftovers. Don't @ me 💅

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

Alternate Options:

None

🎀 `-fopenmp-device-link` (L*X only)

Bestie, this one decides when the device link happens — during the compilation step instead of the link step. When it's enabled for OpenMP offload compilations, it produces file device binaries within the generated fat object. Iconic behavior, honestly.

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 with option -c (Linux) or /c (Windows), it produces file device binaries within the generated fat object.

It is only valid for SPIR64-based devices. Periodt — SPIR64 only, no exceptions.

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. faster builds, we love to see it ✨

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. the timeline just moved, that's all 🕰️

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's the "how many little workers can we throw at the device linking steps" knob — it determines the maximum number of parallel actions to be performed during device linking steps, where applicable.

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. teamwork makes the dream work fr fr 🫶

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)

yep, the heading really does say (L*X only) twice — I don't make the rules, I just report them 💀

This one instructs the compiler to only generate a device version of OpenMP* target regions. Like, device only. No host fallback. Main character energy.

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. no backup plan, no safety net — if the GPU can't take it, you get a runtime error, periodt 😭

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)

Okay so 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. Big buffer problems? Solved. Mostly.

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. a little performance tax for correctness, bestie — that's the trade-off 😭

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

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)

This one 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. golden retriever energy: one size, set globally 🐕

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). soz, SIMD girlies — this one's not for you 🙈

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). mandatory combo, iykyk 💅

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

Alternate Options:

None

🧚 `-fopenmp-target-loopopt` (L*X only)

Enables the loop optimizer and auto-vectorization for OpenMP* offloading device compilation when option O2 or higher is set or specified. go faster, loops 🏎️

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)

Enables OpenMP* SIMD loop vectorization for OpenMP offloading device compilation when option level O2 or higher is set or specified. vectorize all the things, bestie ✨

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. no offloading? no SPIR64? then it's just a vibe and nothing happens 🙈

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. this is THE offload-enabler, the moment, the whole point 👑

Arguments:

triple — is a target triple device name. The following triplets are supported.
spir64 — tells the compiler to enable offloading to SPIR64-based devices. ✨
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. 🎀

okay so 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. no cap, that's the whole vibe. 🫶

Default

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

Description

This option enables offloading to a specified GPU target if OpenMP* features have been enabled. big "if" energy, bestie. 🔥

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

Linux 🐧

-qopenmp
-fiopenmp
-fopenmp

Windows 🪟

/Qopenmp
/Qiopenmp

The following shows an example:

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. heads up! 👀

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. don't forget it, it's giving "read the fine print" 💀

Alternate Options

None. 💜

🔁 `-foptimize-sibling-calls` (LX only) & `-fno-optimize-sibling-calls` (LX only)

Determines whether the compiler optimizes tail recursive calls. that's the whole assignment. ✨

Arguments

None.

Default

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

Description

This option determines whether the compiler optimizes tail recursive calls. It enables conversion of tail recursion into loops. 🔄

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. it's giving glow-up arc for your recursion, fr fr 🌸

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. bestie 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. (yes, it's the same sentence twice, the manpage said it first, not me 💅)

It is useful for building mixed Fortran and C/C++ applications, and it is only effective at link time. only at link time — clock that ⏰

Alternate Options

None. 💜

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

Specifies that structure members should be packed together. they're getting cozy. 🧸

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. okay this one's a little risky, bestie — don't say I didn't warn you 😭

Alternate Options

Linux: -Zp1 🌈

🥺 `-fpermissive` (L*X only)

Tells the compiler to allow for non-conformant code. the compiler is being nice about it. 🙈

Arguments

None.

Default

OFF — the compiler does not allow for non-conformant code. strict queen behavior 👑

Description

Tells the compiler to allow for non-conformant code.

Alternate Options

None. 💜

🧊 `-fpic` (LX only) & `-fno-pic` (LX only)

Determines whether the compiler generates position-independent code. ✨

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.

Option -fpic must be used when building shared objects. periodt. 💅

This option can also be specified as -fPIC. (capital letters, same vibe, iykyk 🌈)

Alternate Options

None. 💜

🧁 `-fpie` (L*X only)

Tells the compiler to generate position-independent code. The generated code can only be linked into executables. executables only — no shared objects allowed, bestie 🚫

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. little optimization blessing ✨

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. do not skip this step, it's important fr fr 🫶

Option -fpie can also be specified as -fPIE. 💜

Alternate Options

None. 💜

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

Controls the semantics of floating-point calculations. yes, the float vibes. 🔥

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. shortcut queen 💅

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. consistent across the board, no cap ⭐
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. speed demon energy 🔥

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. 😭 (reproducible but potentially slower — the classic tradeoff, iykyk)

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". 👑

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

-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. faster but maybe slightly unhinged, honestly 💀

Specifying fast is the same as specifying fast=1. 📌

Setting fast=1 (the default) recognizes and supports NaN and infinite values. Setting fast=2 does not; no NaN or infinite values will be used or produced.
-fp-model=consistent or /fp:consistent — disables optimizations that aren’t 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 information, 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, periodt.

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

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). slay, that’s the whole float vibe check ✨

🎀 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. main character energy for future compiler releases 👑

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. fancy DWARF storage behavior, ngl

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. bestie, it’s deprecated — no cap, there’s no replacement option 💀

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). hardware profile-guided optimization is literally the moment 🔥

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` (LX only) / `-fno-profile-sample-use` (LX only)

Enables the compiler and linker to use information for Hardware Profile-Guided Optimization (HWPGO). This is an experimental feature. experimental era, handle with cute care 🫶

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. speculation, but make it floating-point ✨

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 — bestie the compiler just goes for it and speculates on floating-point operations 🔥 this is also literally the behavior you get when optimizations are enabled, periodt.

BUT — and this is the plot twist — if you specify no optimizations (-O0), the default changes to -fp-speculation=safe (Linux). 💅

Description:

Okay so this option tells the compiler the mode in which to speculate on floating-point operations. That's it, that's the whole vibe.

Lowkey important tho: disabling speculation may prevent the vectorization of some loops containing conditionals. 😭 so like, tradeoffs, y'know?

Alternate Options:

None

-fshort-enums (L*X only) 🎀 — tells the compiler to allocate as many bytes as needed for enumerated types. no cap, just the exact bytes required.

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. That's the whole thing, bestie, it's giving efficiency. ✨

Alternate Options:

None

-fno-stack-protector[-keyword] (L*X only) 🛡️ — enables or disables stack overflow security checks. protecting the stack, protecting the vibes.

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. So like — 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. 💀 literally not the move.

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. Which is, like, a common technique for exploiting code that does not enforce buffer size restrictions. 😭 so yeah, this one's kind of a big deal.

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. glow up for your C++.

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. (say that five times fast, i dare you 🫶)

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.

Heads up bestie: this is a deprecated option that will be removed in a future release. 😭 the replacement option is fsycl-allow-device-image-dependencies. writing's on the wall, fr fr.

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. this is the glow-up replacement, the main character.

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. trimming the dead weight, literally.

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. slay.

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. think of it like packing your device code into lil organized fits.

Arguments:

value — can be only one of the following:

per_kernel — makes a separate device code module for every SYCL* kernel. Each one of those modules carries its kernel plus literally all its dependencies — think called functions, used variables, the whole entourage. 🫶
per_source — makes a separate device code module for each source (translation unit). So each module holds a lil' collection of kernels grouped on a per-source basis, plus all their deps — every used variable, every called function, including the SYCL_EXTERNAL macro-marked functions from other translation units. 🌸
off — creates one single module for all kernels. Heads up tho: if you also pass -fsycl-no-rdc, the behavior ends up being the same as per_source. ✨
auto — the compiler runs a heuristic and picks the best way to split device code for you. Same thing as writing fsycl-device-code-split with no value at all. 🧚

Default:

auto — this is the default whether you don't specify the compiler option at all or you do specify it but leave the value out. Either way 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.

💡 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-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. 🎀

Arguments:

library — the 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, put 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 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 is an experimental feature. 🔥

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 don't specify option -fsycl-device-obj, the compiler will create IP-based fat objects.

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. 💅

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. ⭐

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. 🦋

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. 😭

💡 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. This is an experimental feature. 🔥

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. 👀

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.

💡 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. ⚠️ This is a deprecated option that may be removed in a future release — so like, don't get too attached, bestie.

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. 💀

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

💅 hang on, quick leftover note from the option above: when SYCL offloading is enabled, this option only applies to device-specific compilation.

-fsycl-force-target=triple (L*X only) — literally 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. no cap, it's the boss now.
- Arguments:
  - triple — a target triple device name. it tells the compiler which target should be unbundled or extracted from fat objects or archives that have already been generated. the supported triplets, bestie:
    - 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.
- 🫶 okay so you can have, like, both spir64 and spir64_gen chillin' in your objects. when -fsycl-force-target is specified, the compiler uses the target you named in that option. it will not use the value specified in -fsycl-targets, even if it exists. periodt.
- 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 have only fp64 conversion operations and no fp64 computation operations. it requires an Intel GPU that supports fp64 partial emulation, so check before you commit ✨
- Arguments: None.
- Default:
  - OFF — if this option isn't 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. again: it requires an Intel GPU that supports fp64 partial emulation. the hardware has to be in on the bit.
- 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. it's giving "compiler, explain yourself" 💖
- 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.
- 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 picked for the host compilation of the overall offloading compilation that gets performed. main character compiler energy 👑
- 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.
- 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. you're basically passing notes in class, but make them compiler-legal 📝
- Arguments:
  - opts — is a string of compatible compiler options to be passed. the string must appear within quotes.
  - if there's 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 info 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. nooo don't do it, or at least know what you're doing.
- 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. the vibe: "it'll fit, trust me" 🫡

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... pick your fighter, but pick it informed.
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). yes it's a whole acronym salad, but it's the useful kind of acronym salad 🔥

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.
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). lowkey the FPGA girlies are eating with this one 🌸
- 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.

…the image takes much longer to generate than early does 😭 like genuinely, it's not even a little bit longer, it's a lot longer.

Default: OFF — no partial link of device binaries is performed. Nope, not doing it.

Description: this option tells the compiler to do a partial link of the device binaries that are gonna be used with FPGA 🎛️

That partial link then gets wrapped up by the offload wrapper, which is what lets the device binaries get linked by the host compiler or linker. Cute, right? 💅

If you don't give it a value, here's what goes down:

when it's used with just -fsycl (-fsycl -fsycl-link), the driver generates a host-linkable device object ✨
when it's also used with -fintelfpga (-fsycl -fintelfpga -fsycl-link), the behavior is the same as specifying -fsycl-link=early.

NOTE: when you use 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 it's allowed to simultaneously spawn up to the number of processes you give it, to do all the stuff needed to link SYCL applications. Bestie, this one 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. Again: experimental, so be nice to it 🧪

Note the following limitations when using this option:

this option has no effect if compiler options such as c or E are specified. Like, zero. Nothing. Zilch 💀
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. Example time: 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, then m processes will be the spawned maximum. Math is mathing 📐
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. So don't @ it.
it is not guaranteed that spawning device link processes can be safely combined with build system-level parallelization. Whenever you specify 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 the SYCL framework utility functions and to leave the kernel code unoptimized, so you can keep 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, periodt 💅

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] (L*X only)
-fno-sycl-pstl-offload (L*X 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). The way that oneDPL just handles it for you?? iconic.

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. Lowkey the stack is just not invited to this party 🙈
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. All of them. Every single one 🫶

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 (L*X only)
-fno-sycl-rdc (L*X 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. So like, if you needed those… sorry bestie 😭

Option -fno-sycl-rdc may improve compile time and compiler memory usage. Slay for efficiency 💅

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. Plot twist but make it documented 📖

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 (L*X only)
-fno-sycl-remove-unused-external-funcs (L*X only)

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

Arguments: None
Default:

🌸 `-fsycl-remove-unused-external-funcs`

okay bestie, this one is literally about cleaning up unused SYCL_EXTERNAL functions during compilation. no cap, it’s a little housekeeping pass for your SYCL device code.

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. it’s giving “pick your device era” energy ✨

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` (LX only) / `-fno-sycl-unnamed-lambda` (LX only)

Enables unnamed SYCL* lambda kernels. unnamed but still iconic, honestly 💜

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. bitcode era activated ✨

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. just a vibe check for your code, no object file at the end 🫶

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` (LX only) / `-fno-system-debug` (LX only)

Enables or disables generation of debug information for declarations in system headers. debug info but make it system-header specific 🎀

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. fast compile era, but the target code is lowkey less optimal 😭

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` (LX only) / `-fno-target-export-symbols` (LX only)

Exposes exported symbols in a generated target library to allow for visibility to other modules. visibility slay ✨

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. register allocation but make it device-specific 💅

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 internal heuristics to select a register allocation mode based on kernel analysis. 💅

Default:

The default behavior on PVC hardware is:

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.
Windows: /Qtarget-register-alloc-mode=pvc:default — tells the target backend to not impose any specification when choosing a register allocation mode.

Description:

This option specifies a register allocation mode for specific hardware, for use by supported target backends. As of right now it has no effect if you're targeting hardware other than Ponte Vecchio (PVC).

⚠️ CAUTION: when you're 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 like -ze-opt-large-register-file inside the -Xs high-level option. Bestie, use -ftarget-register-alloc-mode (Linux) or /Qtarget-register-alloc-mode (Windows) instead. 🫶

But flip side: when you're targeting other hardware, that's exactly when you should use the IGC option.

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

Alternate Options:

None.

`-ftz` (LX only) / `-no-ftz` (LX only) 🌊

Flushes denormal results to zero.

Arguments:

None.

Default:

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

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. ✨

The [Q]ftz option has no effect during compile-time optimization.

The [Q]ftz option sets or resets the FTZ and the DAZ hardware flags. Let's break it down, because this is the part people always ask about:

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. 💻

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.

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.

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. Slay, best of both worlds honestly. 🎀

📌 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.

Alternate Options:

None.

`-funsigned-char` (L*X only) 🔤

Sets the default character type to unsigned.

Arguments:

None.

Default:

OFF — the default character type is signed.

Description:

This option sets the default character type to unsigned. Heads up: it has no effect on character values that are explicitly declared signed. This option sets _CHAR_UNSIGNED = 1.

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.

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.
- gold — tells the compiler to use the gold linker. This setting is only available for Linux.
- lld — tells the compiler to use the lld linker.
- llvm-lib — tells the compiler to use the LLVM librarian. This setting is only available for Windows.

Default:

Linux: ld — the compiler uses the ld linker by default.
Windows: link — the compiler uses the link linker by 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.

On Linux, this option is provided for compatibility with gcc. iykyk 😌

📌 NOTE: on Windows, option /Qipo automatically sets option -fuse-ld=lld.

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

Alternate Options:

None.

`-fvec-allow-scalar-stores` (LX only) / `-fno-vec-allow-scalar-stores` (LX only) 🌀

Ensures vectorization of an explicit simd loop.

Arguments:

None.

Default:

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

Description:

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

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.

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.

Alternate Options:

None.

`-fvec-non-loop-argument-load` (LX only) / `-fno-vec-non-loop-argument-load` (LX only) 📥

Determines whether the non-loop vectorizer combines loads for optimization.

Arguments:

None.

Default:

-fvec-non-loop-argument-load — the non-loop vectorizer combines loads when profitable.

Description:

When this option is set (the default), the non-loop vectorizer combines loads when it appears to be profitable. ✨

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.

This option has no effect on the loop vectorizer.

Alternate Options:

None.

`-fvec-peel-loops` (LX only) / `-fno-vec-peel-loops` (LX only) 🍌

Enables peel loop vectorization.

Arguments:

None.

Default:

-fno-vec-peel-loops — no peel loop vectorization occurs.

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.

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.

The vectorization of a peel loop cannot be enforced, because the compiler uses the cost model to determine whether it should be done. Not me, the cost model said no. 🙈

Alternate Options:

None.

`-fvec-remainder-loops` (LX only) / `-fno-vec-remainder-loops` (LX only) 🧩

Enables remainder loop vectorization.

Arguments:

None.

Default:

-fno-vec-remainder-loops — no remainder loop vectorization occurs.

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.

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

The vectorization of remainder can be enforced using #pragma vector vecremainder on the loop. 👑

Alternate Options:

None.

`-fvec-with-mask` (LX only) / `-fno-vec-with-mask` (LX only) 🎭

Enables vectorization for short trip-count loops with masking.

Arguments:

None.

Default:

🎀 `-fno-vec-with-mask`

No vectorization for short trip-count loops with masking occurs.

Description:

Okay so bestie, this option enables a special mode of vectorization, and it's the moment for loops with a small number of iterations that are known at compile time. The peeling and remainder loops created during vectorization also fit into this category, no cap.

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. It's giving "one big masked iteration," honestly.

Alternate Options:

None 🙈

✨ `-fverbose-asm` (L*X only)

✨ `-fno-verbose-asm` (L*X only)

Produces an assembly listing with compiler comments, including options and version information. Literally the receipts of your build, in your assembly file.

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 don't want this default when you specify -S, specify -fno-verbose-asm. Simple as.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. Don't come for me, that's just how it is.

Alternate Options:

None

🦋 `-fvisibility=arg` (L*X only)

🦋 `-fvisibility-global-new-delete-hidden` (L*X only)

🦋 `-fvisibility-inlines-hidden` (L*X only)

🦋 `-f[no]visibility-inlines-hidden-static-local-var` (L*X only)

🦋 `-fvisibility-ms-compat` (L*X only)

Specifies the default visibility for global symbols, or the visibility for symbols in declarations, functions, or variables. This is the whole "can other components see me or nah" of symbols, and it's honestly iconic.

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. Main character energy: everybody can see you and replace you.

hidden — Sets visibility to hidden. The symbol is not visible outside this shared object.

This means that other components cannot directly reference the symbol. Very mysterious of it.

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. Check before you commit, bestie.

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 shows the 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, -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. Last one wins, that's the rule. 👑

The following shows the precedence of the visibility settings (from greatest to least visibility):

default
protected
hidden

NOTE: Clang fvisibility options are also supported. For more information on these options, see the Clang documentation. (iykyk, go read it 🫶)

Alternate Options:

None

🌸 `-fzero-initialized-in-bss` (L*X only)

🌸 `-fno-zero-initialized-in-bss` (L*X only)

Determines whether the compiler places in the DATA section any variables explicitly initialized with zeros. DATA section or BSS section: the eternal question.

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. Free space, we love to see it.

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

🧚 `-g[n]` (L*X only)

Tells the compiler to generate a level of debugging information in the object file. Debug info era, we're so back. 💖

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. Yeah, it gets thicc. That's the tradeoff, bestie.

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. Read that twice, it matters.

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. So yes, -g alone quietly nerfs your optimization — not me being dramatic, that's literally the manpage.

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. Ancient-tool girlies, this one's for you.

Alternate Options:

Linux: None
Windows: /Zi, /Z7, /ZI

💜 `--gcc-toolchain=dir` (L*X only)

Lets you specify the location of the base toolchain. Point it at your toolchain like you're pointing at your bestie across the room.

Arguments:

dir — Is the location of the base toolchain.

Default:

OFF — The compiler uses heuristics to locate the base toolchain. It'll figure it out itself, it's resourceful like that.

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. Pick your DWARF era, it's giving choose-your-own-adventure.

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. However, if compiler option -g is specified, debugging information is generated in the DWARF Version 4 format. 👑

Description:

This option lets you pick a DWARF Version format when generating debug information. 💖

Heads up, bestie: older versions of some analysis tools may require applications to be built with the -gdwarf-2 option to ensure correct operation. 😭

Alternate Options:

None

`-grecord-gcc-switches` (`L*X only`)

This one is lowkey a receipts-keeper: it 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. ✨

Alternate Options:

None

`-gsplit-dwarf` (`L*X only`)

Creates a separate object file containing DWARF debug information. 🎀

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. 🔥

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. 👑

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. 😭

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. 🌸

Arguments:

None

Default:

OFF — compilation occurs as usual. 🫶

Description:

This option tells the compiler to display the include file order and continue compilation. ✨

Alternate Options:

None

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

Displays a list of supported compiler options in alphabetical order. 👑

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. 💅

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. 💖

Alternate Options:

None

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

Adds a directory to the second include file search path. ✨

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). 🦋

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. 🧚

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. 🎀

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. 😭

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). 🌈

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. 💅

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. 🎀

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. 👑

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. ✨

Alternate Options: None

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

Okay bestie, this one is giving “front of the line but for a very specific guest list” 💅 It adds a directory to the front of the include file search path for files included with quotes but not brackets.

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`)

This one specifies a directory to add to the start of the system include path. ✨

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 passed in by -iprefix and puts it on the include search path at the end of the include directories. 🎀

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`)

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

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 search for a specified library when linking. This is lowkey the “please go find this book on the shelf” option for the linker. 📚

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.

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 searching the standard directories. Main character energy for your custom lib spot. 👑

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. Basically: “these are the CPU tricks you’re allowed to pull.” 🔥

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. It’s giving “let the build system know what depends on what.” 🧚

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. ⚠️

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, we’re talking about the old-school x87 vibes. 🫶

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. This is the “dress for the CPU you want” option. ✨

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 — generates code for the Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512) Foundation instructions, the Intel(R) AVX-512 Conflict Detection Instructions (CDI), the Intel(R) AVX-512 Doubleword and Quadword Instructions (DQI), the Intel(R) AVX-512 Byte and Word Instructions (BWI), and the Intel(R) AVX-512 Vector Length Extensions (VLE). 💅

Default:

OFF — if -march isn't specified, the compiler is allowed to generate Intel(R) SSE2 and SSE instructions.

Description:

This is the option that tells the compiler "okay bestie, use this processor's CPU feature set as the baseline" and then it generates code off that. ✨

NOTE: this one only applies to host compilation. If offloading is turned on, it has zero impact on device-specific compilation. no cap.

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.

Arguments:

dialect — the dialect to use for the assembler output file. The 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:

Yeah so this is literally the "which assembler flavor do you want" switch — it tells the compiler to generate the assembler output file using a selected dialect. 🎀

NOTE: host compilation only, bestie. 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.

Arguments:

value — any setting you can specify for option [Q]ax.

Default:

OFF — no additional execution path is generated.

Description:

This one says "hey, make me multiple feature-specific auto-dispatch code paths for x86 architecture processors if there's a performance benefit" — and it also generates a baseline code path, so there's always somewhere to land. 🦋

It cannot be used together with any options that may require Intel-specific optimizations (things like [Q]x or [Q]ax). nope, not happening.

NOTE: host compilation only — when offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None 💜

-mbranches-within-32B-boundaries (L*X only)
-mno-branches-within-32B-boundaries (L*X only)

Tells the compiler to align branches and fused branches on 32-byte boundaries for better performance. 🔥

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. slay, but read the next line pls 👇

NOTE: when you use this option, it may affect binary utilities usage experience, such as debugability. So like… your debugger might have a slightly cursed time. 🙈

NOTE: this 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.

Arguments:

mem_model — the memory model to use. The 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:

So this tells the compiler to use a specific memory model to generate code and store data, and ngl 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. (Yes, that's written as -mcmodel=medium / -mcmodel=large in the original — no space, we keep it.) 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. ✨ tiny model, big main character energy ✨

Alternate Options:

None

-MD (L*X only) — preprocess and compile, generating output file containing dependency information ending with extension .d.

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. That's it, that's the whole vibe. 🎀

Alternate Options:

None

-MFfilename (L*X only) — tells the compiler to generate makefile dependency information in a file.

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. 👑 (no, you can't skip that part, it's a package deal)

Alternate Options:

None

-MG (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 one tells the compiler to generate makefile dependency lines for each source file. It's similar to /QM, but — plot twist — 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.

Arguments:

None

Default:

OFF — if this option isn't 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:

Okay so this 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 giving "the compiler auto-upgrades your function for you" 💫

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. 😭

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, that part is on you, bestie. fr fr.

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. (Carrying this note over exactly, bestie — no cap.)

-MM (L*X only) — makefile dependency lines, but make it no-system-headers.
- 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. iykyk: same vibe, less system-header chaos.
- Alternate options: None.
-MMD (L*X only) — output file with dependency info.
- 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 — the original says: “generate an output file (with extension information.” It is similar to /QMD, but it does not include system header files. yes, that sentence is literally landing like that, and we are preserving it exactly 💀
- Alternate options: None.
-mno-gather (L*X only) — disables 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 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, -mno-omit-leaf-frame-pointer (L*X only) — leaf-function frame pointer: keep it or yeet it.
- 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 these 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, with Make-character quoting.
- 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) — tunes for a specific processor without pulling in extended instruction sets, 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.
- Code generated with -mtune=haswell (/tune:haswell) or -mtune=core-avx2 (/tune:core-avx2) will also run correctly on Intel(R) Core(TM)2 processors, but it might not run as fast as if it had been generated using -mtune=core2 or /tune:core2.
- Alternate options: None.

...and like, that's the whole vibe of it — this is in total contrast to code generated with -march=core-avx2, which will not run correctly on older processors such as Intel(R) Core(TM)2 processors 😭. So yeah, know your audience before you commit, bestie.

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) — stops 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. 🙈

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.

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

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.

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

The driver must add the library names explicitly to the link command. You must use option -qactypes to perform the link to pull in the dependent libraries.

Windows

Okay so this option literally injects directives into the compiled code, and the linker just reads them without needing any extra input from the driver. You don't have to specify a separate link command, periodt. 💅

NOTE: This option may impact target compilations because of the way it enables headers and libraries. So like, keep that in mind bestie.

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).
- Arguments:
  - lib — Indicates which oneDAL library files should be linked. Possible values are:
    - parallel — Tells the compiler to link using the threaded oneDAL libraries. This is the default if the option is specified with no lib.
    - sequential — Tells the compiler to 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)

-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.
- Arguments:
  - lib — Indicates the Intel(R) IPP libraries that the compiler should link to. Possible values are:
    - common — Tells the compiler to link using the main libraries set. This is the default if the option is specified with no lib.
    - crypto — Tells the compiler to link using the Intel(R) Cryptography Primitives Library.
    - nonpic — (Linux* only) Tells the compiler to link using the version of the libraries that do not have position-independent code.
    - nonpic_crypto — (Linux only) Tells the compiler to 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. Possible values are:
    - parallel — Tells the compiler to link using the threaded libraries in oneMKL. This is the default if the option is specified with no lib.
    - sequential — Tells the compiler to link using the sequential libraries in oneMKL.
    - cluster — Tells the compiler to 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. 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.

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. Possible values are:
    - parallel — Tells the compiler to link using the threaded libraries in oneMKL. This is the default if the option is specified with no lib.
    - sequential — Tells the compiler to link using the sequential libraries in oneMKL.
    - cluster — Tells the compiler to 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. 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. To link with oneMKL dynamically, you must specify:

/Qmkl-ilp64 /MD

Okay so this next bit is still living inside that option’s world — it adds directives straight into the compiled code, and the linker reads them without needing any extra input from the driver. Translation: you do not need to specify a separate link command. 💅

Alternate Options: None

-qmkl-sycl-impl=arg[,arg,...] (L*X only) — lets you link to one or more specific Intel(R) oneAPI Math Kernel Library (oneMKL) SYCL libraries. slay.
- 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: this option lets you link to one or more specific oneMKL SYCL libraries.
- It is not supported for static linking.
- NOTE: when using this option, you must also specify option -fsycl and -qmkl (Linux) or /Qmkl (Windows).
- Alternate Options: None
-qopenmp (L*X only), -qno-openmp (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 -fiopenmp (and /Qiopenmp). iconic tbh.
- Arguments: None
- Default:
  - -qno-openmp — 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. The code can be executed in parallel on both uniprocessor and multiprocessor systems.
- This option 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(R) microprocessors and non-Intel microprocessors, but these options may perform additional optimizations on Intel(R) microprocessors than they perform on non-Intel microprocessors.
- The list of major, user-visible OpenMP constructs and features that may perform differently on Intel(R) microprocessors versus non-Intel microprocessors include: locks (internal and user visible), the SINGLE construct, barriers (explicit and implicit), parallel loop scheduling, reductions, memory allocation, thread affinity, and binding.
- 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. lowkey important.
- 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. However, we strongly recommend you use the default setting, -qopenmp-link=dynamic.
- 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.
- 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 runtime 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. ✨
- 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.
- 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.
- 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.
- Alternate Options:
  - Linux: -fiopenmp-simd
  - Windows: /Qiopenmp-simd
-qopenmp-stubs (L*X only) — enables compilation of OpenMP* programs in sequential mode. no cap.
- 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. bestie, this one is for the loop girlies.
- 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 is useful for C/C++ applications and benchmarks where pointers and arguments could be aliased. This is because when you specify level 1 or level 2, more loops will be vectorized or benefit from loop transformations.
- This option is applied to all loops in the file. It does not apply to code outside loops.
- Alternate Options: None
-qopt-dword-index-for-array-of-structs[=val] (L*X only) — 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 (L*X only) / -qno-opt-dynamic-align (L*X only) — turns dynamic data alignment optimizations on or off. ✨

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) — tells the compiler how to optimize for throughput depending on whether the program is meant to run as a single job or in a multi-job setup. 🏃‍♀️💨

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 straight 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.

Heads up: 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] (L*X only) / -qno-opt-mem-layout-trans (L*X only) — controls how much memory layout transformation the compiler does. 🧠✨

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 (L*X only) / -qno-opt-multiple-gather-scatter-by-shuffles (L*X only) — turns the optimization for multiple adjacent gather/scatter type vector memory references on or off. 🌀

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] (L*X only) / -qno-opt-prefetch (L*X only) — turns prefetch insertion optimization on or off. 🔮

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:

varies — the default can change depending on certain option settings.

Alternate Options:

None

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:

Okay so this option turns prefetch insertion optimization on or off 🎀. The whole goal of prefetching is to reduce cache misses by giving the processor lil hints 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)

Specifies the prefetch distance to be used for compiler-generated prefetches inside loops 🌀.

Arguments:

n — is the prefetch distance in terms of the number of (possibly-vectorized) iterations. Possible values are non-negative numbers >=0. And bestie, n = 0 turns off all compiler issued prefetches from memory to L1, no cap 🙈.

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)

Specifies that the compiler should only prefetch for 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)

Enables the generation of a textual file that includes optimization transformation information 📄.

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)

Specifies whether the output for the generated optimization report 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)

Specifies whether mangled or unmangled names should appear in the optimization report 🏷️.

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 — literally every optimizer phase. This is the default if you don’t specify list. slay. 💅

Default:

OFF — no optimization report is generated. periodt.

Description:

This option says “generate optimization reports for one or more optimizer phases,” and that’s the whole vibe. For certain phases you also have to bring backup options, bestie:

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. But if you want 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) — sends the generated report straight to stdout. very main character of it.

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), -qno-opt-streaming-stores (L*X only) — enables generation of streaming stores for optimization. iconic little memory-hierarchy vibe.

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. no cap, that part is on you.

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. zmm girlies rise.

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, bestie:

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. library linkage but make it cute.

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.

NOTE: 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), -qno-unknown-option-as-warning (L*X only) — tells the compiler to treat unknown compiler options on Linux* as a warning instead of an error. gentle parenting the compiler, honestly.

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. register-passing excellence.

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: all __regcall functions must have prototypes. do not skip this, bestie.

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. reusing the fit, saving the time, we love to see it.

Arguments:

exe-filename — is a previously compiled SYCL* binary.

Default:

OFF — nope, zero potential compile-time speed up from reusing the executable for the FPGA target. 💅

Description:

Okay so this option tells the compiler to speed up FPGA target compile time by reusing a previously compiled FPGA hardware image. It's only useful when you're compiling for hardware — that's the whole vibe check.

Basically it lets you minimize or even dodge those long Intel(R) Quartus(R) Prime Software compile times for FPGA targets when the device code hasn't changed. Iconic time-saver fr fr. 🕐✨

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

Alternate Options:

None — it's a solo act, no dupe.

`-S` (L*X only)

Causes the compiler to compile to an assembly file only and not link. 🛑

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. That's it, that's the whole job. 💅

On Linux* systems, the assembly file name has a .s suffix. On Windows* systems, the assembly file name has an .asm suffix. Suffix lore 🎀

Alternate Options:

Linux: None

`-save-temps` (L*X only)

`-no-save-temps` (L*X only)

Tells the compiler to save intermediate files created during compilation. 💾✨

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. Keepsakes, basically. 🎀

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. It's not out here manifesting extra files into existence, bestie. 🫶

Alternate Options:

None

`-shared` (L*X only)

Tells the compiler to produce a dynamic shared object instead of an executable. 🧚✨

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. Sharing is caring 💖

You must specify option fpic for the compilation of each object file you want to include in the shared library. Not optional, it's required, periodt.

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)

Causes Intel-provided libraries to be linked in dynamically. 🌈

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. Enemies to lovers arc, but for link flags. 😭

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. Sneaky little side effect, ngl.

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)

Links the GNU libgcc library dynamically. 🦋

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. Override the default, main character energy. 👑

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]]` (L*X only)

`-no-sox` (L*X only)

Tells the compiler to save the compilation options in the executable file. 📝✨

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. Receipts, but in binary. 🧾

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. Forensics slay. 🔍

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)

Prevents linking with shared libraries. 🚫

Arguments:

None

Default:

OFF — The compiler links with shared libraries.

Description:

This option prevents linking with shared libraries. It causes the executable to link all libraries statically. All in, no borrowing. 💜

NOTE: This option does not cause static linking of libraries for which no static version is available. These libraries can only be linked dynamically. Can't link what doesn't exist, bestie. 😭

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)

Causes Intel-provided libraries to be linked in statically. 🔥

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. Full stop, it's giving error message. 💀

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)

Links the GNU libgcc library statically. 🌸

Arguments:

None

Default:

OFF — The compiler links the GNU libgcc library dynamically.

Description:

This option links the GNU libgcc library statically. It is the opposite of option -shared-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, 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 the whole reason backtrace info can be printed at all, so like… don't skip it.

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

Alternate Options: None

`-static-libstdc++` (L*X only)

✨ Links the GNU libstdc++ library statically. ✨

Arguments: None
Default: OFF — the compiler links the GNU libstdc++ library dynamically.
Description: this option links the GNU libstdc++ library statically.

It's processed by the compiler driver command that initiates linking, adding library names explicitly to the link command. Basically the driver is out here naming libraries by hand, iconic behaviour honestly.

This option is useful when you want to override the default behavior, which causes the library to 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

`-std=val` (L*X only)

Tells the compiler to conform to a specific language standard — like a vibe check but for your entire codebase 🔥

Arguments: val — specifies the language standard to conform to.
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.
Alternate Options: None

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.

`-strict-ansi` (L*X only)

Tells the compiler to implement strict ANSI conformance dialect — the "no thoughts, only conformance" era 😤

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, that's the one that plays nice).

This option sets option fmath-errno, which tells the compiler to assume that the program tests errno after calls to math library functions. Heads up: this restricts optimization, because it causes the compiler to treat most math functions as having side effects. So like… cute for correctness, not it for speed 💅

💀 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 📁

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. Obsessed with a clean little prefix swap tbh 🎀

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.

Alternate Options: None

`-Tfilename` (L*X only)

Tells the linker to read link commands from a file 📜

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 — the "nvm forget that" button 🫶

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.

On Windows systems, use the /u option to undefine all previously defined preprocessor values.

Alternate Options: None

`-u symbol` (L*X only)

Tells the compiler the specified symbol is undefined ✨

Arguments: None
Default: OFF — standard rules are in effect for variables.
Description: this option tells the compiler the specified symbol is undefined.
Alternate Options:

💅 `-undef` (LX only)*

okay so this one just says nope to every single predefined macro — all of them, gone, not a single survivor left standing 😭 that's genuinely all it does, no notes.

Arguments: None — nothing to hand it, bestie.

Default: OFF — defined macros are in effect until they are undefined.

Description: this option disables all predefined macros.

Alternate Options: None

🌀 `-unroll[=n]` (LX only)*

this is the "hey compiler, chill out on the loop unrolling" dial (or the "go off, unroll everything" dial, depending on your vibe). it tells the compiler the maximum number of times to unroll loops.

Arguments:

n — is the maximum number of times a loop can be unrolled. To disable loop unrolling, 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 gets to decide how many times loops can be unrolled. main character optimizer energy, honestly.

Alternate Options:

Linux: -funroll-loops

🎀 `-use-intel-optimized-headers` (LX only)*

this is the "should the performance headers directory join the include path search list" question, and the answer is literally just yes or no, no in-between 💅

Arguments: None

Default: -no-use-intel-optimized-headers — the performance headers directory is not added to the include path search list. (sad but true.)

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. and like, appropriate libraries are also linked in, as needed, for proper functionality. it just works, fr fr ✨

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` (LX only)*

inline assembly reveal?? no but literally — this enables the use of blocks and entire functions of assembly code within a C or C++ file. entire functions, bestie. whole chunks of asm living rent-free in your .cpp. iconic 💀

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. so like, pick a lane, but this flag picks the Microsoft one for you 🫶

Alternate Options: -fasm-blocks

🦋 `-v [filename]` (LX only)*

the receipts flag. this one specifies that driver tool commands should be displayed and executed — so you get to watch the whole thing happen, no mystery, no cap 👑

Arguments:

filename — is the name of a source file to be compiled. A space must appear before the file name. (yes, actually a space. <kbd>Space</kbd>. don't forget it 🙈)

Default: OFF — no tool commands are shown.

Description: this option specifies that driver tool commands should be displayed and executed.

and here's the lil plot twist: if you use this option without specifying a source file name, the compiler displays only the version of the compiler. just the version. that's the whole show. 🎭

Alternate Options: None

🌈 `-vec` (LX only)*

🌈 `-no-vec` (LX only)*

the on/off switch for loop vectorization. enables or disables loop vectorization, that's the tweet.

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` (LX only)*

🍓 `-no-vec-assume-index-overflow` (LX only)*

this pair toggles between modes, with the less conservative mode as the default. so the chill mode is what you get unless you go out of your way, slay.

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. like, safety first but your loads and stores lose out on the extra glow-up. trade-offs, babe 😭

Alternate Options: None

⭐ `-vec-threshold[n]` (LX only)*

setting the bar for when loops get the vectorization treatment. very "you must be at least this profitable to ride" energy 🎢

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. zero chill, just vibes.
- 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. picky queen 👑
- 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 one is genuinely 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. iykyk 🧠

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. it's giving "group project effort allocation" honestly.

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

Alternate Options: None

💜 `-vecabi=keyword` (LX only)*

this one determines which vector function application binary interface (ABI) the compiler uses to create or call vector functions. big ABI decisions happening over here, we're obsessed 🎀

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. (so convenient it's almost suspicious ✨)
- 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.

okay, important warning time, listen up fr fr:

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. no mixing, no matching, no "close enough" 💀

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. yeah. ouch. 😭

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 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
These variants are always created independently of target options.

cmdtarget:

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)
- Intel(R) AVX2 (by the ax option value)

NOTE: 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. If setting cmdtarget is specified, options [Q]x and/or [Q]ax must have identical values.

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.
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. Like, all of them. Silence era.

Arguments: None
Default: OFF — default warning messages are enabled.
Description: This option disables all warning messages.
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` (LX only) / `-Wno-abi` (LX 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. The classic “give me the diagnostics” moment.

Arguments: None
Default: OFF — only default warning diagnostics are enabled.
Description: This option enables many warning and error diagnostics. 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.
Alternate Options: None

`-Wcheck-unicode-security` (LX only) / `-Wno-check-unicode-security` (LX 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. 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` (LX only) / `-Wno-comment` (LX 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.
Alternate Options: None

`-Wdeprecated` (LX only) / `-Wno-deprecated` (LX 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. 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. No more “it’s just a warning” excuses.

Arguments: None
Default: OFF — the compiler returns diagnostics as usual.
Description: This option changes all warnings to errors.
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.
Alternate Options: None

`-Wextra-tokens` (LX only) / `-Wno-extra-tokens` (LX 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.
Alternate Options: None

`-Wformat` (LX only) / `-Wno-format` (LX 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.
Alternate Options: None

`-Wformat-security` (LX only) / `-Wno-format-security` (LX 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.
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` (LX only) / `-Wno-main` (LX 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.
Alternate Options: None

`-Wmissing-declarations` (LX only) / `-Wno-missing-declarations` (LX only) 🫶

Arguments: nope, none at all, she takes zero arguments 💅

Default: Wno-missing-declarations — so no warnings get issued for global functions and variables that show up without a prior declaration. Chill, silent, no nagging.

Description: this option is literally just the vibe check on whether warnings get issued for global functions and variables without prior declaration. That's the whole thing. That's the gig.

Alternate Options: None

🦋 `-Wmissing-prototypes` (LX only) / `-Wno-missing-prototypes` (LX only)

Arguments: None

Default: Wno-missing-prototypes — no warnings are issued for missing prototypes. Silence is golden, bestie.

Description: decides whether warnings get issued for missing prototypes. And if you actually specify Wmissing-prototypes, it tells the compiler to detect global functions that are defined without a previous prototype declaration. Like, "excuse me ma'am, where is your declaration?" energy 🔍

Alternate Options: None

🌸 `-Wno-sycl-strict` (L*X only)

Arguments: None

Default: OFF — meaning the warnings that enforce strict SYCL* language compatibility are enabled. They're on, they're loud, they're living rent free.

Description: this one disables the warnings that enforce strict SYCL* language compatibility. Say it with me: -Wno-sycl-strict = strictness off, chaos on 🙈

Alternate Options: None

🎀 `-Wp,option1[,option2,...]` (L*X only)

Arguments:

option — is a preprocessor option. It is not processed by the driver and gets directly passed to the preprocessor. Straight to the preprocessor, no middleman, no small talk.

Default: OFF — no options are passed to the preprocessor.

Description: passes one or more options to the preprocessor. If the preprocessor isn't invoked, these options are just ignored (they're giving ignored, respectfully). This option is equivalent to specifying -Qoption,cpp,options.

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

Alternate Options: None

✨ `-Wpointer-arith` (LX only) / `-Wno-pointer-arith` (LX only)

Arguments: None

Default: Wno-pointer-arith — no warnings are issued for questionable pointer arithmetic.

Description: determines whether warnings are issued for questionable pointer arithmetic. Questionable. Pointer. Arithmetic. It's giving chaos and we're just here to observe 😭

Alternate Options: None

💜 `-Wreorder` (L*X only)

Arguments: None

Default: OFF — the compiler does not issue a warning.

Description: tells the compiler to issue a warning when the order of member initializers does not match the order in which they must be executed. And heads up: this option is supported for C++ only. C++ girlies only, sorry 🫶

Alternate Options: None

🔥 `-Wreturn-type` (LX only) / `-Wno-return-type` (LX only)

Arguments: None

Default: ON for one condition — a warning is issued when the closing brace of a function returning non-void is reached. So one of these three is always snitching, no cap.

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. Your terminal, your rules 💅

Alternate Options: None

🦋 `-Wshadow` (LX only) / `-Wno-shadow` (LX only)

Arguments: None

Default: Wno-shadow — no warning is issued when a variable declaration hides a previous declaration.

Description: determines whether a warning is issued when a variable declaration hides a previous declaration. Oh and — same as -ww1599. Twins fr fr.

Alternate Options: None

🌈 `-Wsign-compare` (LX only) / `-Wno-sign-compare` (LX only)

Arguments: None

Default: Wno-sign-compare — the compiler does not issue these warnings.

Description: 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. Like, the classic signed-vs-unsigned betrayal 💀

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

Alternate Options: None

⭐ `-Wstrict-aliasing` (LX only) / `-Wno-strict-aliasing` (LX only)

Arguments: None

Default: Wno-strict-aliasing — no warnings are issued for code that might violate the optimizer's strict aliasing rules.

Description: determines whether warnings are issued for code that might violate the optimizer's strict aliasing rules. Sneaky code gets called out 👀

Also, options -fstrict-aliasing and -Ofast also enable strict aliasing. Not me telling you that they're in on it too.

Alternate Options: None

🧚 `-Wstrict-prototypes` (LX only) / `-Wno-strict-prototypes` (LX only)

Arguments: None

Default: Wno-strict-prototypes — no warnings are issued for functions declared or defined without specified argument types.

Description: determines whether warnings are issued for functions declared or defined without specified argument types. Where are the types, babe? Nowhere? Okay then 😭

Alternate Options: None

🍓 `-Wtrigraphs` (LX only) / `-Wno-trigraphs` (LX only)

Arguments: None

Default: Wno-trigraphs — no warnings are issued if any trigraphs are encountered that might change the meaning of the program.

Description: determines whether warnings are issued if any trigraphs are encountered that might change the meaning of the program. Trigraphs changing your program's whole personality? That would be a no from me 🙈

Alternate Options: None

💖 `-Wuninitialized` (LX only) / `-Wno-uninitialized` (LX only)

Arguments: None

Default: Wno-uninitialized — no warning is issued if a variable is used before being initialized.

Description: determines whether a warning is issued if a variable is used before being initialized. Using a variable before it's initialized? In this economy?? 😭

Alternate Options: None

👑 `-Wunknown-pragmas` (LX only) / `-Wno-unknown-pragmas` (LX only)

Arguments: None

Default: Wunknown-pragmas — a warning is issued if an unknown #pragma directive is used. Look at her, being the loud one for once.

Description: determines whether a warning is issued if an unknown #pragma directive is used. Unknown pragma spotted, chat is notified 🔔

Alternate Options: None

🎀 `-Wunused-function` (LX only) / `-Wno-unused-function` (LX only)

Arguments: None

Default: Wno-unused-function — no warning is issued if a declared function is not used.

Description: determines whether a warning is issued if a declared function is not used. Declared but never called... she's just sitting there, existing, unbothered 💅

Alternate Options: None

🌸 `-Wunused-variable` (LX only) / `-Wno-unused-variable` (LX only)

Arguments: None

Default: Wno-unused-variable — no warning is issued if a local or non-constant static variable is unused after being declared.

Description: determines whether a warning is issued if a local or non-constant static variable is unused after being declared. Declared, then forgotten. Ghosted, honestly.

Alternate Options: None

🦋 `-Wwrite-strings` (L*X only)

Arguments: None

Default:

OFF — no diagnostic message is issued if const char * is converted to (non-const) char*.

Description:

This option issues a diagnostic message if const char* is converted to (non-const) char *.

Alternate Options:

None

-X (L*X only) — removes standard directories from the include file search path. 🗂️

Arguments:

None

Default:

OFF — standard directories are in the include file search path.

Description:

This option removes standard directories from the include file search path. It prevents the compiler from searching the default path specified by the INCLUDE environment variable.

On Linux* systems, specifying -X (or -noinclude) prevents the compiler from searching in /usr/include for files specified in an INCLUDE statement.

You can use this option with the I option to prevent the compiler from searching the default path for include files and direct it to use an alternate path. ✨

Alternate Options:

Linux: -nostdinc

-x type (L*X only) — tells the compiler that all source files found subsequent to -x type should be recognized as a particular type. 🏷️

Arguments:

type — is the type of source file. 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. 💅

Alternate Options:

None

-xcode (L*X only) — tells the compiler which processor features it may target, including which instruction sets and optimizations it may generate. 🔥

Arguments:

code — specifies a feature set that the compiler can target, including which instruction sets and optimizations it may generate. 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.

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. 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.
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. 🦋

ATOM_SSSE3 — Okay so this one may generate MOVBE instructions for Intel(R) processors, depending on the setting of option -minstruction (Linux) or /Qinstruction (Windows). It may also generate SSSE3, Intel(R) SSE3, SSE2, and SSE instructions for Intel processors. It 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: This option tells the compiler which processor features it may target, including which instruction sets and optimizations it may generate. No cap.

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. 💀

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. Slay.

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. Main character energy, honestly. 👑

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.

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. Bestie, it’s giving middleman — but make it useful. 🔗

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.

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. Obsessed with this level of control, ngl. 🎀

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. Lowkey the secret tunnel to the backend. 🌀

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. SYCL girlies rise. 🌸

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.
middle end — okay so this is the part of a SPIR-V*-based device compiler that literally generates the SPIR-V*. That SPIR-V* then gets handed by the compiler driver over to the backend of target T. slay pipeline 💅
backend — indicates Ahead of Time (AOT) compilation for target triple T, and Just in Time (JIT) compilation for target T at runtime. both moods, iconic.
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. bestie they're sharing a room, the options get combined, that's just how it is 🫶

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 SYCL target.

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

Alternate Options:

None

🎀 `-Zp[n]` (L*X only) 🎀

Specifies alignment for structures on byte boundaries. lowkey a whole personality trait for your structs.

Arguments:

n — is the byte size boundary. Possible values are 1, 2, 4, 8, or 16.

Default:

Zp16 — structures are aligned on either size boundary 16 or the boundary that will naturally align them.

Description:

This option specifies alignment for structures on byte boundaries.

If you do not specify n, you get Zp16. periodt, that's the deal ✨

Alternate Options:

None

🔮 PREDEFINED MACROS 🔮

To see supported predefined macros, specify the following command:

dpcpp -x c /dev/null -dM -E

This will output the currently defined macros. literally just ask the compiler what it knows and it'll spill the whole tea ☕

🌸 Supported Environment Variables 🌸

💜 Compiler Compile-Time Environment Variables 💜

The following table shows the compile-time environment variables that affect the compiler:

CL (Windows*) — the Windows one; its description lives with _CL_ right below 💅
_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. You can use the pound sign (#) instead. In this example, the pound sign is used as a substitute for an equal sign (=) in the assigned string: SET CL=/Dtest#100 — yes bestie, the # is doing the equal sign's job, we love a workaround 🙈

ICXCFG — Specifies the configuration file for customizing compilations when invoking the compiler using icx. Used instead of the default configuration file.
ICPXCFG — Specifies the configuration file for customizing compilations when invoking the compiler using icpx. 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 is in the same directory as the compiler executable. To use another configuration file in another location, you can use the ICXCFG (Linux, Windows), 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). it will not be quiet about it unless you ask it to be 💀

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.

NOTE: On Windows, these environment variables cannot be set from Visual Studio*. nope, not from there, sorry bestie 😭

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. she's the version that keeps everything 🫶

NOTE: Paths are delimited by a platform-dependent character, PATH_SEPARATOR, for environment variables that accept a sequence of paths. The delimiter character is a colon (:) on Linux and a semicolon (;) on Windows.

🧚 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. literally any non-null value, that's the whole vibe check ⭐

= = = = = = = = = =

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 will 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/ — register first bestie, the door needs a key 🔑

✨ 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 🌟

Your compiler documentation has additional reference material on features of your compiler.

📜 Notices and Disclaimers 💅

okay bestie, we're at the boring-but-actually-important part, and no, you can't skip it — this is the legal tea ☕ and it's lowkey required reading, so let's go 🫶

Intel technologies may require enabled hardware, software or service activation.

No product or component can be absolutely secure. (yes, literally none, that's just the vibe of reality 😭)

Your costs and results may vary.

(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.

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.

💀 real talk: that last paragraph is doing a LOT of heavy lifting — it's the "no promises, bestie" clause, and it means exactly what it says. Not a single implied warranty survives it. Periodt.

and that's the whole page, icon 👑 you made it all the way to the bottom, which honestly? main character energy fr fr 🌈✨ this one's DPCPP(1), Copyright(C) 2019-2025 Intel Corporation, and it's giving official-and-slightly-intimidating, so go forth and dpcpp responsibly 💖🎀🦋

📦 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

DPCPP(1)

DPCPP(1) — Intel(R) oneAPI DPC++ Compiler Options 💅

✨ SYNOPSIS ✨

🌸 DESCRIPTION 🌸

🦋 Clang Option Support 🦋

🔥 FEATURE REQUIREMENTS 🔥

👑 OPTIONS 👑

💖 -ansi (L*X only)

🚀 -axcode (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)

Description 💬

Alternate Options 🌀

Arguments 🎀

Default ⭐

Description 💬

Alternate Options 🌀

Arguments 🎀

Default ⭐

Description 💬

Alternate Options 🌀

Arguments 🎀

Default ⭐

Description 💬

Alternate Options 🌀

Arguments 🎀

Default ⭐

Description 💬

Alternate Options 🌀

Arguments 🎀

Default ⭐

Description 💬

Alternate Options 🌀

Arguments 🎀

Default ⭐

Description 💬

Alternate Options 🌀

Arguments 🎀

Default ⭐

Description 💬

-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-max-error=ulps[:funclist] (L*X only)

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

🌈 -fimf-use-svml=value[:funclist] (L*X only)

🌸 -finline (L*X only)

🌸 -fno-inline (L*X only)

🎀 -finline-functions (L*X only)

🎀 -fno-inline-functions (L*X only)

🦋 -fintelfpga (L*X only)

🔥 -fiopenmp (L*X only)

⭐ -fjump-tables (L*X only)

⭐ -fno-jump-tables (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)

🎀 -fopenmp-device-link (L*X only)

🦋 -fopenmp-max-parallel-link-jobs=num (L*X only)

🌈 -fopenmp-offload-mandatory (for Clang compatibility) (L*X only)

(L*X only)

💜 -fopenmp-target-buffers=keyword (L*X only)

🌸 -fopenmp-target-default-sub-group-size=val (L*X only)

🧚 -fopenmp-target-loopopt (L*X only)

⭐ -fopenmp-target-simd (L*X only)

🦋 -fopenmp-targets=triple (L*X only)

Default

Description

Alternate Options

🔁 -foptimize-sibling-calls (L*X only) & -fno-optimize-sibling-calls (L*X only)

Arguments

Default

💖 `-ansi` (L*X only)

🚀 `-axcode` (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)

`-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-max-error=ulps[:funclist]` (LX only)*

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

🌈 `-fimf-use-svml=value[:funclist]` (L*X only)

🌸 `-finline` (L*X only)

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

🎀 `-finline-functions` (L*X only)

🎀 `-fno-inline-functions` (L*X only)

🦋 `-fintelfpga` (L*X only)

🔥 `-fiopenmp` (L*X only)

⭐ `-fjump-tables` (L*X only)

⭐ `-fno-jump-tables` (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)

🎀 `-fopenmp-device-link` (L*X only)

🦋 `-fopenmp-max-parallel-link-jobs=num` (L*X only)

🌈 `-fopenmp-offload-mandatory` (for Clang compatibility) (L*X only)

💜 `-fopenmp-target-buffers=keyword` (L*X only)

🌸 `-fopenmp-target-default-sub-group-size=val` (L*X only)

🧚 `-fopenmp-target-loopopt` (L*X only)

⭐ `-fopenmp-target-simd` (L*X only)

🦋 `-fopenmp-targets=triple` (L*X only)

🔁 `-foptimize-sibling-calls` (LX only) & `-fno-optimize-sibling-calls` (LX only)

🏰 `-fortlib` (L*X only)

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

🥺 `-fpermissive` (L*X only)

🧊 `-fpic` (LX only) & `-fno-pic` (LX 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` (LX only) / `-fno-profile-sample-use` (LX only)

💜 `-fp-speculation=mode` (L*X only)

🌸 `-fsycl-remove-unused-external-funcs`

🦋 `-fsycl-targets=T1,...,Tn` (L*X only)