IFX(1)

📦 version 2026.0.1.27+c9c3d3e3_ddb4_490e_bb41_6e9041ba32a7, in arch rolling

🎀 IFX(1) — Intel(R) Fortran Compiler 🎀

okay bestie, welcome to IFX(1) — the Intel(R) Fortran Compiler manual page. Also, the raw page has a lone " hanging out at the top like a mysterious side character. No context. Just vibes. Moving on. 💀

This man page describes the supported compiler options for the Intel(R) Fortran Compiler, which is based on open source LLVM* compiler technology.

ifx — invokes the Intel(R) Fortran Compiler. periodt. 💅

✨ SYNOPSIS ✨

ifx [ options ] file1 [ file2 ]...

options — are zero or more compiler options.
fileN — is a Fortran source file, assembly file, object file, object library, or other linkable file.

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

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

🦋 DESCRIPTION 🦋

The Intel(R) Fortran Compiler (ifx) is a new compiler based on the Intel(R) Fortran Compiler Classic (ifort) frontend and runtime libraries, using LLVM backend technology. At this time, ifx supports features of the Fortran 2008 language with the exception of coarrays and parameterized derived types, OpenMP* 5.0 Version TR4, and many OpenMP Version 5.1 directives and offloading features.

ifx is binary (.o/.obj) and module (.mod) file compatible; binaries and libraries generated with ifort can be linked with binaries and libraries built with ifx, and .mod files generated with one compiler can be used by the other. Both compilers use the ifort runtime libraries.

ifx is useful for developers interested in trying GPU offloading, which ifort does not support. Other Fortran users should continue to use ifort.

The LLVM-based Intel(R) Fortran Compiler supports many Intel(R) Fortran Compiler Classic (ifort) compiler options, but full implementation is not yet available in this release. Additional ifort options will be available in future releases.

The ifx command invokes Intel(R) Fortran Compiler, which is designed to preprocess, compile, assemble, and link Fortran programs on systems using supported architectures (see your Release Notes). If a description does not explicitly state an architecture restriction, assume that the description is applicable to all supported architectures.

When there is a restriction, you will see "Architecture Restrictions", which will show the relevant restriction.

The ifx command interprets input files by their filename suffix as follows:

Filenames with the suffix .f90 are interpreted as free-form Fortran 95/90 source files.
Filenames with the suffix .f, .for, or .ftn are interpreted as fixed-form Fortran source files.
Filenames with the suffix .fpp, .F, .FOR, .FTN, or .FPP are interpreted as fixed-form Fortran source files, which must be preprocessed by the fpp preprocessor before being compiled.
Filenames with the suffix .F90 are interpreted as free-form Fortran source files, which must be pre-processed by the fpp preprocessor before being compiled.
Filenames with the suffix .s are interpreted as assembler files and are passed to the assembler.
Filenames with the suffix .S are interpreted as assembler files and are preprocessed by the fpp preprocessor before being passed to the assembler.
Filenames with the suffix .a are interpreted as object libraries and are passed to ld(1).
Filenames with the suffix .o are interpreted as compiled object files and are passed to ld(1).

You can override some options specified on the command line by using the OPTIONS statement in your Fortran source program. An OPTIONS statement affects only the program unit in which the statement occurs. For more information, see the Intel(R) Fortran Language Reference.

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

🚀 Options that Improve Run-Time Performance 🚀

The following command line options can be used to increase the run-time performance of code generated by the Intel(R) Fortran Compiler:

On systems using Intel(R) 64 architecture: -ftz, -ipo, -march=<processor>, -mtune=<processor>, -O[n], -qopenmp, -x<processor>

🧵 Configuration and Indirect Files 🧵

Command options to be used whenever the compiler is invoked can be put into a system configuration file named ifort.cfg, which resides in the same area as the compiler.

The text in this file is processed by ifx before the text on the command line. To use a personal configuration file, set the environment variable IFORTCFG to point to the path and filename to be used.

An indirect file contains text that can be included on the ifx command line. Precede the filename with an at symbol (@) on the command line at the point where the options are to be inserted.

For example, assume that file double_size contains options "-integer-size 8 -real-size 8" and file my_includes contains options "-I/bld/inc -I/bld/headers". In this case, the following command line:

ifort -O3 @double_size myprog.f90 @my_includes

passes to the compiler:

-O3 -integer-size 8 -real-size 8 myprog.f90 -I/bld/inc -I/bld/headers

🌈 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: -mkl, -qmkl, -qmkl-ilp64, /Qmkl and /Qmkl-ilp64 options — Requirement: Intel(R) oneAPI Math Kernel Library (oneMKL) 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 👑

Some compiler options have the form -name keyword. Both -name and keyword can be abbreviated. It is recommended that you use the first four characters of each. For example, -assume buffered_io can be specified as -assu buff.

To see lists of compiler options by functionality, specify a category for option -help on the command line. For a list of the categories you can specify, see -help below.

For information on linker and load-time options, see ld(1).

For some options, you can (or must) specify additional information, such as a keyword, a directory, a file name, a number, and so forth. When this information is required, it is shown in angle brackets (<>); when it is optional, it is shown in square brackets ([]). For example, in option -fp-model=<keyword>, keyword is required; in option -falign-functions[=n], n (a number) is optional.

-align [keyword[, keyword...]] (L*X only) — tells the compiler how to align certain data items.
-noalign (L*X only) — tells the compiler how to align certain data items.

🧸 Arguments:

keyword — specifies the data items to align. Possible values are:
- none — prevents padding bytes anywhere in common blocks and structures.
- arraynbyte — specifies a starting boundary for arrays.
- [no]commons — affects alignment of common block entities.
- [no]dcommons — affects alignment of common block entities.
- [no]qcommons — affects alignment of common block entities.
- [no]zcommons — affects alignment of common block entities.
- [no]records — affects alignment of derived-type components and fields of record structures.
- recnbyte — specifies a size boundary for derived-type components and fields of record structures.
- [no]sequence — affects alignment of sequenced derived-type components.
- all — adds padding bytes whenever possible to data items in common blocks and structures.

🌸 Default:

nocommons — adds no padding bytes for alignment of common blocks.
nodcommmons — adds no padding bytes for alignment of common blocks.
noqcommmons — adds no padding bytes for alignment of common blocks.
nozcommmons — adds no padding bytes for alignment of common blocks.
records — aligns derived-type components and record structure fields on default natural boundaries.
nosequence — causes derived-type components declared with the SEQUENCE statement to be packed, regardless of current alignment rules set by the user.

By default, no padding is added to common blocks but padding is added to structures.

💫 Description:

This option specifies the alignment to use for certain data items. The compiler adds padding bytes to perform the alignment.

align none — tells the compiler not to add padding bytes anywhere in common blocks or structures. This is the same as specifying noalign.
align arraynbyte — aligns the start of arrays on an n-byte boundary. n can be 8, 16, 32, 64, 128, or 256. The default value for n is 8. This affects the starting alignment for all arrays except for arrays in COMMON and arrays declared in the specification part of a module.

Arrays do not have padding between their elements. 💅

Okay, continuing the align keyword family — these are the little alignment gremlins that control padding, and they are lowkey iconic:

align commons — aligns all common block entities on natural boundaries up to 4 bytes, by adding padding bytes as needed.
align nocommons — adds no padding to common blocks. In this case, unaligned data can occur unless the order of data items specified in the COMMON statement places the largest numeric data item first, followed by the next largest numeric data (and so on), followed by any character data.
align dcommons — aligns all common block entities on natural boundaries up to 8 bytes, by adding padding bytes as needed.
align nodcommons — adds no padding to common blocks.
align qcommons — aligns all common block entities on natural boundaries up to 16 bytes, by adding padding bytes as needed.
align noqcommons — adds no padding to common blocks.
align zcommons — aligns all common block entities on natural boundaries up to 32 bytes, by adding padding bytes as needed.
align nozcommons — adds no padding to common blocks.
align norecords — aligns components of derived types and fields within record structures on arbitrary byte boundaries with no padding.
align records — requests that multiple data items in record structures and derived-type structures without the SEQUENCE statement be naturally aligned, by adding padding as needed.
align recnbyte — aligns components of derived types and fields within record structures on the smaller of the size boundary specified (n) or the boundary that will naturally align them. n can be 1, 2, 4, 8, 16, or 32. The default value for n is 8. When you specify this option, each structure member after the first is stored on either the size of the member type or n-byte boundaries, whichever is smaller. For example, to specify 16 bytes as the packing boundary (or alignment constraint) for all structures and unions in the file prog1.f, use the following command:

ifx {-align rec16byte | /align:rec16byte} prog1.f

This option does not affect whether common blocks are naturally aligned or packed.

align sequence — aligns components of a derived type declared with the SEQUENCE statement (sequenced components) according to the alignment rules that are currently in use. The default alignment rules are to align unsequenced components on natural boundaries.
align nosequence — requests that sequenced components be packed regardless of any other alignment rules. Note that align none implies align nosequence.

If you specify an option for standards checking, align sequence is ignored.

align all — tells the compiler to add padding bytes whenever possible to obtain the natural alignment of data items in common blocks, derived types, and record structures. Specifies align dcommons, align records, align nosequence. This is the same as specifying align with no keyword.

Alternate Options:

align none — Linux: -noalign
align records — Linux: -align rec16byte, -Zp16
align norecords — Linux: -Zp1, -align rec1byte
align recnbyte — Linux: -Zp{1|2|4|8|16}
align all — Linux: -align commons -align dcommons -align records -align nosequence

-allow keyword (L*X only) — determines whether the compiler allows certain behaviors.

Arguments:

keyword — specifies the behaviors to allow or disallow. Possible values are:
- [no]fpp_comments — determines how the fpp preprocessor treats Fortran end-of-line comments in preprocessor directive lines.

Default:

fpp_comments — the compiler recognizes Fortran-style end-of-line comments in preprocessor lines.

Description:

This option determines whether the compiler allows certain behaviors.

allow nofpp_comments — tells the compiler to disallow Fortran-style end-of-line comments on preprocessor lines. Comment indicators have no special meaning.

Alternate Options: None

-altparam (L*X only)
-noaltparam (L*X only)

Allows alternate syntax (without parentheses) for PARAMETER statements. 🎀

Arguments: None

Default:

altparam — the alternate syntax for PARAMETER statements is allowed.

Description:

This option specifies that the alternate syntax for PARAMETER statements is allowed. The alternate syntax is:

PARAMETER c = expr [, c = expr] ...

This statement assigns a name to a constant (as does the standard PARAMETER statement), but there are no parentheses surrounding the assignment list.

In this alternative statement, the form of the constant, rather than implicit or explicit typing of the name, determines the data type of the variable.

Alternate Options:

altparam — Linux: None
noaltparam — Linux: None

-ansi-alias (L*X only)
-no-ansi-alias (L*X only)

Tells the compiler to assume certain rules of the Fortran standard regarding aliasing and array bounds.

Arguments: None

Default:

-ansi-alias — programs adhere to the Fortran standard's rules regarding aliasing and array bounds.

Description:

This option tells the compiler to assume certain rules of the Fortran standard regarding aliasing and array bounds.

It tells the compiler to assume that the program adheres to the following rules of the Fortran standard:

Arrays cannot be accessed outside of declared bounds.
A dummy argument may have its definition status changed only through that dummy argument, unless it has the TARGET attribute.

This option is similar to option assume nodummy_aliases with the additional restriction on array bounds.

If -no-ansi-alias (Linux*) or /Qansi-alias- (Windows*) is specified, the compiler assumes that the program might not follow the Fortran standard's rules regarding dummy argument aliasing and array bounds; this can possibly affect performance.

Alternate Options: None

-arch code (L*X only) — tells the compiler which features it may target, including which instruction sets it may generate.

Arguments:

code — indicates to the compiler a feature set that it may target, including which instruction sets 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.

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

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.
CORE-AVX-I — may generate the RDRND instruction, Intel(R) Advanced Vector Extensions (Intel(R) AVX), Intel(R) SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions.

AVX2 — may generate Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2), Intel(R) AVX, Intel(R) SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions.
AVX — may generate Intel(R) Advanced Vector Extensions (Intel(R) AVX), Intel(R) SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions.
SSE4.2 — may generate Intel(R) SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions.
SSE4.1 — may generate Intel(R) SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions.
SSSE3 — may generate SSSE3 instructions and Intel(R) SSE3, SSE2, and SSE instructions.
SSE3 — may generate Intel(R) SSE3, SSE2, and SSE instructions.

🌈 Default 🌈

varies — bestie, if the option arch is not specified, the default target architecture supports Intel(R) SSE2 instructions. That's just where we start, no cap.

💅 Description 💅

okay so this option is literally the one that tells the compiler which features it may target, including which instruction sets it may generate. like, it's the vibe check for your CPU. 🦋

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

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. so like, don't come for the device side with this one, it's not invited to that party. 🙈

Alternate Options

None. that's it. nothing. nada. 🎀

-assume keyword[, keyword...] (L*X only) — tells the compiler to make certain assumptions. yes, we're out here assuming things, and honestly it's giving main character energy. ✨

Arguments

keyword — specifies the assumptions to be made. the possible values are, and buckle up bestie because this list is long:
- none — disables all assume options. a clean slate, an icon, a fresh start. 🎀
- [no]bscc — determines whether the backslash character is treated as a C-style control character syntax in character literals.
- [no]buffered_io — determines whether data is immediately read from or written to disk or accumulated in a buffer. for variable length, unformatted files, it determines whether data is buffered on input or read directly from disk to user variables. 🍓
- [no]buffered_stdout — determines whether data is immediately written to the standard output device or accumulated in a buffer.
- [no]byterecl — determines whether units for the OPEN statement RECL specifier (record length) value in unformatted files are in bytes or longwords (four-byte units). bytes vs longwords, pick your fighter. 💀
- [no]cc_omp — determines whether conditional compilation as defined by the OpenMP Fortran API is enabled or disabled.
- [no]contiguous_assumed_shape — determines whether contiguity is assumed for assumed-shape dummy arguments.
- [no]contiguous_pointer — determines whether contiguity is assumed for pointers.
- [no]dummy_aliases — determines whether the compiler assumes that dummy arguments to procedures share memory locations with other dummy arguments or with COMMON variables that are assigned.
- [no]failed_images — determines whether the runtime system checks for failed images on a team of images when executing image control statements without a STAT= specifier, or when executing a call to MOVE_ALLOC or a collective or atomic subroutine that does not specify a STAT argument.
- [no]fpe_summary — determines whether a floating-point exceptions summary is displayed when a STOP or ERROR STOP statement is encountered. lowkey handy ngl. 🔥
- [no]ieee_compares — determines whether floating-point comparison operations are performed as IEEE signaling operations.
- [no]ieee_fpe_flags — determines whether the floating-point exception and status flags are saved on routine entry and restored on routine exit.
- [no]ieee_mode_restore — determines whether IEEE floating-point modes are saved and restored at procedure call sites should the procedure change them.
- [no]inline_cloc — determines whether calls to the C_LOC function in the intrinsic module ISO_C_BINDING are treated as external module procedure calls or if inline code is generated for them.
- [no]minus0 — determines whether the compiler uses Fortran 2003 or Fortran 90/77 standard semantics in the SIGN intrinsic when treating -0.0 and +0.0 as 0.0, and how it writes the value on formatted output. the whole -0.0 situation is so dramatic honestly 😭
- [no]nan_compares — determines whether code for floating-point comparison operations involving NaNs is generated, or if the compiler can generate a faster code sequence because it assumes no NaNs will be encountered. faster code, but you're assuming no NaNs, so like… be sure. 👀
- [no]old_boz — determines whether the binary, octal, and hexadecimal constant arguments in intrinsic functions INT, REAL, DBLE, and CMPLX are treated as signed integer constants.
- [no]old_e0g0_format — determines whether Fortran 2018 rules are used to format floating-point numbers that have G0.0 or E0 or ES0 format edit descriptors.
- [no]old_inquire_recl — determines the value of the RECL= specifier on an INQUIRE statement for an unconnected unit or a unit connected for stream access.

prior to Fortran 2018, this behavior was undefined — the scalar-int-variable in the RECL= specifier becomes defined with -1 if the file is unconnected, and -2 if the file is connected for stream access. 💅

[no]old_ldout_format — determines the output of integer and real values in list-directed and namelist-directed output.

[no]old_ldout_zero — bestie, this one decides the format of a floating-point zero that list-directed output spits out. old_ldout_zero gives you exponential format, and noold_ldout_zero gives you fractional format. ✨
[no]old_logical_assign — controls the behavior in assignment statements when logical values get assigned to numeric variables, and numeric values get assigned to logical variables. yes it's exactly as chaotic as it sounds 💅
[no]old_logical_ldio — decides whether NAMELIST and list-directed input accept logical values for numeric IO-list items, and numeric values for logical IO-list items. mixing vibes fr fr
[no]old_maxminloc — determines the results of the intrinsics MAXLOC and MINLOC when you hand them an empty array as an argument, or when every element of the mask is false. edge case icon 👑
[no]old_unit_star — determines whether unit * is treated the same as units 5 and 6, or is distinct. pick a lane, unit * 🎀
[no]old_xor — determines whether .XOR. is defined by the compiler as an intrinsic operator. retro operator moment ✨
[no]protect_allocates — determines whether memory allocation requests using the ALLOCATE statement are protected with critical sections, so you avoid random timing problems in a multi-threaded environment. safety girlie 🫶
[no]protect_constants — determines whether a constant actual argument, or a copy of it, is passed to a called routine. no cap, this matters 🌸
[no]protect_parens — determines whether the optimizer honors parentheses in REAL and COMPLEX expression evaluations by not reassociating operations. respect the parentheses, honestly 😭
[no]realloc_lhs — determines whether the compiler uses the current Fortran Standard rules or the old Fortran 2003 rules when interpreting assignment statements. old rules vs new rules, choose your fighter 💀
[no]recursion — determines whether procedures are compiled for recursion by default. recursion recursion recursion, iykyk 🔥
[no]source_include — determines whether the compiler searches for USE modules and INCLUDE files in the default directory, or in the directory where the source file is located. where u at bestie 🦋
[no]std_expon_output — determines whether the exponent letter E is omitted from the output of floating-point numbers with an exponent whose absolute value is in the range of 0-99, when the number is written with one of the format edit descriptors E, EN, ES, EX, or D, and a field width of zero is specified. very specific, very demure 🌸
[no]std_intent_in — determines whether the compiler assumes that dummy arguments with the INTENT(IN) attribute in a called procedure are not modified across a call, in accordance with the Fortran standard. trust the standard 💖
[no]std_minus0_rounding — determines whether to display a negative value that is not zero but rounds to zero on output with a leading minus sign. the minus sign said "i'm still here" 😭
[no]std_mod_proc_name — determines whether the names of module procedures are allowed to conflict with user external symbol names. name drama, iconic honestly 💅
[no]std_value — determines whether the VALUE attribute has the effect as if the actual argument is assigned to a temporary, and the temporary is then passed to the called procedure, so that subsequent changes to the value of the dummy argument do not affect the actual argument, in accordance with the Fortran standard. copy not share, periodt 🎀
[no]underscore — determines whether the compiler appends an underscore character to external user-defined names. lil _ bestie 🫶
[no]2underscores (Linux) — determines whether the compiler appends two underscore characters to external user-defined names. double underscore, double slay ✨
[no]writeable-strings — determines whether character constants go into non-read-only memory. putting them somewhere they can be written, lowkey wild 👀

✨ Default: ✨

nobscc — the backslash character is treated as a normal character in character literals. just a normal guy fr 💅
nobuffered_io — data in the internal buffer is immediately read from or written (flushed) to disk (OPEN specifier BUFFERED='NO'). Data read from variable length, unformatted files is read directly from disk to a user's variables.

If you set the FORT_BUFFERED environment variable to true, the default is assume buffered_io. 🫶

nobuffered_stdout — data is not buffered for the standard output device, but instead is written immediately to the device. no waiting around ✨
nobyterecl — units for OPEN statement RECL values with unformatted files are in four-byte (longword) units. four-byte units, noted 💖
nocc_omp — conditional compilation as defined by the OpenMP Fortran API is disabled unless option [q or Q]openmp is specified.

If compiler option [q or Q]openmp is specified, the default is assume cc_omp. 🔥

nocontiguous_assumed_shape — contiguity is not assumed for assumed-shape dummy arguments. no assumptions bestie 🌸
nocontiguous_pointer — contiguity is not assumed for pointers. same energy, pointer edition 🦋
nodummy_aliases — dummy arguments to procedures do not share memory locations with other dummy arguments, or with variables shared through use association, host association, or common block use. everyone gets their own space 💅
nofailed_images — when an image executes an image control statement without a STAT= specifier, or when executing a MOVE_ALLOC or collective or atomic subroutine without a STAT argument, the runtime system does not explicitly check for failed images on the current team. no extra checks happening here 👀
nofpe_summary — suppresses a summary of floating-point exceptions from being displayed when a STOP or ERROR STOP statement is encountered. no summary for u 😭
noieee_compares — floating-point comparison operations are not performed using IEEE signaling compares. regular compares only 🎀
noieee_fpe_flags — the flags are not saved on routine entry, and they are not restored on routine exit. flags said "i'll be here" and then weren't 💀
noieee_mode_restore — IEEE floating-point modes are not restored after return from a procedure call where the modes are altered. the modes stay altered, periodt 🌈
noinline_cloc — the C_LOC function from the intrinsic module ISO_C_BINDING is called as an external module procedure call. external call vibes ✨
nominus0 — compiler treats -0.0 and +0.0 as plain 0.0 inside the SIGN intrinsic (Fortran 90/77 style), and when it writes a 0.0 out in formatted output it gives you no sign at all. slay.
nan_compares — generates code for floating-point compares that actually checks for NaNs and gets you the same results you'd get with assume ieee_compares ✨ — with one little exception: a compare against a signaling NaN behaves like it was a quiet NaN.
noold_boz — the binary, octal and hexadecimal constant arguments you pass to the intrinsic functions INT, REAL, DBLE and CMPLX get treated as bit strings representing a value of that intrinsic's data type — like, the bits are not converted. periodt.
old_e0g0_format — formats output for the G0.0, E0 and ES0 edit descriptors the way it did before everyone conformed to the Fortran 2018 standard. G0.0 doesn't use the minimal width needed for a real value. 🫶

This setting makes the runtime always strip the exponent letter E out of the output for real values produced with the E0 and ES0 format edit descriptors.

old_inquire_recl — the scalar-int-variable in a RECL= specifier of an INQUIRE statement for an unconnected unit becomes defined with the value 0; and if that unit is connected for stream access, the value is undefined. 🙈
old_ldout_format — for list-directed and namelist-directed output, integers get written with a fixed width that depends on the integer kind, and zero real values get written using the E format.
old_ldout_zero — for list-directed output of a floating-point zero, exponential format is used instead of fractional output.
noold_logical_assign — okay so in the assignment statement L = N, where L is a logical variable and N is a numeric value, N is converted to integer if necessary, and then L gets .FALSE. if the integer value is 0, and .TRUE. if the integer value is -1 or 1 according to the setting of the compiler option fpscomp logicals.

And in the assignment statement N = L, where N is a variable of numeric type and L is a logical value: if L is .FALSE., N is assigned the value 0, converted to the type of N if necessary. If L is .TRUE., N is assigned the value 1 or -1, converted to the type of N if necessary, according to the setting of the compiler option fpscomp logicals.

The compiler option fpscomp logicals specifies that non-zero values are treated as true and zero values are treated as false. The literal constant integer value of 0.

The default is fpscomp nologicals, which specifies that odd integer values (low bit one) are treated as true and even integer values (low bit zero) are treated as false. The literal constant .TRUE. has an integer value of -1 and the literal constant .FALSE. has an integer value of 0. 💅

noold_logical_ldio — tells the compiler that NAMELIST and list-directed input cannot accept logical values (T, F, etc.) for numeric (integer, real and complex) IO-list items, or numeric values for logical IO-list items. If you specify this and then go give a logical value for a numeric item (or a numeric value for a logical item) in NAMELIST and list-directed input… runtime error. literally. 💀
old_maxminloc — MAXLOC and MINLOC return 1 when you hand them an empty array as an argument, or when every element of the mask is false.
old_unit_star — the READs or WRITEs to UNIT=* go to stdin or stdout respectively, even if UNIT=5 or 6 has been connected to another file. iconic behaviour tbh.
old_xor — the intrinsic operator .XOR. is defined by the compiler. 🦋
noprotect_allocates — memory allocation requests using the ALLOCATE statement are not protected with critical sections and may hit random timing problems in a multi-threaded environment. ⚠️ be careful bestie.
protect_constants — a constant actual argument is passed to a called routine, and any attempt to modify it results in an error. no cap, hands off.
noprotect_parens — the optimizer reorders REAL and COMPLEX expressions without regard for parentheses, reassociating operations if that produces faster executing code. 😭
realloc_lhs — tells the compiler that when the left-hand side of an assignment is an allocatable object, it should be reallocated to the shape of the right-hand side of the assignment before the assignment happens. This is the current Fortran Standard definition. Heads up: this feature may cause extra overhead at runtime. The option standard-realloc-lhs has the same effect as assume realloc_lhs. ✨
norecursion — tells the compiler that all procedures are not compiled for recursion, unless they're declared with the RECURSIVE keyword. Fortran 2018 specifies the default mode of compilation is recursion; previous standards specified no recursion. This default will change in a future release. 👀
source_include — the compiler searches for USE modules and INCLUDE files in the directory where the source file is located.
nostd_expon_output — floating-point numbers with an exponent whose absolute value is in the range of 0-99 that are output with the E, EN, ES or D format descriptor when the width specified is zero will be output with the exponent letter E omitted from the output.
std_intent_in — the compiler assumes that dummy arguments with the INTENT(IN) attribute in a called procedure are not modified across a call, in accordance with the Fortran standard. PSA: this setting is deprecated and may be removed in a future release. 🫶
std_minus0_rounding — a negative value that isn't zero but rounds to zero on output gets displayed with a leading minus sign. For example, the value -0.00000001 in F5.1 format will be displayed as -0.0 rather than as 0.0. ate.
nostd_mod_proc_name — the compiler allows the names of module procedures to conflict with user external symbol names. chaos permitted 💀
std_value — the compiler assumes the VALUE attribute has the effect as if the actual argument is assigned to a temporary, and the temporary is then passed to the called procedure, so that subsequent changes to the value of the dummy argument don't affect the actual argument — in accordance with the Fortran standard. 💖
nounderscore (Windows) / underscore (Linux) — On Windows* systems, the compiler does not append an underscore character to external user-defined names. On Linux* systems, the compiler does append an underscore character to external user-defined names.
no2underscores (Linux) — the compiler does not append two underscore characters to external user-defined names that contain an embedded underscore.
nowriteable-strings — the compiler puts character constants into read-only memory. 🔒

🎀 Description 🎀

This option specifies assumptions to be made by the compiler. like, the whole vibe check of what it's willing to just assume about your code. 🦋

assume none — disables all the assume options. nope, none of them, we're starting fresh ✨
assume bscc — tells the compiler to treat the backslash character ( as a C-style control (escape) character syntax in character literals. The bscc keyword means "BackSlashControlCharacters." iykyk 💅
assume buffered_io — tells the compiler to accumulate records in a buffer. This sets the default for opening sequential files to BUFFERED='YES', which also happens if the FORT_BUFFERED runtime environment variable is specified. 🌸

When this option is on, the internal buffer gets filled — possibly by a whole bunch of record input statements (READ) or output statements (WRITE) — before it ever gets read from disk, or written to disk, by the Fortran runtime system. And heads up bestie: if a file is opened for direct access, I/O buffering is just ignored, periodt. 🫶

Using buffered reads and writes usually makes disk I/O way more efficient, because it handles larger blocks of data on disk less often. But 😭 if you request buffered writes, records that haven't been written to disk yet may be lost in the event of a system failure. That's the trade, ngl.

The OPEN statement BUFFERED specifier applies to one specific logical unit. In contrast, the assume [no]buffered_io option and the FORT_BUFFERED environment variable apply to all Fortran units. iykyk 💅

assume buffered_stdout — tells the Fortran runtime system to accumulate data for the standard output device in a buffer. When the buffer is full, or the user executes a FLUSH on OUTPUT_UNIT in intrinsic module ISO_FORTRAN_ENV, the data gets displayed on the standard output unit. ✨

Using buffered writes may be more efficient in time and space, but use assume nobuffered_stdout if you want data displayed immediately on the standard output device — like, say, for an input prompt. 🎀

assume [no]buffered_stdout does not affect and is not affected by assume [no]buffered_io. They're literally living separate lives.

After compiling with this option, the default blocksize for stdout is 8 KB.

assume byterecl — specifies that the units for the OPEN statement RECL specifier (record length) value are in bytes for unformatted data files, not longwords (four-byte units). For formatted files, the RECL value is always in bytes. 🦋

If a file is open for unformatted data and assume byterecl is specified, INQUIRE returns RECL in bytes; otherwise, it returns RECL in longwords. An INQUIRE returns RECL in bytes if the unit is not open.

assume cc_omp — enables conditional compilation as defined by the OpenMP Fortran API. That is, when !$space appears in free-form source or c$spaces appears in column 1 of fixed-form source, the rest of the line is accepted as a Fortran line. cute lil compiler easter egg 🌸
assume contiguous_assumed_shape — tells the compiler to assume contiguity for assumed-shape dummy arguments. This may aid in optimization. However, if you're mistaken about the contiguity of your data, it could result in runtime failures. 💀 so like... be sure.
assume contiguous_pointer — tells the compiler to assume contiguity for pointers. This may aid in optimization. However, if you're mistaken about the contiguity of your data, it could result in runtime failures. same warning, different victim 🙈
assume dummy_aliases — tells the compiler that dummy (formal) arguments to procedures share memory locations with other dummy arguments (aliases) or with variables shared through use association, host association, or common block use.

Specify the option when you compile the called subprogram. The program semantics involved with dummy aliasing do not strictly obey Standard Fortran and they slow performance, so you get better runtime performance if you do not use this option.

However, if a program depends on dummy aliasing and you do not specify this option, the runtime behavior of the program will be unpredictable. In such programs, the results will depend on the exact optimizations that are performed. In some cases, normal results will occur, but in other cases, results will differ because the values used in computations involving the offending aliases will differ. it's giving chaos 😭

assume failed_images — tells the runtime system to check for failed images on the current team when executing an image control statement that does not have a STAT= specifier, or when a MOVE_ALLOC or collective or atomic subroutine without a STAT argument is executed. 👑

A failed image check is made each time an image control statement that has a STAT= specifier is executed, and when a call to MOVE_ALLOC or a collective or atomic subroutine with a STAT argument is executed.

assume fpe_summary — causes a summary of floating-point exceptions that occurred during program execution to be displayed when a STOP or ERROR STOP statement is encountered. Counts will be shown for each exception. This is the behavior specified by the Fortran 2003 standard. ⭐

Note that if there is no STOP or ERROR STOP statement, no summary is displayed. no exit, no tea 🍓

assume ieee_compares — tells the compiler to generate IEEE signaling comparison operations for the binary floating-point comparison operators.
assume ieee_fpe_flags — tells the compiler to save floating-point exception and status flags on routine entry and restore them on routine exit.

This option can slow runtime performance because it provides extra code to save and restore the floating-point exception and status flags (and the rounding mode) on entry to and exit from every routine compiled with the option.

This option can be used to get the full Fortran Standard behavior of intrinsic modules IEEE EXCEPTIONS, IEEE ARITHMETIC, and IEEE FEATURES, which require that if a flag is signaling on routine entry, the processor will set it to quiet on entry and restore it to signaling on return. If a flag signals while the routine is executing, it will not be set to quiet on routine exit. 🧚

Options fpe and fpe-all can be used to set the initial state for which floating-point exceptions will signal.

assume ieee_mode_restore — tells the compiler to generate code at a procedure call site to save the state of the IEEE floating-point modes prior to the call, and to restore the modes upon return from the call. This behavior is specified by the Fortran standard. 🌈
assume inline_cloc — tells the compiler to generate inline code for the C_LOC function from the intrinsic module procedure ISO_C_BINDING. By default, all procedures in the intrinsic modules are called as external procedures.
assume minus0 — tells the compiler to use Fortran 95 standard semantics for the treatment of the IEEE* floating value -0.0 in the SIGN intrinsic, which distinguishes the difference between -0.0 and +0.0, and to write a value of -0.0 with a negative sign on formatted output. negative zero gets its moment 💅
assume nan_compares — tells the compiler to generate code for floating-point exceptions using an ieee_compare comparison code sequence such that compares to a NaN get correct answers. Signaling NaNs behave like quiet NaNs. Specifying nonan_compares tells the compiler that floating-point compares will not involve NaN operands, which allows a faster code sequence to be generated, but will give undefined behavior if an operand in a floating-point comparison is a NaN. 💀 choose wisely
assume old_boz — tells the compiler that the binary, octal, and hexadecimal constant arguments in intrinsic functions INT, REAL, DBLE, and CMPLX should be treated as signed integer constants.
assume noold_e0g0_format — tells the compiler to use Fortran 2018 standard format for real numbers that are output using the G0.0, E0, and ES0 edit descriptors. 🎀
assume noold_inquire_recl — okay so this one tells the compiler to use Fortran 2018 semantics for RECL= on an INQUIRE statement. 💅

If the unit is unconnected, the scalar-int-variable of the RECL= specifier becomes defined with the value -1. If the unit is connected for stream access, it becomes defined with the value -2. Slay, now you know. ✨

assume noold_ldout_format — tells the compiler to use Fortran 2003 standard semantics for output of integer and real values in list-directed and namelist-directed output. 🎀

Integers are written using an I0 format with a leading blank for spacing.

Real and complex values are written using an E or F format with a leading blank for spacing. The format used depends on the magnitude of the value. Values that are zero are written using an F format.

assume noold_ldout_zero — for list-directed output of a floating-point zero, fractional format is used instead of exponential output. 🦋

Early versions of the Fortran standard specified exponential format should be used for list-directed output of a floating-point zero value. Newer versions of the standard specify that fractional format should be used. Glow-up behavior, honestly.

assume old_logical_assign — bestie, this one is a whole vibe. 😭

In the assignment statement L = N, where L is a logical variable and N is a numeric value, N is converted to integer if necessary, and L is assigned the bit value of the integer value without conversion.

In the assignment statement N = L, where N is a variable of numeric type and L is a logical value, N is assigned the bit value of the value of L without conversion.

assume old_logical_ldio — logical values are allowed for numeric items and numeric values are allowed for logical items. Chaotic, but go off. 👑
assume noold_maxminloc — tells the compiler that MAXLOC and MINLOC should return 0 when given an empty array as an argument or every element of the mask is false. 💀

Compared to the default setting (old_maxminloc), this behavior may slow performance because of the extra code needed to check for an empty array argument or for an all-false mask. The price of correctness, ngl.

assume noold_unit_star — tells the compiler that READs or WRITEs to UNIT=* go to the file to which UNIT=5 or 6 is connected. 🫶
assume noold_xor — prevents the compiler from defining .XOR. as an intrinsic operator. This lets you use .XOR. as a user-defined operator. It's literally a Fortran 2003 feature. ✨
assume protect_allocates — memory allocation requests using the ALLOCATE statement are protected with critical sections to avoid random timing problems in a multi-threaded environment in some distributions and configurations. Safety first, queen. 🎀
assume noprotect_constants — tells the compiler to pass a copy of a constant actual argument. This copy can be modified by the called routine, even though the Fortran standard prohibits such modification. The calling routine does not see any modification to the constant. 🙈
assume protect_parens — tells the optimizer to honor parentheses in REAL and COMPLEX expression evaluations by not reassociating operations. For example, (A+B)+C would not be evaluated as A+(B+C). 🦋

If assume noprotect_parens is specified, (A+B)+C would be treated the same as A+B+C and could be evaluated as A+(B+C) if it produced faster executing code.

Such reassociation could produce different results depending on the sizes and precision of the arguments.

For example, in (A+B)+C, if B and C had opposite signs and were very large in magnitude compared to A, A+B could result in the value as B; adding C would result in 0.0. With reassociation, B+C would be 0.0; adding A would result in a non-zero value. Math is wild, fr fr. 😭

assume norealloc_lhs — the compiler uses the old Fortran 2003 rules when interpreting assignment statements. The left-hand side is assumed to be allocated with the correct shape to hold the right-hand side. If it is not, incorrect behavior will occur. 🚨 The option nostandard-realloc-lhs has the same effect as assume norealloc_lhs.
assume recursion — tells the compiler to compile procedures that are declared without the RECURSIVE or NON_RECURSIVE keyword as recursive procedures. ✨

In Fortran 2018, these procedures are compiled for recursion by default; in previous standards they were compiled as non-recursive procedures. The current default behavior is non-recursive. This will change in a future release. Mark your calendars, bestie. 🗓️

assume nosource_include — tells the compiler to search the default directory for module files specified by a USE statement or source files specified by an INCLUDE statement. This option affects fpp preprocessor behavior and the USE statement. 💜
assume nostd_expon_output — tells the runtime libraries to omit the exponent letter E in the output of a floating point number with an exponent whose absolute value is in the range of 0-99 when using the edit descriptors E, EN, ES, EX or D and a field width of zero is specified. 🔥

The standard requires the exponent letter E to be output in these cases; by default it is not.

If you specify option standard-semantics, it sets option assume std_expon_output.

assume nostd_intent_in — tells the compiler to assume that dummy arguments with the INTENT(IN) attribute in a called procedure may be modified across a call. This is not in accordance with the Fortran standard. 😬

If you specify option standard_semantics, it sets option assume std_intent_in.

assume nostd_minus0_rounding — tells the compiler to use pre-Fortran 2008 standard semantics for the treatment of IEEE* floating values that are negative, non-zero, and when rounded for display are zero. The value should be printed without a leading minus sign. 🙈

For example, the floating value -0.00000001 when rounded in F5.1 format will be displayed as 0.0. Use assume std_minus0_rounding to use Fortran 2008 standard semantics to display this value as -0.0 when rounded in F5.1 format.

assume [no]std_minus0_rounding does not affect and is not affected by assume [no]minus0. The former controls printing of a minus sign for non-zero numbers while the latter controls printing of actual signed zero values. Two different things, don't mix them up bestie. 💅

assume std_mod_proc_name — tells the compiler to revise the names of module procedures so they do not conflict with user external symbol names. For example, procedure proc in module m would be named m_MP_proc. The Fortran 2003 Standard requires that module procedure names not conflict with other external symbols. 👑

By default, procedure proc in module m would be named m_mp_proc, which could conflict with a user-defined external name m_mp_proc. The audacity, honestly. 💀

assume nostd_value — tells the compiler to use pre-Fortran 2003 standard semantics for the VALUE attribute so that the value of the actual argument is passed to the called procedure, not the address of the actual argument nor the address of a copy of the actual argument. 🎀

`assume underscore` ✨

Okay so assume underscore tells the compiler to append an underscore character to external user-defined names: the main program name, named common blocks, BLOCK DATA blocks, global data names in MODULEs, and names implicitly or explicitly declared EXTERNAL. The name of a blank (unnamed) common block remains _BLNK__, and Fortran intrinsic names are not affected. 💅

`assume 2underscores` (Linux) 🦋

This one tells the compiler to append two underscore characters to external user-defined names that contain an embedded underscore: the main program name, named common blocks, BLOCK DATA blocks, global data names in MODULEs, and names implicitly or explicitly declared EXTERNAL. The name of a blank (unnamed) common block remains _BLNK__, and Fortran intrinsic names are not affected.

This option does not affect external names that do not contain an embedded underscore. By default, the compiler only appends one underscore to those names. For example, if you specify assume 2underscores for external names my_program and myprogram, my_program becomes my_program__, but myprogram becomes myprogram_. No cap.

`assume writeable-strings` 🎀

Tells the compiler to put character constants into non-read-only memory.

Alternate Options:

assume nobscc — Linux: -nbs
assume dummy_aliases — Linux: -common-args
assume protect_parens — Linux: -fprotect-parens
assume realloc_lhs — Linux: -standard-realloc-lhs
assume recursion — Linux: -recursive

`-auto` (LX only) / `-noauto` (LX only) 🫶

Causes all local, non-SAVEd variables to be allocated to the runtime stack.

Arguments:

None

Default:

varies — Items that are declared in a main program are not necessarily allocated on the stack, but anything declared inside a function or subroutine (unless it's initialized) is always on the stack.

The default is also auto if one of the following options are specified:

recursive
[q or Q]openmp

Description:

This option places local variables (scalars and arrays of all types), except those declared as SAVE, on the runtime stack. It is as if the variables were declared with the AUTOMATIC attribute.

It does not affect variables that have the SAVE attribute or ALLOCATABLE attribute, or variables that appear in an EQUIVALENCE statement or in a common block.

If you want to cause variables to be placed in static memory, specify option [Q]save. If you want only scalar variables of certain intrinsic types to be placed on the runtime stack, specify option auto-scalar.

Alternate Options:

auto — Linux: None
noauto — Linux: -save

`-auto-scalar` (L*X only) 🌸

Causes scalar variables of intrinsic types INTEGER, REAL, COMPLEX, and LOGICAL that do not have the SAVE attribute to be allocated to the runtime stack. This is a deprecated option that may be removed in a future release.

Arguments:

None

Default:

-auto-scalar — Scalar variables of intrinsic types INTEGER, REAL, COMPLEX, and LOGICAL that do not have the SAVE attribute are allocated to the runtime stack.

Note that the default changes to option auto if one of the following options are specified:

recursive
[q or Q]openmp

Description:

This option causes allocation of scalar variables of intrinsic types INTEGER, REAL, COMPLEX, and LOGICAL to the runtime stack. It is as if they were declared with the AUTOMATIC attribute.

It does not affect variables that have the SAVE attribute (which include initialized locals) or that appear in an EQUIVALENCE statement or in a common block.

This option may provide a performance gain for your program, but if your program depends on variables having the same value as the last time the routine was invoked, your program may not function properly. Variables that need to retain their values across subroutine calls should appear in a SAVE statement.

You cannot specify option save or auto with this option.

NOTE: On Windows NT* systems, there is a performance penalty for addressing a stack frame that is too large. This penalty may be incurred with [Q]auto because arrays are allocated on the stack along with scalars. However, with /Qauto-scalar, you would have to have more than 32K bytes of local scalar variables before you incurred the performance penalty. /Qauto-scalar enables the compiler to make better choices about which variables should be kept in registers during program execution.

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 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 — ok so this one 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. it's giving "everything, all at once" 💅
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. basically it 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. this one 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.

✨ bestie you can specify more than one code value. when you're specifying more than one code value, each value must be separated with a comma. see the Examples section below, iykyk.

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:

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

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. main character energy from the baseline tbh 💀

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 ifx 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, that's the instruction. go report it.)

Alternate Options:

None

`-Bdir` (L*X only)

specifies a directory that can be used to find include files, libraries, and executables. one little flag, three jobs, obsessed 💖

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. (yes, with the space in the original — copying it exactly, don't come for me 🫶)

Alternate Options:

None

`-Bdynamic` (L*X only)

enables dynamic linking of libraries at runtime. slay, but runtime-flavored 💅

Arguments:

None

Default:

OFF — limited dynamic linking occurs.

Description:

this option enables dynamic linking of libraries at runtime. smaller executables are created than with static linking. 🎀

this option is placed in the linker command line corresponding to its location on the user command line. it controls the linking behavior of any library that is passed using the command line.

all libraries on the command line following option -Bdynamic are linked dynamically until the end of the command line or until a -Bstatic option is encountered. the -Bstatic option enables static linking of libraries. it's literally a relay race between the two 🏃‍♀️

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

Alternate Options:

None

`-Bstatic` (L*X only)

enables static linking of a user's library. the calm, collected sibling of -Bdynamic 🌸

Arguments:

None

Default:

OFF — default static linking occurs.

Description:

this option enables static linking of a user's library.

this option is placed in the linker command line corresponding to its location on the user command line. it controls the linking behavior of any library that is passed using the command line.

all libraries on the command line following option -Bstatic are linked statically until the end of the command line or until a -Bdynamic option is encountered. the -Bdynamic option enables dynamic linking of libraries. 🔁

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

Alternate Options:

None

`-Bsymbolic` (L*X only)

binds references to all global symbols in a program to the definitions within a user's shared library. it's giving "you will respect my definitions" 👑

Arguments:

None

Default:

OFF — when a program is linked to a shared library, it can override the definition within the shared library.

Description:

this option binds references to all global symbols in a program to the definitions within a user's shared library.

this option is only meaningful on Executable Linkage Format (ELF) platforms that support shared libraries.

CAUTION: ⚠️ this option can have unintended side-effects of disabling symbol preemption in the shared library. like, genuinely be careful with this one, bestie — it's not a vibe, it's a side effect.

NOTE: this one is host compilation only bestie 💅 — when offloading is on, it does not impact device-specific compilation.

Alternate Options:

None

🦋 `-Bsymbolic-functions` (L*X only)

Binds references to all global function symbols in a program to the definitions within a user's shared library. Iconic behaviour, no notes.

Arguments:

None

Default:

OFF — when a program is linked to a shared library, it can override the definition within the shared library.

Description:

This option binds references to all global function symbols in a program to the definitions within a user's shared library. Slay, but also very niche.

It's only meaningful on Executable Linkage Format (ELF) platforms that support shared libraries. iykyk.

CAUTION: this option can have unintended side-effects of disabling symbol preemption in the shared library. Like, it's giving "surprise plot twist" energy — be careful. ⚠️

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

Alternate Options:

None

🎀 `-c` (L*X only)

Causes the compiler to generate an object only and not link. Literally just compile, bestie. No linking era.

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. Compile era, then it says bye 👋

The compiler generates an object file for each Fortran source file. One per file, no cap. 🗂️

🌸 `-ccdefault` keyword (L*X only)

Specifies the type of carriage control used when a file is displayed at a terminal screen. Yes we're talking about carriage control in the year of our lord, and yes it still matters. 🚂

Arguments:

keyword — specifies the carriage-control setting to use. Possible values are:
- none — tells the compiler to use no carriage control processing.
- default — tells the compiler to use the default carriage-control setting.
- fortran — tells the compiler to use normal Fortran interpretation of the first character. For example, the character 0 causes output of a blank line before a record.
- list — tells the compiler to output one line feed between records.

Default:

ccdefault default — the compiler uses the default carriage control setting.

Description:

This option specifies the type of carriage control used when a file is displayed at a terminal screen (units 6 and *). It provides the same functionality as using the CARRIAGECONTROL specifier in an OPEN statement. Same vibe, different door. ✨

The default carriage-control setting can be affected by the vms option. If option vms is specified with ccdefault default, carriage control defaults to normal Fortran interpretation (ccdefault fortran) if the file is formatted and the unit is connected to a terminal. If option novms (the default) is specified with ccdefault default, carriage control defaults to list (ccdefault list). The plot thickens 💀

Alternate Options:

None

💜 `-check` [keyword[, keyword...]] (LX only), `-nocheck` (LX only)

Checks for certain conditions at runtime. Your little runtime bodyguard 🫶

Arguments:

keyword — specifies the conditions to check. Possible values are:
- none — disables all check options.
- [no]arg_temp_created — determines whether checking occurs for actual arguments copied into temporary storage before routine calls.
- [no]assume — determines whether checking occurs to test that the scalar-logical-expression in the ASSUME directive is true, or that the addresses in the ASSUME_ALIGNED directive are aligned on the specified byte boundaries.
- [no]bounds — determines whether checking occurs for array subscript and character substring expressions.
- [no]contiguous — determines whether the compiler checks pointer contiguity at pointer-assignment time.
- [no]format — determines whether checking occurs for the data type of an item being formatted for output.
- [no]output_conversion — determines whether checking occurs for the fit of data items within a designated format descriptor field.
- [no]pointers — determines whether checking occurs for certain disassociated or uninitialized pointers or unallocated allocatable objects.
- [no]shape — determines whether array conformance checking is performed.
- [no]stack — determines whether checking occurs on the stack frame.
- [no]teams — determines whether the runtime system diagnoses non-standard coarray team usage.
- [no]udio_iostat — determines whether conformance checking occurs when user-defined derived type input/output routines are executed.
- [no]uninit — determines whether checking occurs for uninitialized variables. This setting is only available for Linux.
- all — enables all check options.

CAUTION: files compiled with option check all should also be linked with this same option, or the link step may fail. Fr fr, link it the same way or it's not gonna be a good time. 😭

Default:

nocheck — no checking is performed for runtime failures. Note that if option vms is specified, the defaults are check format and check output_conversion.

Description:

This option checks for certain conditions at runtime.

NOTE: -check all now behaves as -check all -check nouninit. Setting -check uninit and linking with libraries not built with this option, such as Intel(R) oneAPI Math Kernel Library (oneMKL) or Intel(R) MPI Library, causes runtime failures. -check uninit is no longer set by -check all. Not me warning you twice 💀

Here's the whole glow-up menu, option by option:

check none — disables all check options (same as nocheck).
check arg_temp_created — enables runtime checking on whether actual arguments are copied into temporary storage before routine calls. If a copy is made at runtime, an informative message is displayed.
check assume — enables runtime checking on whether the scalar-logical-expression in the ASSUME directive is true and that the addresses in the ASSUME_ALIGNED directive are aligned on the specified byte boundaries. If the test is .FALSE., a runtime error is reported and the execution terminates. Periodt. 🛑
check bounds — enables compile-time and runtime checking for array subscript and character substring expressions. An error is reported if the expression is outside the dimension of the array or the length of the string.

For array bounds, each individual dimension is checked. For arrays that are dummy arguments, only the lower bound is checked for a dimension whose upper bound is specified as * or where the upper and lower bounds are both 1.

For some intrinsics that specify a DIM= dimension argument, such as LBOUND, an error is reported if the specified dimension is outside the declared rank of the array being operated upon.

Once the program is debugged, omit this option to reduce executable program size and slightly improve runtime performance. Debug era ➡️ ship era ✨

It is recommended that you do bounds checking on unoptimized code. If you use option check bounds on optimized code, it may produce misleading messages because registers (not memory locations) are used for bounds values. Lowkey messy, so trust the recommendation 🫠

check contiguous — tells the compiler to check pointer contiguity at pointer-assignment time. This will help prevent programming errors such as assigning contiguous pointers to non-contiguous objects.
check format — issues the runtime FORVARMIS fatal error when the data type of an item being formatted for output does not match the format descriptor being used (for example, a REAL*4 item formatted with an I edit descriptor). fatal means fatal, bestie 💅
check noformat — with this setting, the data item is formatted using the specified descriptor unless the length of the item cannot accommodate the descriptor (for example, it is still an error to pass an INTEGER*2 item to an E edit descriptor). 🫶
check output_conversion — issues the runtime OUTCONERR continuable error message when a data item is too large to fit in a designated format descriptor field without loss of significant digits. Format truncation occurs, the field is filled with asterisks (*), and execution continues. 😭
check pointers — enables runtime checking for disassociated or uninitialized Fortran pointers, unallocated allocatable objects, and integer pointers that are uninitialized. pointer chaos gets caught ✨
check shape — enables compile-time and runtime array conformance checking in contexts where it is required by the standard. These include the right-hand and left-hand side of intrinsic and elemental defined assignment, the operands of intrinsic and elemental defined binary operations, two or more array arguments to ELEMENTAL procedures, the ARRAY= and MASK= arguments to intrinsic procedures as required, and the arguments to the intrinsic module procedures IEEE_SET_FLAG and IEEE_SET_HALTING_MODE.

In an ALLOCATE statement with array bounds specified for an allocate-object and with SOURCE=source specified, the allocate-object must conform with source.

Note that you can specify a setting in the warn option to choose whether array conformance violations are diagnosed with errors or warnings. shape-checking lore 👑

check stack — enables checking on the stack frame. The stack is checked for buffer overruns and buffer underruns. This option also enforces local variables initialization and stack pointer verification.

This option disables optimization and overrides any optimization level set by option O. optimization? not today 💀

check teams — enables checking for non-standard coarray team usage. For example, ifx permits the TEAM argument to NUM_IMAGES to be a type TEAM_TYPE variable which describes a team that is not the current or an ancestor of the current team.

When check teams is specified, a message is generated each time a non-standard coarray extension is detected. team drama detector 🦋

check uninit — (Linux) 💖 uses the LLVM Memory Sanitizer (MSAN) to enable run-time checking on uninitialized stack- or heap-allocated variables. If such a variable is read before it is written at runtime, a MSAN message that details the call stack of the read instruction and the call stack of the allocation instruction of the variable will be issued. The program terminates right after a MSAN message is issued.

To get source information about the call stacks in a MSAN message, do the following:

Compile your program with option -g1 or above. For example:

ifx -check uninit -g1 myprog.f90 -o myprog.exe

Run your program with the MSAN_SYMBOLIZER_PATH environment variable set to the executable llvm-symbolizer in your compiler installation. For example:

MSAN_SYMBOLIZER_PATH=${ONEAPI_ROOT}/compiler/latest/linux/bin-llvm/llvm-symbolizer myprog.exe

If you specify option -check uninit, you cannot also specify option -static.

To ensure that the required runtime libraries are linked and correctly initialized, specify option -check uninit in the link command if any part of the object file is compiled with this option.

NOTE: For MSAN to be accurate, your whole program, including the library code used by the program, needs to be compiled with option -check uninit (or its equivalent if it is not a Fortran source file, such as option -fsanitize=memory for C/C++); otherwise, you may get false positive reports on uninitialized variables.

Since every Fortran program links by default with the static Fortran runtime library and the runtime library’s dependencies, ifx provides a set of those memory-sanitized static libraries in the compiler installation and uses them when you link your Fortran program with option -check uninit.

No memory-sanitized dynamic Fortran runtime library is provided in the installation.

Consequently, if you link your program with option -check uninit and specify option -shared-intel to force the use of the dynamic Fortran runtime library, your final executable will be linked with the regular, unsanitized dynamic Fortran runtime library. You may then see false positive MSAN messages when you run this executable.

Therefore, for option -check uninit to be effective, do not link your program with option -shared-intel.

For more information on the Memory Sanitizer, see: https://clang.llvm.org/docs/MemorySanitizer.html.

CAUTION: Files compiled with option check uninit should also be linked with this same option, or the link step may fail.

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

Windows: this setting is not currently available on Windows because the Memory Sanitizer is not supported on Windows. not available, no cap 🙈

check all — enables all check options. This is the same as specifying check with no keyword.

This option disables optimization and overrides any optimization level set by option O.

To get more detailed location information about where an error occurred, use option traceback. all the checks, all at once ✨

Alternate Options:

check none — Linux: -nocheck
check bounds — Linux: -CB
check shape — Linux: -CS
check uninit — Linux: -CU
check all — Linux: -check, -C

-coarray[=keyword] (L*X only) — enables the coarray feature. 🦋

Arguments:

keyword — specifies the memory system where the coarrays will be implemented. Possible values are:
- shared — indicates that multiple images will be created. This is the default.
- single — indicates a configuration where the image does not contain self-replication code. This results in an executable with a single running image.

This configuration can be useful for debugging purposes, even though there are no inter-image interactions.

Default:

OFF — coarrays are not enabled unless you specify this option.

Description:

This option enables the coarray features first introduced in the Fortran 2008 Standard. It enables any coarray syntax in your program. If this option is not specified, coarray syntax is rejected.

It also tells the driver to link against appropriate libraries, and to create the appropriate executables.

Keywords can be specified multiple times; however, if keyword single is specified anywhere on the command line, it takes precedence.

You can specify option [Q]coarray-num-images to specify the default number of images that can be used to run a coarray executable. If you do not specify that option, you get the number of execution units on the current system.

You can specify the [Q]coarray-config-file option to specify the name of a Message Passing Interface (MPI) configuration file.

Options [Q]coarray-num-images and [Q]coarray-config-file are valid for all keyword values. coarray config, iconic 💜

Alternate Options:

None

-coarray-config-file=filename (L*X only) — specifies the name of a Message Passing Interface (MPI) configuration file. 🎀

Arguments:

filename — is the name of the MPI configuration file. You can specify a path.

Default:

OFF — when coarrays are enabled, the compiler uses default settings for MPI.

Description:

This option is literally the glow-up your coarray build needs for multi-node stuff 💅 — it names the Message Passing Interface (MPI) configuration file. The compiler reads that file when it processes coarrays, and it's what configures the MPI for multi-node operations.

Heads up though, bestie: this option has no affect unless you also specify the [Q]coarray option, which is required to create the coarray executable. So like… don't expect it to do anything on its own, okay?

Also important: when a setting is specified in environment variable FOR_COARRAY_CONFIG_FILE, it overrides the compiler option setting. The env var wins, periodt.

Alternate Options:

None

-coarray-num-images=n (L*X only) — specifies the default number of images that can be used to run a coarray executable.

Arguments:

n — is the default number of images. The limit is determined from the system configuration.

Default:

OFF — the number of images is determined at runtime.

Description:

This option specifies the default number of images that can be used to run a coarray executable.

This option has no affect unless you also specify the [Q]coarray option. This option is required to create the coarray executable.

Note that when a setting is specified in environment variable FOR_COARRAY_NUM_IMAGES, it overrides the compiler option setting. Env var stays undefeated 👑

Alternate Options:

None

-convert keyword (L*X only) — specifies the format of unformatted files containing numeric data. This is the "my data came from a different machine and it's giving ancient vibes" option 🧚

Arguments:

keyword — specifies the format for the unformatted numeric data. Possible values are:
- native — specifies that unformatted data should not be converted.
- big_endian — specifies that the format will be big endian for integer data and big endian IEEE floating-point for real and complex data.
- cray — specifies that the format will be big endian for integer data and CRAY* floating-point for real and complex data.
- fdx (Linux*) — specifies that the format will be little endian for integer data, and VAX processor floating-point format F_floating, D_floating, and IEEE binary128 for real and complex data.
- fgx (Linux) — specifies that the format will be little endian for integer data, and VAX processor floating-point format F_floating, G_floating, and IEEE binary128 for real and complex data.
- ibm — specifies that the format will be big endian for integer data and IBM* System370 floating-point format for real and complex data.
- little_endian — specifies that the format will be little endian for integer data and little endian IEEE floating-point for real and complex data.
- vaxd — specifies that the format will be little endian for integer data, and VAX* processor floating-point format F_floating, D_floating, and H_floating for real and complex data.
- vaxg — specifies that the format will be little endian for integer data, and VAX processor floating-point format F_floating, G_floating, and H_floating for real and complex data.

Default:

convert native — no conversion is performed on unformatted files containing numeric data. Chill, do-nothing default, we love to see it ✨

Description:

This option specifies the format of unformatted files containing numeric data.

convert native — specifies that unformatted data should not be converted.
convert big_endian — specifies that the format will be big endian for INTEGER*1, INTEGER*2, INTEGER*4, or INTEGER*8, and big endian IEEE floating-point for REAL*4, REAL*8, REAL*16, COMPLEX*8, COMPLEX*16, or COMPLEX*32.
convert cray — specifies that the format will be big endian for INTEGER*1, INTEGER*2, INTEGER*4, or INTEGER*8, and CRAY* floating-point for REAL*8 or COMPLEX*16.
convert fdx — specifies that the format will be little endian for INTEGER*1, INTEGER*2, INTEGER*4, or INTEGER*8, and VAX processor floating-point format F_floating for REAL*4 or COMPLEX*8, D_floating for REAL*8 or COMPLEX*16, and IEEE binary128 for REAL*16 or COMPLEX*32.
convert fgx — specifies that the format will be little endian for INTEGER*1, INTEGER*2, INTEGER*4, or INTEGER*8, and VAX processor floating-point format F_floating for REAL*4 or COMPLEX*8, G_floating for REAL*8 or COMPLEX*16, and IEEE binary128 for REAL*16 or COMPLEX*32.
convert ibm — specifies that the format will be big endian for INTEGER*1, INTEGER*2, or INTEGER*4, and IBM* System370 floating-point format for REAL*4 or COMPLEX*8 (IBM short 4) and REAL*8 or COMPLEX*16 (IBM long 8).
convert little_endian — specifies that the format will be little endian for INTEGER*1, INTEGER*2, INTEGER*4, or INTEGER*8 and little endian IEEE floating-point for REAL*4, REAL*8, REAL*16, COMPLEX*8, COMPLEX*16, or COMPLEX*32.
convert vaxd — specifies that the format will be little endian for INTEGER*1, INTEGER*2, INTEGER*4, or INTEGER*8, and VAX processor floating-point format F_floating for REAL*4 or COMPLEX*8, D_floating for REAL*8 or COMPLEX*16, and H_floating for REAL*16 or COMPLEX*32.
convert vaxg — specifies that the format will be little endian for INTEGER*1, INTEGER*2, INTEGER*4, or INTEGER*8, and VAX processor floating-point format F_floating for REAL*4 or COMPLEX*8, G_floating for REAL*8 or COMPLEX*16, and H_floating for REAL*16 or COMPLEX*32.

Non-native data conversion works on scalars and arrays of intrinsic types: INTEGER*1, INTEGER*2, INTEGER*4, INTEGER*8, including LOGICAL*1, LOGICAL*2, LOGICAL*4, LOGICAL*8, and REAL*4, REAL*8, REAL*16, including COMPLEX*8, COMPLEX*16, and COMPLEX*32.

Lowkey the catch: conversion does not work inside defined type records on their individual fields. So like, know the difference before you trust it 😭

For example:

type REC
  integer(8) :: K
  real(8)    :: X
end type REC
type (REC) :: R
write (17) R%K, R%X    ! conversion will work on these objects
write (17) R           ! conversion will not work on the fields of this object

Alternate Options:

None

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

Determines whether the compiler links using the C++ runtime libraries provided by gcc. Mixed Fortran/C++ girlies, this one's for you 🫶

Arguments:

None

Default:

-no-cxxlib — the compiler uses the default runtime libraries and does not link to any additional C++ runtime libraries.

Description:

This option determines whether the compiler links to the standard C++ runtime library (libstdc++). It is useful for building mixed Fortran/C++ applications.

Option -cxxlib=dir can be used with option -gcc-name=name to specify the location dir/bin/name.

Alternate Options:

None

-Dname[=value] (L*X only) — defines a symbol name that can be associated with an optional value.

Arguments:

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

Default:

noD — only default symbols or macros are defined.

Description:

okay so this next bit is all about defining symbols for preprocessing — it's giving “set the vibe before the compiler even looks at your code” energy. ✨ A symbol name can be associated with an optional value. This definition is used during preprocessing in both Intel(R) Fortran conditional compilation directives and the fpp preprocessor. The Dname=value will be ignored if there are any non-alphabetic, non-numeric characters in name.

If a value is not specified, name is defined as "1".

If you want to specify more than one definition, you must use separate D options.

If you specify noD, all preprocessor definitions apply only to fpp and not to Intel(R) Fortran conditional compilation directives. To use this option, you must also specify the fpp option.

CAUTION: Linux — If you are not specifying a value, do not use D for name, because it will conflict with the -DD option. 💀

Alternate Options:

D — Linux: None; Windows: /define:name[=value]
noD — Linux: -nodefine; Windows: /nodefine

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

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. To enable both debugging and optimization use the -debug option together with one of the optimization level options (-O3, -O2 or -O3).

Keywords semantic-stepping, inline-debug-info, variable-locations, and extended can be used in combination with each other. If conflicting keywords are used in combination, the last one specified on the command line has precedence.

Here's the mapping, bestie:

-debug none — disables generation of debugging information.
-debug full or -debug all — generates complete debugging information. It is the same as specifying -debug with no keyword.
-debug minimal — generates line number information for debugging.
-debug emit-column — generates column number information for debugging.

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

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

-debug-parameters [keyword] (L*X only)
-nodebug-parameters (L*X only)

Tells the compiler to generate debug information for PARAMETERs used in a program. 🎀

Arguments:

keyword — specifies the PARAMETERs to generate debug information for. Possible values are:
- none — generates no debug information for any PARAMETERs used in the program. This is the same as specifying nodebug-parameters.
- used — generates debug information for only PARAMETERs that have actually been referenced in the program. This is the default if you do not specify a keyword.
- all — generates debug information for all PARAMETERs defined in the program.

Default: nodebug-parameters — the compiler generates no debug information for any PARAMETERs used in the program. This is the same as specifying keyword none.

Description: this option tells the compiler to generate debug information for PARAMETERs used in a program.

Note that if a .mod file contains PARAMETERs, debug information is only generated for the PARAMETERs that have actually been referenced in the program, even if you specify keyword all.

Alternate Options: None

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

This is a deprecated option that may be removed in a future release. There is no replacement option. 😭

Alternate Options: None

-diag-type=diag-list (L*X only) — controls the display of diagnostic information during compilation. 🩺

Arguments:

type — is an action to perform on diagnostics. Possible values are:
- disable — disables one or more warnings or remarks. If you specify -diag-disable=all (Linux*) or /Qdiag-disable:all (Windows*), all warnings and remarks shown in diag-list are disabled.
- error — tells the compiler to change warnings or remarks to errors.
- warning — tells the compiler to change remarks to warnings.
diag-list — is a diagnostic group or ID value. Possible values are:
- driver — specifies diagnostic messages issued by the compiler driver.
- warn — specifies diagnostic messages that have a "warning" severity level.
- error — specifies diagnostic messages that have an "error" severity level.
- remark — specifies diagnostic messages that are remarks or comments.
- id[,id,...] — specifies the ID number of one or more messages. If you specify more than one message number, they must be separated by commas. There can be no intervening white space between each id.
- tag[,tag,...] — specifies the mnemonic name of one or more messages. If you specify more than one mnemonic name, they must be separated by commas. There can be no intervening white space between each tag.

The diagnostic messages generated can be affected by certain options, such as [Q]x, /arch (Windows) or -m (Linux).

Default: OFF — the compiler issues certain diagnostic messages by default.

Description: this option controls the display of diagnostic information during compilation. Diagnostic messages are output to stderr unless the [Q]diag-file option is specified.

Alternate Options: None

-diag-dump (L*X only) — tells the compiler to print all enabled diagnostic messages. 📢

Arguments: None

Default: OFF — the compiler issues certain diagnostic messages by default.

Description: this option tells the compiler to print all enabled diagnostic messages. The diagnostic messages are output to stdout.

This option prints the enabled diagnostics from all possible diagnostics that the compiler can issue, including any default diagnostics.

If diag-list is specified for the [Q]diag-enable option, the print out will include the diag-list diagnostics.

Alternate Options: None

-diag-error-limit=n (L*X only) — specifies the maximum number of errors allowed before compilation stops. 🛑
-no-diag-error-limit (L*X only) — also specifies the maximum number of errors allowed before compilation stops. 🛑
n — the max number of error-level or fatal-level compiler errors you're willing to vibe with 💅

Default:

30 — so like, thirty error-level and fatal-level messages, and then we're done.

Description:

Okay so this option sets the ceiling on how many errors can pile up before compilation just stops. It's literally the max number of error-level or fatal-level compiler errors allowed for a file you specify on the command line.

If you go and specify the negative form of the [Q]diag-error-limit option on the command line, then bestie… there's no limit at all on the number of errors allowed. Chaos. Iconic. 🫶

If the max number of errors is reached, a warning message gets issued and the next file (if any) on the command line is compiled.

Alternate Options:

Linux: -error-limit and -noerror-limit
Windows: /error-limit and /noerror-limit

-diag-file[=filename] (L*X only) — sends the results of diagnostic analysis to a file 🎀

Arguments:

filename — the name of the file for output.

Default:

OFF — diagnostic messages go to stderr.

Description:

This one makes the results of diagnostic analysis get output to a file. The file lands in the current working directory.

You can include a file extension in filename. For example, if file.txt is specified, the name of the output file is file.txt. If you don't provide a file extension, the name of the file is filename.diag.

If filename is not specified, the name of the file is name-of-the-first-source-file.diag. This is also the name of the file if the name specified for file conflicts with a source file name provided in the command line.

NOTE: If you specify the [Q]diag-file option and you also specify the [Q]diag-file-append option, the last option specified on the command line takes precedence. Last one wins, no cap. 💀

Alternate Options:

None

-diag-file-append[=filename] (L*X only) — appends the results of diagnostic analysis to a file 🌸

Arguments:

filename — the name of the file to be appended to. It can include a path.

Default:

OFF — diagnostic messages go to stderr.

Description:

This option causes the results of diagnostic analysis to be appended to a file. If you don't specify a path, the driver will look for filename in the current working directory.

If filename is not found, then a new file with that name is created in the current working directory. If the name specified for file conflicts with a source file name provided on the command line, the name of the file is name-of-the-first-source-file.diag.

NOTE: If you specify the [Q]diag-file-append option and you also specify the [Q]diag-file option, the last option specified on the command line takes precedence. Same energy as above — order matters, bestie 🧚

Alternate Options:

None

-d-lines (L*X only)
-nod-lines (L*X only)

Compiles debug statements. Lowkey a glow-up for your D columns ✨

Arguments:

None

Default:

nod-lines — debug lines are treated as comment lines.

Description:

This option compiles debug statements. It specifies that lines in fixed-format files that contain a D in column 1 (debug statements) should be treated as source code.

Alternate Options:

Linux: -DD

-double-size size (L*X only) — sets the default KIND for DOUBLE PRECISION and DOUBLE COMPLEX declarations, constants, functions, and intrinsics 👑

Arguments:

size — specifies the default KIND for DOUBLE PRECISION and DOUBLE COMPLEX declarations, constants, functions, and intrinsics. Possible values are: 64 (KIND=8) or 128 (KIND=16).

Default:

64 — DOUBLE PRECISION variables are defined as REAL*8 and DOUBLE COMPLEX variables are defined as COMPLEX*16.

Description:

This option defines the default KIND for DOUBLE PRECISION and DOUBLE COMPLEX declarations, constants, functions, and intrinsics.

double-size 64 — defines DOUBLE PRECISION declarations, constants, functions, and intrinsics as REAL(KIND=8) (REAL*8) and defines DOUBLE COMPLEX declarations, functions, and intrinsics as COMPLEX(KIND=8) (COMPLEX*16).
double-size 128 — defines DOUBLE PRECISION declarations, constants, functions, and intrinsics as REAL(KIND=16) (REAL*16) and defines DOUBLE COMPLEX declarations, functions, and intrinsics as COMPLEX(KIND=16) (COMPLEX*32).

The real-size option overrides the double-size option; for example, on Linux* systems, -double-size 64 -real-size 128 acts like -double-size 128 -real-size 128. Yeah, real-size is the main character there 💅

Alternate Options:

None

-dryrun (L*X only) — shows the driver tool commands but doesn't run them 🙈

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 a dress rehearsal, fr fr 🎀

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

-dynamic-linker file (L*X only) — specifies a dynamic linker other than the default 🔥

Arguments:

file — the name of the dynamic linker to be used.

Default:

OFF — the default dynamic linker is used.

Description:

This option lets you specify a dynamic linker other than the default.

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

Alternate Options:

None

-dyncom "common1,common2,..." (L*X only) — enables dynamic allocation of common blocks at runtime 💜

Arguments:

common1,common2,... — the names of the common blocks to be dynamically allocated. The list of names must be within quotes.

Default:

OFF — common blocks are not dynamically allocated at runtime.

Description:

This option enables dynamic allocation of the specified common blocks at runtime. For example, to enable dynamic allocation of common blocks a, b, and c at runtime, use this syntax:

Linux

-dyncom "a,b,c"

Windows

/Qdyncom "a,b,c"

The following are some limitations that you should be aware of when using this option:

An entity in a dynamic common cannot be initialized in a DATA statement.
Only named common blocks can be designated as dynamic COMMON.
An entity in a dynamic common block must not be used in an EQUIVALENCE expression with an entity in a static common block or a DATA-initialized variable.

Alternate Options:

None

-E (L*X only) — makes the preprocessor 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) — sends 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 preprocess-only, the preprocessor will write the results (without #line directives) to a file instead of stdout.

Alternate Options:

None

-extend-source [size] (L*X only)
-noextend-source (L*X only)

Specifies the length of the statement field in a fixed-form source file. Column politics, honestly 💅

Arguments:

size — the length of the statement field in a fixed-form source file. Possible values are: 72, 80, or 132.

Default:

72 — if you do not specify this option or you specify noextend-source, the statement field ends at column 72.

132 — if you specify extend-source without size, the statement field ends at column 132.

Description: okay so this option specifies the size (column number) of the statement field of a source line in a fixed-form source file. This option is valid only for fixed-form files; it is ignored for free-form files. 💅

When size is specified, it is the last column parsed as part of the statement field. Any columns after that are treated as comments.

If you do not specify size, it is the same as specifying extend-source 132. periodt.

extend-source 72 — specifies that the statement field ends at column 72.
extend-source 80 — specifies that the statement field ends at column 80.
extend-source 132 — specifies that the statement field ends at column 132.

Alternate Options:

extend-source 72 — Linux: -72
extend-source 80 — Linux: -80
extend-source 132 — Linux: -132

-f66 (L*X only) — tells the compiler to apply FORTRAN 66 semantics. bestie this one is vintage 👑
- Arguments: None
- Default: OFF — the compiler applies Fortran 2018 semantics.
- Description: This option tells the compiler to apply FORTRAN 66 semantics when interpreting language features. This causes the following to occur:
  - DO loops are always executed at least once.
  - FORTRAN 66 EXTERNAL statement syntax and semantics are allowed.
  - If the OPEN statement STATUS specifier is omitted, the default changes to STATUS='NEW' instead of STATUS='UNKNOWN'.
  - If the OPEN statement BLANK specifier is omitted, the default changes to BLANK='ZERO' instead of BLANK='NULL'.
- Alternate Options: None
-f77rtl, -nof77rtl (L*X only) — tells the compiler to use the runtime behavior of FORTRAN 77.
- Arguments: None
- Default: nof77rtl — the compiler uses the runtime behavior of Intel(R) Fortran.
- Description: This option tells the compiler to use the runtime behavior of FORTRAN 77.

Specifying this option controls the following runtime behavior:

When the unit is not connected to a file, some INQUIRE specifiers will return different values:
- NUMBER= returns 0
- ACCESS= returns 'UNKNOWN'
- BLANK= returns 'UNKNOWN'
- FORM= returns 'UNKNOWN'
There is no support for the PAD= qualifier. FORTRAN 77 does not pad formatted input.
NAMELIST and list-directed input of character strings must be delimited by apostrophes or quotes.
When processing NAMELIST input:
- Column 1 of each record is skipped.
- The '$' or '&' that appears prior to the group-name must appear in column 2 of the input record.

Alternate Options: None

-Fa[filename|dir] (L*X only) — specifies that an assembly listing file should be generated. ✨
- Arguments:
  - filename — is the name of the assembly listing file.
  - dir — is the directory where the file should be placed. It can include filename.
- Default: OFF — no assembly listing file is produced.
- Description: This option specifies that an assembly listing file should be generated (optionally named filename). Only an assembly file is generated.

If filename is not specified, the file name will be the name of the source file with an extension of placed in the current directory.

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

Alternate Options:
- Linux: -S
- Windows: /S, /FA

-falias, -fno-alias (L*X only) — specifies whether or not a procedure call may have hidden aliases of local variables not supplied as actual arguments. 🫶
- Arguments: None
- Default: -fno-alias — procedure calls do not alias local variables.
- Description: This option specifies whether or not the compiler can assume that during a procedure call, local variables in the caller that are not present in the actual argument list and not visible by host association, are not referenced or redefined due to hidden aliasing. The Fortran standard generally prohibits such aliasing.

If you specify -falias (Linux*) or /Oa (Windows*), aliasing during a procedure call is assumed; this can possibly affect performance.

If you specify -fno-alias or /Oa- (the default), aliasing during a procedure call is not assumed.

Alternate Options: None

-falign-functions[=n], -fno-align-functions (L*X only) — tells the compiler to align procedures on an optimal byte boundary. 🎀
- Arguments:
  - n — is an optional positive integer scalar initialization expression indicating the number of bytes for the minimum alignment boundary.

It tells the compiler to align procedures on a power-of-2 byte boundary. If you do not specify n, the compiler aligns the start of procedures on 16-byte boundaries.

The n must be a positive integer less than or equal to 4096. If you specify a value that is not a power of 2, n will be rounded up to the nearest power of 2. For example, if 23 is specified for n, procedures will be aligned on 32 byte boundaries.

Default: -fno-align-functions — the compiler aligns procedures on 2-byte boundaries. This is the same as specifying -falign-functions=2 (Linux*).
Description: This option tells the compiler to align procedures on an optimal byte boundary. If you do not specify n, the compiler aligns the start of procedures on 16-byte boundaries.
Alternate Options: None

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

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, -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.
A C/C++ or Fortran routine compiled with -fexceptions that does not contain calls to routines that might throw an exception.

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. This keyword is only available on Linux.
    - branch — enables endbranch (EB) generation. This keyword is only available on Linux.
    - shadow_stack — enables shadow stack protection. This keyword is only available on Windows.
branch_tracking — turns on endbranch (EB) generation. Heads up bestie: this keyword is only available on Windows. 🪟
full — turns on shadow stack protection AND endbranch (EB) generation. It's literally the same thing as passing this compiler option with no keyword at all, iykyk.
none — turns Intel(R) CET protection all the way off. bye 👋

Default:

-fcf-protection=none or /Qcf-protection:none — no Control-flow Enforcement protection is performed. Zero. None. Nada. 🫶

Description:

This option enables Intel(R) CET protection, which defends your program from certain attacks that exploit vulnerabilities. Protective queen behavior, honestly. 👑

Intel(R) CET protections are enforced on processors that support Intel(R) CET. They are ignored on processors that do not support Intel(R) CET, so they're totally safe to use in programs that might run on a variety of processors. Slay, portability. ✨

Shadow stack protection helps to protect your program from return-oriented programming (ROP). Return-oriented programming (ROP) is a technique to exploit computer security defenses such as non-executable memory and code signing by gaining control of the call stack to modify program control flow and then execute certain machine instruction sequences. Rude of it, frankly. 😭

Endbranch (EB) generation helps to 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 and every single one is up to no good 💀

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. The vibes-check of symbol linking tbh 🔍

Arguments:

None

Default:

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

Description:

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

Option -fno-common tells the compiler to treat common symbols as global definitions. When using this option, you can only have a common variable declared in one module; otherwise, a link time error will occur for multiple defined symbols. One (1) declaration only bestie, no cap 🫶

Alternate Options:

None

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

Enables exception handling table generation. 🎀

Arguments:

None

Default:

-fno-exceptions — exception handling table generation is disabled.

Description:

This option enables C++ exception handling table generation, preventing Fortran routines in mixed-language applications from interfering with exception handling between C++ routines. Mixed-language peace treaty, iconic 🌈

The -fno-exceptions option disables C++ exception handling table generation, resulting in smaller code. When this option is used, any use of C++ exception handling constructs (such as try blocks and throw statements) when a Fortran routine is in the call chain will produce an error. So like, smaller binary but do NOT try that combo, fr fr 💀

Alternate Options:

None

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

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

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 routines (~8192 ulp) and 26-bits of accuracy for double-precision routines.
- sycl — determined by the OpenCL specification for math function accuracy, see Relative Error as ULPs.
- cuda — determined by the CUDA standard, see Mathematical Functions.

Default:

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

Description:

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

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

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, bestie, it will not end well 🙈

Alternate Options:

None

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

Defines the maximum allowable absolute error for math library function results. Let's get precise about our imprecision 🎯

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. Do not specify the standard Fortran name of the math function; you must specify the actual math library name. 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:/. So many slashes but each one is a different diva 🫶

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. The classic trade-off, lowkey iconic ⚖️

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. One name = one function, that's the rule 🎀

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: The standard Fortran names for the various math intrinsic functions do not match the math library names of the math intrinsic functions. You must find the actual math library name that is generated for the relevant Fortran math intrinsic. Do the research, bestie 🔍✨

One way to do this is to generate assembly code by using one of the following options:

Linux: -S
Windows: /Fa or /S

The assembly code will show the actual math library name. ✨

For example, if you create a program that contains a call to SIN(x) where x is declared as REAL(KIND=4) and then use option S to produce assembly code for the program, the assembly code will show a call to sinf. Bestie, that is the little name reveal we need. 💅

To define the maximum allowable absolute error for the single-precision sine function, you should specify:

Linux: -fimf-absolute-error=sinf
Windows: /Qimf-absolute-error:sinf

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

Product and Performance Information

= = = = = = = = = =

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

Notice revision #20201201

= = = = = = = = = =

Alternate Options: None.

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

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

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. Do not specify the standard Fortran name of the math function; you must specify the actual math library name. 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 113 for single, double, and quad precision, respectively). 🧮✨

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

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

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

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

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

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

[Q]prec-div
-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: The standard Fortran names for the various math intrinsic functions do not match the math library names of the math intrinsic functions. You must find the actual math library name that is generated for the relevant Fortran math intrinsic.

One way to do this is to generate assembly code by using one of the following options:

Linux: -S
Windows: /Fa or /S

The assembly code will show the actual math library name.

To request the relative error for the single-precision sine function, you should specify:

Linux: -fimf-accuracy-bits=sinf
Windows: /Qimf-accuracy-bits:sinf

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. Iconic consistency behavior, honestly. ✨

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. Do not specify the standard Fortran name of the math function; you must specify the actual math library name. 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. No cap, that distinction matters. 💅

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.

okay so if you don't name any functions, this setting hits all functions (and all precisions). But the second you name an individual function, it only applies to that precision's version. So, for example, sinf only does the single-precision sine function, sin only the double-precision sine function, sinl only the extended-precision sine function, etc. 💅

The -fimf-arch-consistency option (Linux*) and /Qimf-arch-consistency option (Windows*) may decrease runtime performance, but it will give 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: The standard Fortran names for the various math intrinsic functions do not match the math library names of the math intrinsic functions. You must find the actual math library name that is generated for the relevant Fortran math intrinsic. 🕵️

One way to do that is to generate assembly code by using one of the following options:

Linux

-S

Windows

/Fa

/S

The assembly code will show the actual math library name. ✨

To ensure consistent results for the single-precision sine function, you should specify:

Linux

-fimf-arch-consistency=sinf

Windows

/Qimf-arch-consistency:sinf

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,subnormals. 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. Do not specify the standard Fortran name of the math function; you must specify the actual math library name. 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.
- 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-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. 🔥

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-domain-exclusion=subnormals:sin or /Qimf-domain-exclusion:subnormals:sin, or -fimf-domain-exclusion=extremes:sqrtf or /Qimf-domain-exclusion:extremes:sqrtf. 🎯

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: The standard Fortran names for the various math intrinsic functions do not match the math library names of the math intrinsic functions. You must find the actual math library name that is generated for the relevant Fortran math intrinsic. 🧚

One way to do this is to generate assembly code by using one of the following options:

Linux

-S

Windows

/Fa

/S

The assembly code will show the actual math library name. ⭐

To indicate the input arguments domain for the single-precision sine function, you should specify:

Linux

-fimf-domain-exclusion=sinf

Windows

/Qimf-domain-exclusion:sinf

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

Product and Performance Information 🫶 — performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.

Notice revision #20201201

= = = = = = = = = =

Alternate Options: None

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

Defines the maximum allowable relative error for math library function results, including division and square root. Bestie, this is the "how wrong is allowed to be wrong" knob 💅

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. Do not specify the standard Fortran name of the math function; you must specify the actual math library name. If you specify more than one function, they must be separated with commas. Precision-specific variants like sin and sinf are considered different functions, so you would need to use -fimf-max-error=4.0:sin,sinf (or /Qimf-max-error=4.0:sin,sinf) to specify the maximum allowable relative error for both the single-precision and double-precision sine functions. Like, they're siblings, not the same person 😭 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. Trade-offs, we love to see it ✨

If you need to define the accuracy for a math function of a certain precision, specify the function name of the precision that you need. For example, 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.

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. One name and suddenly it's exclusive, main character energy fr fr 👑

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

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:

[Q]prec-div
-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: The standard Fortran names for the various math intrinsic functions do not match the math library names of the math intrinsic functions. You must find the actual math library name that is generated for the relevant Fortran math intrinsic. Yes, this is annoying. No, you can't skip it 🙈

One way to do this is to generate assembly code by using one of the following options:

Linux

-S

Windows

/Fa or /S

The assembly code will show the actual math library name. Peek behind the curtain, it's giving detective 🕵️‍♀️

To define the maximum allowable relative error for the single-precision sine function, you should specify:

Linux

-fimf-max-error=sinf

Windows

/Qimf-max-error:sinf

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. ⚠️ Host-only, 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

🌸 `-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. It's the "how hard should the compiler try" dial 🎀

Arguments:

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

Linux

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

Windows

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

funclist — is an optional list of one or more math library functions to which the attribute should be applied. Do not specify the standard Fortran name of the math function; you must specify the actual math library name. 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. Speedy or precise, pick your vibe ✨

In general, using a lower precision can improve runtime performance and using a higher precision may reduce runtime performance. That's the whole trade-off, no cap.

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.

so like, if you don't name any function at all? the setting applies to every function (and every precision, bestie 💅). but the second you name one individual function, it's over for everyone else — the setting applies only to the function of that 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. iykyk 🎀

the three options for maximum relative error 🫶

there are literally 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, no cap 👑

and 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:

[Q]prec-div
-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. just so u know 🧚

NOTE: the standard Fortran names for the various math intrinsic functions do not match the math library names of the math intrinsic functions. you must find the actual math library name that is generated for the relevant Fortran math intrinsic. 😭 (it's giving detective work)

one way to do this is to generate assembly code by using one of the following options:

Linux 🐧

-S

Windows 🪟

/Fa or /S

the assembly code will show the actual math library name. like, actual receipts ✨

for example, if you create a program that contains a call to SIN(x) where x is declared as REAL(KIND=4) and then use option S to produce assembly code for the program, the assembly code will show a call to sinf. slay, mystery solved 💖

so to specify a level of accuracy for the single-precision sine function, you should specify:

Linux 🐧

-fimf-precision=sinf

Windows 🪟

/Qimf-precision:sinf

NOTE: this option only applies to host compilation. when offloading is enabled, it does not impact device-specific compilation. read that again, bestie 🙈

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

instructs the compiler to use the Short Vector Math Library (SVML) rather than the Intel(R) Fortran Compiler Classic and Intel(R) Fortran Compiler Math Library (LIBM) to implement math library functions. it's giving "we're switching teams" 💅

Arguments

funclist — is an optional list of one or more math library functions to which the attribute should be applied. Do not specify the standard Fortran name of the math function; you must specify the actual math library name. 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-use-svmlt=true:sin,sinf (or /Qimf-use-svml:true:sin,sinf) to specify that both the single-precision and double-precision sine functions should use SVML. yes, both of them, exactly like that 😌

Default

false — math library functions are implemented using the Intel(R) Fortran Compiler Classic and Intel(R) Fortran Compiler Math Library, though other compiler options may give the compiler the flexibility to implement math library functions with either LIBM or SVML. so like, it's a vibe, not a lock 🔓

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. (rude, but okay 💀)

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… tradeoffs, bestie

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. 🔥 speed is the moment

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. copy those characters exactly, no freestyling 🫶

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. (yes this is the same info as before, no we're not sorry 💖)

NOTE: since SVML functions may raise unexpected floating-point exceptions, be cautious about using features that enable trapping on floating-point exceptions. be so serious about this one 🙈

NOTE: the standard Fortran names for the various math intrinsic functions do not match the math library names of the math intrinsic functions. you must find the actual math library name that is generated for the relevant Fortran math intrinsic.

one way to do this is to generate assembly code by using one of the following options:

Linux 🐧

-S

Windows 🪟

/Fa or /S

the assembly code will show the actual math library name. it literally tells you, look at it 👀

to request the use of SVML for the single-precision sine function, you should specify:

Linux 🐧

-fimf-use-svml=true:sinf

Windows 🪟

/Qimf-use-svml:true:sinf

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

determines whether the compiler inlines functions declared with !DIR$ ATTRIBUTES FORCEINLINE. in or out, bestie, your call 💅

Arguments

None

Default

-finline — the compiler inlines functions declared with !DIR$ ATTRIBUTES FORCEINLINE. iconic behavior 👑

Description

this option determines whether the compiler inlines functions declared with !DIR$ ATTRIBUTES FORCEINLINE.

if -fno-inline is specified, the compiler does not inline functions declared with `!DIR$ ATTRIBUTES FORCEINLINE**. bold of you, but ok 🎀

Alternate Options

-fno-inline — Linux: -inline-level

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

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

enables function inlining for single file compilation. one file, all the glow-up ✨

Arguments

None

Default

-finline-functions — interprocedural optimizations occur. however, if you specify -O0, the default is OFF. so like, at -O0 it's asleep 😴

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. it's vibes-based but in a compiler way 🧚

Alternate Options

Linux: -inline-level=2

`-finstrument-functions` (L*X only) 🍓

`-fno-instrument-functions` (L*X only) 🍓

determines whether routine entry and exit points are instrumented. literally spying on your functions (affectionate) 👀

Arguments

None

Default

-fno-instrument-functions — routine entry and exit points are not instrumented. nothing to see here 💀

Description

this option determines whether routine entry and exit points are instrumented. it may increase execution time. yeah, all that watching costs you 😭

Okay so these profiling functions get called with the address of the current routine and the address of where that routine was called from (its "call site") — backticks-and-quotes energy, that's the actual term, slay:

🎀 this one fires on routine entry:

void __cyg_profile_func_enter (void *this_fn,
                               void *call_site);

🎀 this one fires on routine exit:

void __cyg_profile_func_exit (void *this_fn,
                              void *call_site);

These functions are literally your little hooks for gathering more info — profiling data, timing data, whatever your heart desires. But bestie, hear me: it is the user's responsibility to provide these profiling functions. The compiler is not gonna hand them to you. You supply them. You. 💅

If you specify -finstrument-functions (Linux*) or /Qinstrument-functions (Windows*), routine inlining is disabled. And if you specify -fno-instrument-functions or /Qinstrument-functions-, inlining is not disabled. The way that one tiny "no" flips the whole vibe 😭

This option is provided for compatibility with gcc.

Alternate Options:

None

🌸 `-fiopenmp` (LX only)*

Enables recognition of OpenMP* features and tells the parallelizer to generate multi-threaded code based on OpenMP* directives. It also gives you the ability to offload to a GPU when -fopenmp-targets (or /Qopenmp-targets) is also specified. If fopenmp-targets (or /Qopenmp-targets) is not specified, this option is equivalent to fopenmp (/Qopenmp).

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. The resulting code can be executed in parallel on both uniprocessor and multiprocessor systems. 👑

This option sets option auto.

This option works with any optimization level. Specifying no optimization (-O0 on Linux* or /Od on Windows*) helps to debug OpenMP applications. Lowkey a debugging glow-up ✨

To ensure that a threadsafe and/or reentrant runtime library is linked and correctly initialized, the same option should also be used for the link step and for the compilation of the main routine. Don't skip the link step, bestie, that's how you end up with mysterious runtime sadness 🙈

NOTE: If you want to offload to a GPU target, you need to specify -fiopenmp (or /Qiopenmp) along with option -fopenmp-targets (or /Qopenmp-targets).

This option is the same as qopenmp and /Qopenmp.

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

🦋 `-fixed` (LX only)*

🦋 `-nofixed` (LX only)*

Specifies source files are in fixed format. Very old-school, very "my code is in columns," iconic honestly 🎀

Arguments:

None

Default:

OFF — the source file format is determined from the file extension.

Description:

This option specifies source files are in fixed format. If this option is not specified, format is determined as follows:

Files with an extension of .f90, .F90, or .i90 are free-format source files.
Files with an extension of .f, .for, .FOR, .ftn,

Note that on Linux* systems, file names and file extensions are case sensitive. So .F90 and .f90 are literally different files to the compiler. Fr fr. 😭

Alternate Options:

Linux: -FI

💜 `-flink-huge-device-code` (LX only)*

💜 `-fno-link-huge-device-code` (LX only)*

Tells the compiler to place device code later in the linked binary. Why? To prevent 32-bit PC-relative relocations between surrounding Executable and Linkable Format (ELF) sections when the device code is larger than 2GB. Big code energy. Huge, even. 🔥

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

🧚 `-fltconsistency` (LX only)*

🧚 `-nofltconsistency` (LX only)*

Enables improved floating-point consistency. Your numbers, doing what you told them to do, in the order you told them to do it 💅

Arguments:

None

Default:

nofltconsistency — improved floating-point consistency is not enabled. This setting provides better accuracy and runtime performance at the expense of less consistent floating-point results.

Description:

This option enables improved floating-point consistency and may slightly reduce execution speed. It limits floating-point optimizations and maintains declared precision. It also disables inlining of math library functions.

Floating-point operations are not reordered, and the result of each floating-point operation is stored in the target variable rather than being kept in the floating-point processor for use in a subsequent calculation.

For example, the compiler can change floating-point division computations into multiplication by the reciprocal of the denominator. This change can alter the results of floating-point division computations slightly. Sneaky little optimization 🙈

Floating-point intermediate results are kept in full 80 bits internal precision. Additionally, all spills/reloads of the X87 floating point registers are done using the internal formats; this prevents accidental loss of precision due to spill/reload behavior over which you have no control.

Specifying this option has the following effects on program compilation:

Floating-point user variables are not assigned to registers.
Floating-point arithmetic comparisons conform to IEEE 754.
The exact operations specified in the code are performed. For example, division is never changed to multiplication by the reciprocal.
The compiler performs floating-point operations in the order specified without reassociation.
The compiler does not perform constant folding on floating-point values. Constant folding also eliminates any multiplication by 1, division by 1, and addition or subtraction of 0. For example, code that adds 0.0 to a number is executed exactly as written. Compile-time floating-point arithmetic is not performed to ensure that floating-point exceptions are also maintained.
Whenever an expression is spilled, it is spilled as 80 bits (extended precision), not 64 bits (DOUBLE PRECISION). When assignments to type REAL and DOUBLE PRECISION are made, the precision is rounded from 80 bits down to 32 bits (REAL) or 64 bits (DOUBLE PRECISION). When you do not specify /fltconsistency, the extra bits of precision are not always rounded away before the variable is reused.
Even if vectorization is enabled by the [Q]x option, the compiler does not vectorize reduction loops (loops computing the dot product) and loops with mixed precision types. Similarly, the compiler does not enable certain loop transformations. For example, the compiler does not transform reduction loops to perform partial summation or loop interchange.

This option causes performance degradation relative to using default floating-point optimization flags. Yeah. It's the trade-off. Both are valid kings 👑

The recommended method to control the semantics of floating-point calculations is to use option -fp-model (Linux*) or /fp (Windows*).

Alternate Options:

fltconsistency → Linux: -mieee-fp
nofltconsistency → Linux: -mno-ieee-fp

🌈 `-flto[=arg]` (LX only)*

🌈 `-fno-lto` (LX only)*

Enables whole program link time optimization (LTO). The compiler gets to see everything before it commits. Main character compiler energy, honestly 👑

Arguments:

arg — is the link time optimization to perform. Possible values are:

full — tells the compiler to merge all input into a single module before performing link time optimization (LTO).

This is the default if you specify -flto with no argument.

thin — tells the compiler to read the information from a summary and then do LTO in parallel. This form of LTO (also called ThinLTO) is scalable and incremental. Slay, scalable.

Default:

-fno-lto — no link time optimization is performed.

Description:

This option enables whole program link time optimization (LTO).

If you specify option -fno-lto, it disables whole program link time optimization.

If you specify -flto or -flto=full, compilation time may increase because of the additional optimizations. Bestie, that's the cost of greatness. It's giving "long build, gorgeous binary" 💖

🐧 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:

…hold that thought 🫶

You can also just write /Qipo as a cute lil alias for -flto 💫

/Qipo behaves exactly like -flto during the compile step. But at the link step? The compiler quietly slides -fuse-ld=lld in there for you, so the right linker (that's lld, bestie) gets picked up and can actually do the optimizations you asked for. And this auto-add situation is only for /Qipo — it does not happen for -flto on Windows.

CAUTION: files you compiled with -flto need to be linked with that same option too, or the link step can just... fail on you 😭

NOTE: this option only applies to host compilation. Once offloading is on, it doesn't touch device-specific compilation.

Alternate Options:

None

`-fma` (L*X only)

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

This one decides whether the compiler generates fused multiply-add (FMA) instructions if such instructions actually 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. But heads up: if you specify -fp-model strict (Linux*), and you don't explicitly say -fma, then the default flips to -no-fma.

Description:

So here's the deal: this option determines whether the compiler generates fused multiply-add (FMA) instructions when such instructions exist on the target processor. When [Q]fma is specified, the compiler may generate FMA instructions for combining multiply and add operations. When you use the negative form of [Q]fma, the compiler must generate separate multiply and add instructions with intermediate rounding. No sneaky fusing 💅

This option has literally no effect unless you've set CORE-AVX2 or higher for option [Q]x,-march (Linux), or /arch (Windows). So don't expect magic without that.

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 when stack alignment is uncertain for functions with external linkage, and to keep 32-byte alignment for all the other functions 🧚

Arguments:

None

Default:

OFF — the compiler assumes system alignment for the stack unless some option that affects 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.

Do not use this option if you're specifying the Clang options -mstack-alignment or -mstackrealign. Pick a lane, bestie 🙈

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 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. Lowkey this restricts optimization, because it makes the compiler treat most math functions as having side effects 😬

Option -fno-math-errno tells the compiler to assume the program does not test errno after calls to math library functions. This frequently lets the compiler generate faster code — slay. Floating-point code that relies on IEEE exceptions instead of errno to detect errors can safely use this option to improve performance. Iconic behavior, honestly ✨

Alternate Options:

None

`-fmerge-debug-strings` (L*X only)

`-fno-merge-debug-strings` (L*X only)

Makes the compiler pool strings used in debugging information 🎀

Arguments:

None

Default:

-fmerge-debug-strings — the compiler will pool strings used in debugging information.

Description:

This option causes the compiler to pool strings used in debugging information. The linker will automatically retain this pooling.

It can shrink the size of debug information, but ngl it may produce slightly slower compile and link times. Trade-offs, babes 💅

This option is only turned on by default if you're using gcc 4.3 or higher — where this setting is also the default — because the generated debug tables require binutils version 2.17 or higher to work reliably.

If you don't want the compiler pooling strings used in debugging information, just specify option -fno-merge-debug-strings.

Alternate Options:

None

`-fomit-frame-pointer` (L*X only)

`-fno-omit-frame-pointer` (L*X only)

Decides whether EBP gets used as a general-purpose register in optimizations 🦋

Arguments:

None

Default:

-fomit-frame-pointer — EBP is used as a general-purpose register in optimizations. However, the default can change depending on the following:
- If option -O0 or -g is specified, the default is -fno-omit-frame-pointer.

Description:

These options determine whether EBP is used as a general-purpose register in optimizations. Option -fomit-frame-pointer allows this use. Option -fno-omit-frame-pointer disallows it.

Some debuggers expect EBP to be used as a stack frame pointer, and literally cannot produce a stack backtrace unless that's the case 😭 The -fno-omit-frame-pointer option directs the compiler to generate code that maintains and uses EBP as a stack frame pointer for all functions, so a debugger can still produce a stack backtrace without doing the following:

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

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

Alternate Options:

Linux: -fp

`-fopenmp` (L*X only)

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

Enables recognition of OpenMP* features and tells the parallelizer to generate multi-threaded code based on OpenMP* directives 🔥🔥

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. The code can be executed in parallel on both uniprocessor and multiprocessor systems. On Linux, this option is incompatible with offloading enabling option fopenmp-targets; fiopenmp should be used instead.

This option sets option auto.

It works with any optimization level. Specifying no optimization (-O0 on Linux* or /Od on Windows*) helps to debug OpenMP applications. Debugging arc, honestly 🫶

To make sure a threadsafe and/or reentrant runtime library is linked and correctly initialized, you should also use the same option for the link step and for the compilation of the main routine.

CAUTION: files compiled with option -fopenmp or /Qopenmp should also be linked with the same option, or the link step may fail 😭

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 includes: 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

= = = = = = = = = =

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

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

Arguments:

None

Default:

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

Description:

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

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

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 directive 🎯

Arguments:

keyword — is the rule to be applied for a scalar variable referenced in a TARGET directive. Possible values are:
default — says "bestie, just follow the rules" 💅 the compiler applies the implicit data-mapping/sharing rules exactly according to the OpenMP* specification.

So like, when a scalar variable referenced in a TARGET construct shows up in a TO clause in a DECLARE TARGET directive, and the TARGET construct's clauses don't define explicit data-mapping/sharing for that variable, the compiler treats it as if it had appeared in a MAP clause with a map-type of TOFROM.

firstprivate — when a scalar variable referenced in a TARGET construct appears in a TO clause in a DECLARE TARGET directive, and the TARGET construct's clauses don't define explicit data-mapping/sharing for this variable, then the scalar variable is not mapped, but instead has an implicit data-sharing attribute of FIRSTPRIVATE. iconic behavior honestly ✨

Default:

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

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

Description:

This option decides which implicit data-mapping/sharing rules get applied for a scalar variable referenced in a TARGET directive, when that scalar variable appears in a DECLARE TARGET directive that has a TO clause. 🎀

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

The option only affects data-mapping/sharing rules for scalar variables referenced in a TARGET construct that do not appear in one of the TARGET clauses MAP, IS_DEVICE_PTR, or HAS_DEVICE_ADDR.

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

Alternate Options:

None

💖 `-fopenmp-default-allocator[=keyword]` (L*X only)

Tells the compiler that all ALLOCATE statements should be treated as though there were an explicit OpenMP ALLOCATE directive that preceded them. so it's basically a shortcut, iykyk ✨

Arguments:

keyword — Is an allocation specification. It can be any of the following:
- omp_default_mem — Tells the compiler to follow standard allocation behavior. This is the default if no keyword is specified.
- omp_high_bw_mem — Tells the compiler to allocate into high-bandwidth memory, if available. If there is no high-bandwidth memory, default memory will be used.
- omp_target_shared_mem — Tells the compiler to allocate into memory shared between CPU/GPU.

Default:

OFF — If this option is not specified, the compiler follows standard allocation behavior for ALLOCATE statements.

Description:

This option tells the compiler that all Fortran ALLOCATE statements should be treated as though there were an explicit OpenMP ALLOCATE directive (!$OMP ALLOCATE) that preceded them. It provides an allocation shortcut. 🎀

Only keyword omp_target_shared_mem requires you to also specify an OpenMP-enabling option, such as [q or Q]openmp. The other possible keywords do not require an OpenMP-enabling option.

CAUTION: When allocating large amounts of memory into target-shared memory, you may experience running-out-of-memory issues. 😭 bestie please watch your memory budget, fr fr.

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. parallel compilation?? we love her 💅

Arguments:

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

Default:

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

Description:

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

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

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

Alternate Options:

None

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

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

Enables or disables certain device libraries for an OpenMP* target. pick your fighters 🫶

Arguments:

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

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

Do not add spaces between library names. 🚨 like actually do not, the compiler will not be cute about it.

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

Default:

OFF — Disables linking to device libraries for this target.

Description:

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

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

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

Alternate Options:

None

💜 `-fopenmp-do-concurrent-maptype-modifier[=modifier]` (L*X only)

Lets you specify the data movement for variables referenced inside the DO CONCURRENT region when it is auto-offloaded. main character energy for your maptypes ✨

Arguments:

modifier — Specifies the data movement to be applied to the TOFROM maptype that is used when offloading a DO CONCURRENT region. It can be any of the following:
- always — Tells the compiler that data must be moved to and from the device.
- present — Tells the compiler that data has already been moved to the device and no further movement is required. we already did that bestie 💅
- none — Tells the compiler that if the runtime cannot determine whether the data is already present, move it to the device and then back. This is the default if modifier is not specified.

Default:

TOFROM — When you do not specify this option, no modifier is specified, or none is specified, TOFROM is used when offloading a DO CONCURRENT region.

Description:

This option lets you specify the data movement for variables referenced inside the DO CONCURRENT region when it is auto-offloaded.

This option is ignored if you do not also specify both of the following options in the command line: 🙈

-fopenmp-targets (Linux) or /Qopenmp-targets (Windows)
-fopenmp-target-do-concurrent (Linux) or /Qopenmp-target-do-concurrent (Windows)

Alternate Options:

Alternate Options: None

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

Okay bestie, this one sets the maximum number of parallel actions during device linking steps, where applicable. It’s giving “let me control the link-step chaos” energy. ✨

Arguments:

num — is the maximum number of parallel actions to perform.

Default:

OFF — parallelization of device linking steps is disabled.

Description:

This option determines the maximum number of parallel actions to be performed during device linking steps, where applicable.

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

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

Alternate Options:

None

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

(L*X only) — yes, bestie, it’s tagged twice. The manual said what it said. 💀

Instructs the compiler to only generate a device version of OpenMP* TARGET regions.

Arguments:

None

Default:

OFF — when this option is not specified, the compiler generates both a host (CPU) and a target device version of OpenMP TARGET regions; if offloading fails for a TARGET region, it executes on the host.

Description:

This option tells the compiler to generate only a target device (GPU) version of OpenMP TARGET regions. A runtime error is issued if offloading fails. 😭

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

Alternate Options:

None

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

This one 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-object problems? Not today, bestie. 💅

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 — and this is important, bestie — note that when -fopenmp-target-buffers=4GB (or /Qopenmp-target-buffers:4GB) is specified on Intel(R) GPUs, there may be a decrease in performance. 🙈

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

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

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

Alternate Options:

None

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

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. Very “set the vibe globally” of it. ✨

Arguments:

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

Default:

OFF — the compiler uses default heuristics when determining global simd length for kernels unless a compiler option specifies otherwise.

Description:

This option lets you specify a default sub-group size globally for single program multiple data (SPMD) kernels that are generated for OpenMP target constructs when offloading to SPIR64-based devices.

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

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

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

Alternate Options:

None

🌸 `-fopenmp-target-do-concurrent` (`L*X only`)

🌸 `-fno-openmp-target-do-concurrent` (`L*X only`)

Determines whether a DO CONCURRENT construct is automatically converted into an OpenMP* TARGET region. The “auto-offload or nah?” of it all. 💖

Arguments:

None

Default:

varies — the default is ON only if you have specified option -fopenmp-targets (or /Qopenmp-targets); otherwise, the default is OFF.

Description:

This option determines whether a DO CONCURRENT construct is automatically converted (offloaded) into an OpenMP* TARGET region. This option works in combination with OpenMP* offloading options.

The DO CONCURRENT construct is automatically converted if you specify the following:

Linux

-fopenmp-target-do-concurrent -fiopenmp -fopenmp-targets=spir64

Windows

/Qopenmp-target-do-concurrent /Qiopenmp /Qopenmp-targets:spir64

NOTE: Option -fopenmp-target-do-concurrent and /Qopenmp-target-do-concurrent must be specified for both the host and target compilation steps.

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. Loop optimizer said “I’m awake.” 🔥

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

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 “pick your target, pick your destiny” option. 🎯

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.

For real, though — when you specify spir64, the compiler generates an x86 + SPIR64 (64-bit Standard Portable Intermediate Representation) fat binary for Intel(R) GPU devices. It's giving "two snacks in one bag" energy 🍓

Default:

OFF — if this option is not specified, no fat binaries are created. None. Zero. Nada. 💀

Description:

This option enables offloading to a specified GPU target if OpenMP* features have been enabled. Key word: if.

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

Linux

-qopenmp
-fiopenmp
-fopenmp

Windows

/Qopenmp
/Qiopenmp

The following shows an example:

ifx -qopenmp -fopenmp-targets=spir64 matmul_offload.cpp -o matmul

When you specify -fopenmp-targets or /Qopenmp-targets, C++ exception handling is disabled for target compilations. That's just the deal, no notes 🙈

Linux

For host compilations, if you want to disable C++ exception handling, you must specify option -fno-exceptions. Like, you actually have to.

CAUTION: Files compiled with option -fopenmp-targets or /Qopenmp-targets should also be linked with the same option, or the link step may fail. Ask me how I know 😭

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

Alternate Options:

None — she's one of a kind 💅

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

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

Determines whether the compiler optimizes tail recursive calls. Yes, that's the whole plot.

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. Loops! Iconic.

If you do not want to optimize tail recursive calls, specify -fno-optimize-sibling-calls. Simple as that.

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. Like, the stack stays untouched — main character behavior honestly 👑

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. Crossing the language aisle 🫶

Arguments:

None

Default:

OFF — C/C++ compiler drivers do not link to Fortran libraries. They stay in their lane.

Description:

This option tells the C/C++ compiler driver to link to the Fortran libraries. (Yes, that's the same sentence again — it's that important, okay?) This option is primarily used by C/C++ for mixed-language programming.

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

Alternate Options:

None

🎀 `-fpconstant` (L*X only)

🎀 `-nofpconstant` (L*X only)

Tells the compiler that single-precision constants assigned to double-precision variables should be evaluated in double precision. Extra precision, extra drama.

Arguments:

None

Default:

nofpconstant — single-precision constants assigned to double-precision variables are evaluated in single precision according to Fortran 2003 Standard rules.

Description:

This option tells the compiler that single-precision constants assigned to double-precision variables should be evaluated in double precision.

This is extended precision. It does not comply with the Fortran 2003 standard, which requires that single-precision constants assigned to double-precision variables be evaluated in single precision. Like, the standard says no and this option says "anyway" 😌

It allows compatibility with FORTRAN 77, where such extended precision was allowed. If this option is not used, certain programs originally created for FORTRAN 77 compilers may show different floating-point results because they rely on the extended precision for single-precision constants assigned to double-precision variables. So if the numbers look weird on a legacy program... yeah. That's why. Lowkey important 💜

Alternate Options:

None

🔥 `-fpen` (L*X only)

Allows some control over floating-point exception handling for the main program at runtime. Some control. Not all the control. Manage your expectations bestie.

Arguments:

n — Specifies the floating-point exception handling level. Possible values are:
- 0 — Floating-point invalid, divide-by-zero, and overflow exceptions are enabled throughout the application when the main program is compiled with this value. If any such exceptions occur, execution is aborted. This option causes subnormal floating-point results to be set to zero. Underflow results will also be set to zero, unless you override this by explicitly specifying option -no-ftz or -fp-model precise (Linux*) or option /Qftz- or /fp:precise (Windows*).

Underflow results from SSE instructions, as well as x87 instructions, will be set to zero. By contrast, option [Q]ftz only sets SSE underflow results to zero. (Yeah — [Q]ftz is doing less than 0 here. Not me comparing them 😭)

Sets option -fp-speculation=strict (Linux*) or /Qfp-speculation:strict (Windows*) for any program unit compiled with -fpe0 (Linux*) or /fpe:0 (Windows*). This disables certain optimizations in cases where speculative execution of floating-point operations could lead to floating-point exceptions that would not occur in the absence of speculation. For example, this may prevent the vectorization of some loops containing conditionals.

Disables certain optimizations that generate calls to the Short Vector Math Library that could lead to floating-point exceptions for extreme input arguments that would not occur if libm was called instead. For example, this may prevent the vectorization of some loops containing calls to transcendental math functions.

To get more detailed location information about where the error occurred, use option traceback. Very helpful, highly recommend 🔍

NOTE: If you have more than one module, you must build each module, including the main module, with value fpe0 (Linux) or fpe:0 (Windows) to avoid floating-point exceptions that may occur within the modules. Every. Single. Module. Don't skip the main one either 🫠

1 — All floating-point exceptions are disabled.

Underflow results from SSE instructions, as well as x87 instructions, will be set to zero.

3 — All floating-point exceptions are disabled. Floating-point underflow is gradual, unless you explicitly specify a compiler option that enables flush-to-zero, such as [Q]ftz, O3, or O2. This setting provides full IEEE support. Full IEEE, we stan 🌈

Default:

-fpe3 — All floating-point exceptions are disabled. Floating-point underflow is gradual, unless you explicitly specify a compiler option that enables flush-to-zero.

Description:

This option allows some control over floating-point exception handling at runtime. This includes whether exceptional floating-point values are allowed and how precisely runtime exceptions are reported.

The fpe option affects how the following conditions are handled:

When floating-point calculations result in a divide by zero, overflow, or invalid operation.
When floating-point calculations result in an underflow.
When a subnormal number or other exceptional number (positive infinity, negative infinity, or a NaN) is present in an arithmetic expression.

When enabled exceptions occur, execution is aborted and the cause of the abort gets reported to the user. And if compiler option traceback was specified at compile time, you also get detailed info about where the abort happened. (Very "here's exactly where it went down" of it. 🕵️‍♀️)

Heads up though: this option does not enable underflow exceptions, input subnormal exceptions, or inexact exceptions.

Alternate Options:

None

`-fpe-all=n` (L*X only)

Lets you have some control over floating-point exception handling for each routine in a program at runtime. Cute, right? ✨

Arguments:

n — specifies the floating-point exception handling level. Possible values are:
- 0 — floating-point invalid, divide-by-zero, and overflow exceptions are enabled. If any such exceptions occur, execution is aborted. This option sets the [Q]ftz option; therefore underflow results will be set to zero unless you explicitly specify -no-ftz (Linux) or /Qftz- (Windows). To get more detailed location information about where the error occurred, use option traceback.
- 1 — all floating-point exceptions are disabled. Underflow results from SSE instructions, as well as x87 instructions, will be set to zero.
- 3 — all floating-point exceptions are disabled. Floating-point underflow is gradual, unless you explicitly specify a compiler option that enables flush-to-zero, such as [Q]ftz, O3, or O2. This setting provides full IEEE support.

Default:

-fpe-all=3 — or the setting of fpe that the main program was compiled with. All floating-point exceptions are disabled. Floating-point underflow is gradual, unless you explicitly specify a compiler option that enables flush-to-zero.

Description:

So this option allows some control over floating-point exception handling for each routine in a program at runtime. That includes whether exceptional floating-point values are even allowed, and how precisely runtime exceptions get reported. 💅

The fpe-all option affects how these conditions get handled:

When floating-point calculations result in a divide by zero, overflow, or invalid operation.
When floating-point calculations result in an underflow.
When a subnormal number or other exceptional number (positive infinity, negative infinity, or a NaN) is present in an arithmetic expression.

The current settings of the floating-point exception and status flags are saved on each routine entry and restored on each routine exit. Lowkey that may incur some performance overhead. 😬

When option fpe-all is applied to a main program, it has the same effect as when option fpe is applied to the main program.

When enabled exceptions occur, execution is aborted and the cause of the abort reported to the user. If compiler option traceback is specified at compile time, detailed information about the location of the abort is also reported.

This option does not enable underflow exceptions, input subnormal exceptions, or inexact exceptions.

Option fpe-all sets option assume ieee_fpe_flags.

Alternate Options:

None

`-fpic` (L*X only)

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

Determines whether the compiler generates position-independent code. PIC era!! 🌈

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.

Important bestie: option -fpic must be used when building shared objects. No cap. 🔥

This option can also be specified as -fPIC.

Alternate Options:

None

`-fpie` (L*X only)

Tells the compiler to generate position-independent code. The generated code can only be linked into executables. 🎀

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's 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. (Slay, optimization. 👑)

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.

Option -fpie can also be specified as -fPIE.

Alternate Options:

None

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

Controls the semantics of floating-point calculations. Very "let's define the rules of the float universe" of it. 🦋

Arguments:

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

Default:

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

Description:

This option controls the semantics of floating-point calculations.

Okay so first, 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 giving "control room for floats." 🎛️

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

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

-fp-model=fast[=1|2] or /fp:fast[=1|2] — tells the compiler to go aggressive on floating-point math optimizations. Like, it's gonna go fast. These optimizations increase speed, but ngl they may affect the accuracy or reproducibility of floating-point computations. 🏎️💨

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

Setting fast or fast=1 sets option assume nan_compares; setting fast=2 sets option assume nonan_compares.

-fp-model=consistent or /fp: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. It's giving "same answer, every time" energy ✨

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. The main character of FP models 👑

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

-fp-model=source or /fp:source — this option causes intermediate results to be rounded to the precision defined in the source code. It also implies keyword precise.

It sets options -fprotect-parens and /Qprotect-parens.

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

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

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

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

NOTE: This option cannot be used to change the default (source) precision for the calculation of intermediate results.

📊 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

-fpp (L*X only)
-nofpp (L*X only)

Runs the Fortran preprocessor on source files before compilation. 🧚

Arguments:

fpp_option — is a Fortran preprocessor (fpp) option; it must start with a slash (/) and appear in quotes. This argument is only allowed on Windows* systems.

Default:

nofpp — the Fortran preprocessor is not run on files before compilation.

Description:

This option runs the Fortran preprocessor on source files before they are compiled.

If you want to pass fpp options to the Fortran preprocessor, you can use any of the following methods:

Specify option Qoption,fpp,"option". This is the recommended method. 🫶
Linux: Specify option -Wp,fpp_option (for example, -Wp,-macro=no).
Windows: Specify option fpp and include the argument fpp_option (for example, fpp:"/macro=no").

To see a list of all available fpp options, specify the following on the command line:

Linux:

fpp -help

Windows:

fpp /help

Alternate Options:

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

-fpp-name=name (L*X only) — lets you specify an alternate preprocessor to use with Fortran.

Arguments:

name — is the name of the preprocessor executable. It can include a path. See the description below for more details.

Default:

OFF — no preprocessor is run on files before compilation.

Description:

This option lets you specify an alternate preprocessor to use with Fortran.

The compiler invokes the user-specified Fortran preprocessor by spawning a command with the following signature:

alt_fpp @fpp.arg

where alt_fpp is the name of the Fortran preprocessor you want to use, and fpp.arg is an input file containing the preprocessor's command line arguments.

fpp.arg is generated by the Fortran compiler driver, and contains the -D<define>, -I<include directory>, and input file names from the compiler command line. Compiler predefined options -D<define> and -I<include directory> are also included. Output from the preprocessor goes to STDOUT and will be captured for any further processing. 📥

You can use option Qoption,fpp,… to pass other definitions (using -D<define>), include directories (using -I<include directory>), or other options accepted by the preprocessor.

You can use option Qlocation, fpp,… to specify a directory for supporting tools.

Alternate Options:

None

-fpreview-breaking-changes (L*X only) — lets a user tell the compiler that they are willing to give up backward compatibility guarantees and lets the compiler enable new backward breaking changes that will appear in the next major release. ⚠️✨

Arguments:

None

Default:

OFF — the compiler follows default heuristics for backward compatibility.

Description:

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

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

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-ml-use (L*X only) — enables the use of a pre-trained machine learning model to predict branch execution probabilities driving profile-guided optimizations. This is a deprecated option that will be removed in a future release. 💀🤖

Arguments:

None

Default:

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

Description:

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

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

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

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

Alternate Options:

None

-fprotect-parens (L*X only)
-fno-protect-parens (L*X only)

Determines whether the optimizer honors parentheses when floating-point expressions are evaluated. 🧮

Arguments:

None

Default:

-fno-protect-parens — parentheses are ignored when determining the order of expression evaluation.

Description:

This option determines whether the optimizer honors parentheses when determining the order of floating-point expression evaluation.

When option -fprotect-parens (Linux) or /Qprotect-parens (Windows) is specified, the optimizer will maintain the order of evaluation imposed by parentheses in the code. Respect the parentheses, periodt. 💅

When option -fno-protect-parens (Linux) or /Qprotect-parens- (Windows) is specified, the optimizer may reorder floating-point expressions without regard for parentheses if it produces faster executing code.

Alternate Options:

Linux: -assume protect_parens

Windows: /assume:protect_parens

-fpscomp [keyword[, keyword...]] (L*X only)
-nofpscomp (L*X only)

Controls whether certain aspects of the runtime system and semantic language features inside the compiler play nice with Intel(R) Fortran or Microsoft* Fortran PowerStation. 💅

🌸 Arguments 🌸

keyword — tells the compiler which compatibility flavor to follow, bestie. The possible values are:
- none — no compatibility options at all, we're doing this fresh ✨
- [no]filesfromcmd — decides what compatibility kicks in when the OPEN statement's FILE= specifier is blank
- [no]general — decides what compatibility kicks in when the semantics differ between Fortran PowerStation and Intel(R) Fortran
- [no]ioformat — decides what compatibility is used for list-directed formatted and unformatted I/O
- [no]libs — decides whether the portability library gets passed to the linker
- [no]ldio_spacing — decides whether a blank gets inserted at runtime after a numeric value and before a character value
- [no]logicals — decides what compatibility is used for the representation of LOGICAL values
- all — every single compatibility option, turned on, all at once 👑

🎀 Default 🎀

fpscomp libs

The portability library is passed to the linker. That's the vibe out of the box. 🫶

💖 Description 💖

This option controls whether certain aspects of the runtime system and semantic language features within the compiler are compatible with Intel Fortran or Microsoft* Fortran PowerStation.

If you're having a whole ✨moment✨ porting applications from Fortran PowerStation, specify fpscomp (or fpscomp all). When porting applications from Intel Fortran, use fpscomp none or fpscomp libs (the default).

⭐ The options, one by one ⭐

fpscomp none — specifies that no options should be used for compatibility with Fortran PowerStation. This is the exact same thing as specifying nofpscomp. Option fpscomp none enables full Intel(R) Fortran compatibility. If you omit fpscomp, the default is fpscomp libs. And heads up 🫵 you cannot use the fpscomp and vms options in the same command.
fpscomp filesfromcmd — specifies Fortran PowerStation behavior when the OPEN statement FILE= specifier is blank (FILE=' '). It causes the following actions to be taken at runtime:
- The program reads a file name from the list of arguments (if any) in the command line that invoked the program. If any of the command-line arguments contain a null string (''), the program asks the user for the corresponding file name. Each additional OPEN statement with a blank FILE= specifier reads the next command-line argument.
- If there are more nameless OPEN statements than command-line arguments, the program prompts for additional file names.
- In a QuickWin application, a "File Select" dialog box appears to request file names.

To prevent the runtime system from using the file name specified on the command line when the OPEN statement FILE specifier is omitted, specify fpscomp nofilesfromcmd. This allows the application of Intel Fortran defaults, such as the FORTn environment variable and the FORT.n file name (where n is the unit number).

The fpscomp filesfromcmd option affects the following Fortran features:

The OPEN statement FILE specifier — for example, assume a program OPENTEST contains the following statements:

OPEN(UNIT = 2, FILE = ' ') OPEN(UNIT = 3, FILE = ' ') OPEN(UNIT = 4, FILE = ' ')

The following command line assigns the file TEST.DAT to unit 2, prompts the user for a file name to associate with unit 3, then prompts again for a file name to associate with unit 4:

opentest test.dat '' ''

Implicit file open statements such as the WRITE, READ, and ENDFILE statements — unopened files referred to in READ or WRITE statements are opened implicitly as if there had been an OPEN statement with a name specified as all blanks. The name is read from the command line. 😮‍💨

fpscomp general — specifies that Fortran PowerStation semantics should be used when a difference exists between Intel Fortran and Fortran PowerStation. The fpscomp general option affects the following Fortran features:
- The BACKSPACE statement:
  - It allows files opened with ACCESS='APPEND' to be used with the BACKSPACE statement.
  - It allows files opened with ACCESS='DIRECT' to be used with the BACKSPACE statement.

Note: Allowing files that are not opened with sequential access (such as ACCESS='DIRECT') to be used with the BACKSPACE statement violates the Fortran 95 standard and may be removed in the future. 💀

The READ statement:
- It causes a READ from a formatted file opened for direct access to read records that have the same record type format as Fortran PowerStation. This consists of accounting for the trailing Carriage Return/Line Feed pair (<CR><LF>) that is part of the record. It allows sequential reads from a formatted file opened for direct access.

Note: Allowing files that are not opened with sequential access (such as ACCESS='DIRECT') to be used with the sequential READ statement violates the Fortran 95 standard and may be removed in the future. 💀

It allows the last record in a file opened with FORM='FORMATTED' and a record type of STREAM_LF or STREAM_CR that does not end with a proper record terminator (<line feed> or <carriage return>) to be read without producing an error.
It allows sequential reads from an unformatted file opened for direct access.

Note: Allowing files that are not opened with sequential access (such as ACCESS='DIRECT') to be read with the sequential READ statement violates the Fortran 95 standard and may be removed in the future. 💀

The INQUIRE statement:
- The CARRIAGECONTROL specifier returns the value "UNDEFINED" instead of "UNKNOWN" when the carriage control is not known.
- The NAME specifier returns the file name "UNKNOWN" instead of filling the file name with spaces when the file name is not known.
- The SEQUENTIAL specifier returns the value "YES" instead of "NO" for a direct access formatted file.
- The UNFORMATTED specifier returns the value "NO" instead of "UNKNOWN" when it is not known whether unformatted I/O can be performed to the file.

Note: Returning the value "NO" instead of "UNKNOWN" for this specifier violates the Fortran 95 standard and may be removed in the future. 💀

The OPEN statement:
- If a file is opened with an unspecified STATUS keyword value, and is not named (no FILE specifier), the file is opened as a scratch file. For example:

OPEN (UNIT = 4)

In contrast, when fpscomp nogeneral is in effect with an unspecified STATUS value with no FILE specifier, the FORTn environment variable and the FORT.n file name are used (where n is the unit number).
If the STATUS value was not specified and if the name of the file is "USER", the file is marked for deletion when it is closed.
It allows a file to be opened with the APPEND and READONLY characteristics.
If the default for the CARRIAGECONTROL specifier is assumed, it gives "LIST" carriage control to direct access formatted files instead of "NONE".
If the default for the CARRIAGECONTROL specifier is assumed and the device type is a terminal file, the file is given the default carriage control value of "FORTRAN" instead of "LIST".
It gives an opened file the additional default of write sharing.
It gives the file a default block size of 1024 instead of 8192. (yes that's a whole 8x, don't @ me 😭)
If the default for the MODE and ACTION specifier is assumed and there was an error opening the file, try opening the file as read only, then write only.

If a file that is being re-opened has a different file type than the current existing file, an error is returned. no cap, bestie, that’s a hard stop. 😭
It gives direct access formatted files the same record type as Fortran PowerStation. This means accounting for the trailing Carriage Return/Line Feed pair (<CR><LF>) that is part of the record.
The STOP statement: it writes the Fortran PowerStation output string and/or returns the same exit condition values.
The WRITE statement:
- Writing to formatted direct files: When writing to a formatted file opened for direct access, records are written in the same record type format as Fortran PowerStation. This consists of adding the trailing Carriage Return/Line Feed pair <CR><LF>) that is part of the record. It ignores the CARRIAGECONTROL specifier setting when writing to a formatted direct access file.
- Interpreting Fortran carriage control characters: When interpreting Fortran carriage control characters during formatted I/O, carriage control sequences are written that are the same as Fortran PowerStation. This is true for the "Space, 0, 1 and + " characters.
- Performing non-advancing I/O to the terminal: When performing non-advancing I/O to the terminal, output is written in the same format as Fortran PowerStation.
- Interpreting the backslash (\) and dollar ($) edit descriptors: When interpreting backslash and dollar edit descriptors during formatted I/O, sequences are written the same as Fortran PowerStation.
- Performing sequential writes: It allows sequential writes from an unformatted file opened for direct access.

Note: Allowing files that are not opened with sequential access (such as ACCESS='DIRECT') to be read with the sequential WRITE statement violates the Fortran 95 standard and may be removed in the future. periodt, that’s a real warning, not a vibe. 💀

Specifying fpscomp general sets fpscomp ldio_spacing.

fpscomp ioformat — Specifies that Fortran PowerStation semantic conventions and record formats should be used for list-directed formatted and unformatted I/O. The fpscomp ioformat option affects the following Fortran features:
- The WRITE statement:
 - For formatted list-directed WRITE statements, formatted internal list-directed WRITE statements, and formatted namelist WRITE statements, the output line, field width values, and the list-directed data type semantics are determined according to the following sample for real constants (N below): For 1 <= N < 10**7, use F15.6 for single precision or F24.15 for double. For N < 1 or N >= 10**7, use E15.6E2 for single precision or E24.15E3 for double. See the Fortran PowerStation documentation for more detailed information about the other data types affected.
 - For unformatted WRITE statements, the unformatted file semantics are dictated according to the Fortran PowerStation documentation; these semantics are different from the Intel Fortran file format. See the Fortran PowerStation documentation for more detailed information. The following table summarizes the default output formats for list-directed output with the intrinsic data types:
- The READ statement:
 - For formatted list-directed READ statements, formatted internal list-directed READ statements, and formatted namelist READ statements, the field width values and the list-directed semantics are dictated according to the following sample for real constants (N below): For 1 <= N < 10**7, use F15.6 for single precision or F24.15 for double. For N < 1 or N >= 10**7, use E15.6E2 for single precision or E24.15E3 for double. See the Fortran PowerStation documentation for more detailed information about the other data types affected.
 - For unformatted READ statements, the unformatted file semantics are dictated according to the Fortran PowerStation documentation; these semantics are different from the Intel Fortran file format. See the Fortran PowerStation documentation for more detailed information.
fpscomp nolibs — Prevents the portability library from being passed to the linker.
fpscomp ldio_spacing — Specifies that at runtime a blank should not be inserted after a numeric value before a character value (undelimited character string). This representation is used by Intel Fortran releases before Version 8.0 and by Fortran PowerStation. If you specify fpscomp general, it sets fpscomp ldio_spacing.
fpscomp logicals — Specifies that integers with a non-zero value are treated as true, integers with a zero value are treated as false. The literal constant .TRUE. has an integer value of 1, and the literal constant releases before Version 8.0 and by Fortran PowerStation.

The default is fpscomp nologicals, which specifies that odd integer values (low bit one) are treated as true and even integer values (low bit zero) are treated as false.

The literal constant .TRUE. has an integer value of -1, and the literal constant .FALSE. has an integer value of 0. This representation is used by Compaq* Visual Fortran.

The internal representation of LOGICAL values is not specified by the Fortran standard. Programs that use integer values in LOGICAL contexts, or that pass LOGICAL values to procedures written in other languages, are non-portable and may not execute correctly. Intel recommends that you avoid coding practices that depend on the internal representation of LOGICAL values. bestie, this is the “do not build your whole personality on this” warning. 🙈

The fpscomp logicals option affects the results of all logical expressions and affects the return value for the following Fortran features:

The INQUIRE statement specifiers OPENED, IOFOCUS, EXISTS, and NAMED
The EOF intrinsic function
The BTEST intrinsic function
The lexical intrinsic functions LLT, LLE, LGT, and LGE
fpscomp all — Specifies that all options should be used for compatibility with Fortran PowerStation. This is the same as specifying fpscomp with no keyword. Option fpscomp all enables full compatibility with Fortran PowerStation.
Alternate Options: None

-fp-speculation=mode (L*X only) — Tells the compiler the mode in which to speculate on floating-point operations. floating-point chaos mode selection, basically. ✨
- 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 — The compiler speculates on floating-point operations. This is also the behavior when optimizations are enabled.
  - However, if you specify no optimizations (-O0), the default changes to -fp-speculation=safe (Linux).
- Description:
  - This option tells the compiler the mode in which to speculate on floating-point operations.
  - Disabling speculation may prevent the vectorization of some loops containing conditionals.
- Alternate Options: None

-free (L*X only)
-nofree (L*X only) — Specifies source files are in free format. free-format source files said slay. 🦋
- Arguments: None
- Default: OFF — The source file format is determined from the file extension.
- Description: This option specifies source files are in free format. If this option is not specified, format is determined as follows:
  - Files with an extension of .f90, .F90, or .i90 are free-format source files.
  - Files with an extension of .f, .for, .FOR, .ftn, or
- Alternate Options: Linux: -FR

-fsanitize=sanitizer (L*X only) — Enables the specified code sanitizer to detect certain issues at runtime. runtime detective mode: activated. 🔥
- Arguments:
  - sanitizer — Specifies the code sanitizer to use. You can only specify one sanitizer. Possible values are:
    - address — Detects buffer overflows/underflows (Linux and Windows) and memory leaks (Linux only).
memory — (Linux only) hunts down uninitialized variables. 💅 Heads up though: the memory sanitizer needs all the code to be sanitized — and yes that includes library code that's linked, whether it's linked dynamically or statically — otherwise you'll get false positives, either in your code or in the library code. No cap, it's an all-or-nothing vibe.

This setting is literally the same as specifying option -check uninit.

thread — (Linux only) catches data races in a threaded program. 🧵✨

Default:

OFF — the sanitizers just follow default heuristics at runtime.

Description:

This option turns on the code sanitizer you picked so it can detect certain issues at runtime. 🕵️‍♀️

Option fsanitize is especially useful when you want to make sure your program is genuinely free of the various issues the sanitizers detect, or when your program is behaving erratically and you cannot pinpoint the issue by inspecting the source code or by using a debugger. It's giving "diagnostic main character energy". 🔥

When you're running a thread-sanitized OpenMP program, please set the environment variable "OMP_TOOL_LIBRARIES='libarcher.so'" so you get more accurate data race detections. 🙏

Do NOT specify fsanitize when building production code. Like, seriously. It's not that girl for shipped binaries. 💀

To ensure the required runtime libraries are linked and correctly initialized, specify option -fsanitize in the link command if any part of the object file is compiled with this option. 🔗

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

Alternate Options:

None

🛡️ `-fstack-protector[-keyword]` (L*X only)

🛡️ `-fno-stack-protector[-keyword]` (L*X only)

Enables or disables stack overflow security checks. 🎀

Arguments:

keyword — the 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. every single one 👑

If no -keyword is specified, option -fstack-protector enables stack overflow security checks for routines with a string buffer. 🧵

Default:

-fno-stack-protector, -fno-stack-protector-strong — no stack overflow security checks are enabled for the relevant routines.
-fno-stack-protector-all — no stack overflow security checks are enabled for any routines.

Description:

This option enables or disables stack overflow security checks for certain (or all) routines. A stack overflow occurs when a program stores more data in a variable on the execution stack than is allocated to the variable. Writing past the end of a string buffer or using an index for an array that is larger than the array bound could cause a stack overflow and security violations. 😭 Not the vibe.

The -fstack-protector options are provided for compatibility with gcc. If the gcc/glibc implementation is available, it is used; otherwise, the Intel implementation is used. 🤝

For an Intel-specific version of this feature, see option -fstack-security-check.

Alternate Options:

None

🔍 `-fstack-security-check` (L*X only)

🔍 `-fno-stack-security-check` (L*X only)

Determines whether the compiler generates code that detects some buffer overruns. 🐛

Arguments:

None

Default:

-fno-stack-security-check — the compiler does not detect buffer overruns.

Description:

This option determines whether the compiler generates code that detects some buffer overruns that overwrite the return address. This is a common technique for exploiting code that does not enforce buffer size restrictions. 🚨 Lowkey scary, highkey important.

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

🌀 `-fstrict-overflow` (for Clang compatibility) (L*X only)

🌀 `-fno-strict-overflow` (for Clang compatibility) (L*X only)

Determines whether strict overflow is enabled for signed addition, subtraction, and multiplication wrap arounds using twos-complement representation. ➕➖✖️

Arguments:

None

Default:

-fstrict-overflow or /Qstrict-overflow — strict overflow is enabled for signed arithmetic overflow of addition, subtraction, and multiplication wrap arounds using twos-complement representation.

Description:

This option determines whether strict overflow is enabled for signed addition, subtraction, and multiplication wrap arounds using twos-complement representation. (Yes, we said it twice, it's that iconic. 💅)

Integer overflow occurs when an operation on two integer values results in a value that is too large to be represented in an integer of the size specified; for example, two 32-bit integers added together result in a value that does not fit into 32 bits. 🤯

When overflow occurs, as much of the value as can fit into the result is assigned, usually resulting in a negative number. 🫠

When -fstrict-overflow (Linux) or /Qstrict-overflow (Windows) is in effect, the compiler assumes that integer operations can never overflow. This can provide better optimizations. However, if overflow does occur, the resulting behavior is undefined. ⚠️ Like, undefined undefined. Don't play with that.

If your program relies on integer overflow to work, specify -fno-strict-overflow (Linux) or /Qstrict-overflow- (Windows). This permits overflow but may produce less optimized code. 🐌

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

Alternate Options:

None

🌈 `-fsycl` (L*X only)

Enables Fortran to perform the SYCL offload device linking steps for potential SYCL-based fat objects or libraries. ✨

Arguments:

None

Default:

OFF — Fortran object files are not linked with SYCL object files.

Description:

This option enables Fortran to perform the SYCL offload device linking steps for potential SYCL-based fat objects or libraries. 💖

NOTE: This option is only valid when using ifx to link your executable. 🫶

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-dead-args-optimization` (L*X only)

🦋 `-fno-sycl-dead-args-optimization` (L*X only)

Enables elimination of SYCL dead kernel arguments. 🧹

Arguments:

None

Default:

OFF — SYCL dead kernel arguments are not eliminated. This default may change in the future. 👀

Description:

This option enables elimination of SYCL dead kernel arguments. This optimization can improve performance. 🚀

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

If you specify -fno-sycl-dead-args-optimization, this optimization is disabled. 🙅‍♀️

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

Alternate Options:

None

🎀 `-fsycl-device-code-split[=value]` (L*X only)

Specifies a SYCL* device code module assembly. 🧩

Arguments:

value — can be only one of the following:

per_kernel — 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. 🌟
per_source — creates a separate device code module for each source (translation unit). Each device code module will contain a collection of kernels grouped on per-source basis and all their dependencies, such as all used variables and called functions, including the SYCL_EXTERNAL macro-marked functions from other translation units. 📚
off — creates a single module for all kernels. 1️⃣
auto — compiler goes full detective mode and uses a heuristic to pick the best way of splitting device code. It's literally the same as specifying 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 runs its heuristic to pick the best way of splitting device code. 💅

Description:

This option specifies a SYCL* device code module assembly.

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-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. bestie this is the on/off switch for device libs.

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.

Wanna link more than one library? Drop a comma between the library names. Say you want both the libm-fp32 device library and the C library — you'd specify libm-fp32,libc.

Do not add spaces between library names. (fr fr, no spaces, the compiler is not playing.) 🫶

Also note: if you specify all, it supersedes any additional value you may specify. all said what it said. 👑

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 you use 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-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 that is a whole lot of capital letters, we love an acronym moment.

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). What does that even do? It provides annotations to intercept various events inside kernels generated by Just in Time (JIT) compilation. spyware but make it profiling 💀 (jk, it's for tracing).

NOTE: when you use 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. Zero. None. Nada.

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. This option is only valid for linking against SYCL-based objects.

Arguments:

T — is a target triple device name. If you specify more than one T, they must be separated by commas. (commas, bestie, not spaces, not vibes.) 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.
- 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. It is only valid for linking against SYCL-based objects.

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. it's giving "everything bagel" but for binaries 🥯

NOTE: the long syntax values that include -sycldevice, such as spir64-unknown-unknown-sycldevice, are still supported, but they are deprecated. 👵 they still work, they're just old news.

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

-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. (experimental = it's in its experimental era, handle with care 🙈)

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. one-time long compile? worth it. take the time, bestie. 💖

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-register-alloc-mode=device-name:reg-mode[,device-name:reg-mode][,...] (L*X only) 🧚

Specifies a register allocation mode for specific hardware for use by supported target backends.

Arguments:

device-name — is the device name. Currently, you can only specify the following:
- pvc — indicates a Ponte Vecchio (PVC) device.

More devices may be added in the future. (watch this space 👀)

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 following is the default behavior on PVC hardware:

Linux: -ftarget-register-alloc-mode=pvc:auto — tells the target backend to use internal heuristics to select a register allocation mode based on kernel analysis.
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. Currently, it has no effect if you are targeting hardware other than Ponte Vecchio (PVC). sorry to everyone else, PVC is the main character here 👑

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

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

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

Alternate Options: None

-ftrapuv (L*X only) — Initializes stack local variables to an unusual value to aid error detection. 🫶
- Arguments: None
- Default: OFF — the compiler does not initialize local variables.
- Description: This option initializes stack local variables to an unusual value to aid error detection. Normally, these local variables should be initialized in the application. It also unmasks the floating-point invalid exception.

This option sets option -g (Linux*) and /Zi or /Z7 (Windows*), which changes the default optimization level from O2 to -O0 (Linux) or /Od (Windows). You can override this effect by explicitly specifying an O option setting.

This option sets option [Q]init snan.

If option O2 and option -ftrapuv (Linux) or /Qtrapuv (Windows) are used together, you should specify option -fp-speculation safe (Linux) or /Qfp-speculation:safe (Windows) to prevent exceptions resulting from speculated floating-point operations from being trapped.

For more details on using options -ftrapuv and /Qtrapuv with compiler option O, see the article titled Don't optimize when using -ftrapuv for uninitialized variable detection.

Another way to detect uninitialized local scalar variables is by specifying keyword uninit for option check.

Alternate Options: None

-ftz (L*X only)
-no-ftz (L*X only) — Flushes subnormal results to zero. ✨
- Arguments: None
- Default: -ftz — subnormal results are flushed to zero.

Every optimization option O level, except O0, sets [Q]ftz.

Value 0 for the [Q]fpe option sets [Q]ftz.

Description: This option flushes subnormal results to zero when the application is in the gradual underflow mode. It may improve performance if the subnormal 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. If FTZ is ON, subnormal results from floating-point calculations will be set to the value zero. If FTZ is OFF, subnormal results remain as is. If DAZ is ON, subnormal values used as input to floating-point instructions will be treated as zero. If DAZ is OFF, subnormal 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.

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

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.

NOTE: For ifx 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 (L*X only)
-fno-vec-allow-scalar-stores (L*X 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 OpenMP* directive 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 (L*X only)
-fno-vec-non-loop-argument-load (L*X 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 (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 (L*X only)
-fno-vec-peel-loops (L*X 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.

Alternate Options: None

-fvec-remainder-loops (L*X only)
-fno-vec-remainder-loops (L*X 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 !DIR$ VECTOR VECREMAINDER on the loop.

Alternate Options: None

-fvec-with-mask (L*X only)
-fno-vec-with-mask (L*X only) — Enables vectorization for short trip-count loops with masking. 🎀
- Arguments: None
- Default:

💅 `-fno-vec-with-mask`

What it does: no vectorization for short trip-count loops with masking occurs. Periodt.
Description: this option enables a special mode of vectorization, and it's the vibe 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, bestie.

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. That's just how it do. ✨

Alternate Options: None 🙅‍♀️

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

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

What it does: produces an assembly listing with compiler comments, including options and version information.
Arguments: None
Default: -fno-verbose-asm — no source code annotations appear in the assembly listing file, if one is produced.
Description: this option produces an assembly listing file with compiler comments, including options and version information. Iconic behavior, honestly.

To use this option, you must also specify -S, which sets -fverbose-asm. So like, -S is the main character here and this option is its hype squad.

If you do not want this default when you specify -S, specify -fno-verbose-asm.

NOTE:</> this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. No cap.

Alternate Options: None 💅

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

🦋 `-fvisibility-keyword=filename` (L*X only)

What it does: specifies the default visibility for global symbols or the visibility for symbols in a file.
Arguments:
- keyword — specifies the visibility setting. Possible values are:
  - default — sets visibility to default.
  - extern — sets visibility to extern.
  - hidden — sets visibility to hidden.
  - internal — sets visibility to internal.
  - protected — sets visibility to protected.
- filename — is the pathname of a file containing the list of symbols whose visibility you want to set. The symbols must be separated by whitespace (spaces, tabs, or newlines). So like, spaces are fine, tabs are fine, newlines are fine — just keep them separated, bestie.
Default: -fvisibility=default — the compiler sets visibility of symbols to default.
Description: this option specifies the default visibility for global symbols (syntax -fvisibility=keyword) or the visibility for symbols in a file (syntax -fvisibility-keyword=filename).

Visibility specified by -fvisibility-keyword=filename overrides visibility specified by -fvisibility=keyword for symbols specified in a file. The file said what it said, and it wins. 💅

Here's the full tea on every combo:

-fvisibility=default / -fvisibility-default=filename — sets visibility of symbols to default. This means other components can reference the symbol, and the symbol definition can be overridden (preempted) by a definition of the same name in another component.
-fvisibility=extern / -fvisibility-extern=filename — sets visibility of symbols to extern. This means the symbol is treated as though it is defined in another component. It also means that the symbol can be overridden by a definition of the same name in another component.
-fvisibility=hidden / -fvisibility-hidden=filename — sets visibility of symbols to hidden. This means that other components cannot directly reference the symbol. However, its address may be passed to other components indirectly. Sneaky but legal. 🙈
-fvisibility=internal / -fvisibility-internal=filename — sets visibility of symbols to internal. This means that the symbol cannot be referenced outside its defining component, either directly or indirectly. The affected functions can never be called from another module, including through function pointers. It's giving "you don't know her" energy. 💀
-fvisibility=protected / -fvisibility-protected=filename — sets visibility of symbols to protected. This means other components can reference the symbol, but it cannot be overridden by a definition of the same name in another component. Look but don't touch, basically. ✨

If an -fvisibility option is specified more than once on the command line, the last specification takes precedence over any others. Last one wins, periodt.

If a symbol appears in more than one visibility filename, the setting with the least visibility takes precedence. The quietest one speaks loudest, iykyk.

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

extern
default
protected
hidden
internal

Note that extern visibility only applies to functions. If a variable symbol is specified as extern, it is assumed to be default. Not me pointing that out so you don't get caught out. 🫶

Alternate Options: None 🎀

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

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

What it does: determines whether the compiler places in the DATA section any variables explicitly initialized with zeros.
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. Efficiency queen. 👑
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. Yes, the Windows spelling is different, and yes, you still have to type it exactly. 😭

Alternate Options: None 💜

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

What it does: tells the compiler to generate a level of debugging information in the object file.
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. Bigger file, bigger debug energy. 🦋

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. That's just the rules, bestie.

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 -g lowkey changes your optimization situation — don't forget.

Specifying the -g or -O0 option sets the -fno-omit-frame-pointer option.

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. If your tool is acting ancient, that's why. 💀

Alternate Options:
- Linux: None
- Windows: /Zi, /Z7

🧚 `-gcc-name=name` (L*X only)

What it does: lets you specify the name of the GCC compiler that should be used to set up the link-time environment, including the location of standard libraries.
Arguments:
- name — is the name of the GCC compiler to use. It can include the path where the GCC compiler is located.
Default: OFF — the compiler uses the PATH setting to find the GCC compiler and resolve environment settings.
Description: this option lets you specify the name of the GCC compiler that should be used to set up the link-time environment, including the location of standard libraries. If you do not specify a path, the compiler will search the PATH settings for the compiler name you provide. It's giving "she'll find it herself". ✨

This option is helpful when you are referencing a non-standard GCC installation, or you have multiple GCC installations on your system. The compiler will match GCC version values to the GCC compiler you specify.

The C++ equivalent to option -gcc-name is -gxx-name. Sibling energy. 🫶

Alternate Options: None 🌸

🎀 `-gdwarf-n` (L*X only)

What it does: lets you specify a DWARF Version format when generating debug information.
Arguments:
- n — is a value denoting the DWARF Version format to use. Possible values are:
  - 2 — generates debug information using the DWARF Version 2 format.
3 — makes debug info in the DWARF Version 3 format ✨
4 — makes debug info in the DWARF Version 4 format 💖
5 — makes debug info in the DWARF Version 5 format 🎀

Default:

OFF — no debug info gets generated at all, bestie. BUT — plot twist — if you also pass compiler option -g, then debug info does get generated, in the DWARF Version 4 format. 🙈

Description:

So this option is literally your "pick a DWARF Version" menu when you're generating debug info 🌸

Lowkey important heads up: older versions of some analysis tools may need your apps built with -gdwarf-2 to work correctly. iykyk 😭

Alternate Options:

None 💅

-gen-dep[=filename] (L*X only) 🦋
-no-gen-dep (L*X only)

Tells the compiler to generate build dependencies for the current compilation 👑

Arguments:

filename — the name of the file for output, and yes it can totally include a path ✨

If you specify filename, it's similar to specifying option [Q]MFfilename. If you don't specify filename, it's similar to specifying option [Q]MD or [Q]MMD 💖

Default:

-no-gen-dep or /gen-dep- — the compiler does NOT generate build dependencies for the compilation 🚫

Description:

This option tells the compiler to generate build dependencies for the current compilation — fr fr, it's giving "let me track everything for you" energy 🌈 The build dependencies include a list of all files included with INCLUDE statements or .mod files accessed with USE statements 👀

If you don't specify filename, the dependencies get written to stdout 💻

You can use option gen-depformat to pick the form of the output for the build dependencies generated 🎀

If you specify option gen-dep and you don't specify option gen-depformat, the output format is in a form acceptable to the make utility 🛠️

Note that if option fpp is used to process #include files, those files will also show up in the list of build dependencies 👑

If you wanna generate build dependencies but you do NOT wanna compile the sources, you must also specify option syntax-only — no cap, that's the rule 😤

Alternate Options:

gen-dep with a filename — Linux: -MF
gen-dep with no filename — Linux: -MD or -MMD

-gen-depformat=form (L*X only) 🦋

Specifies the form for the output generated when option gen-dep is specified ✨

Arguments:

form — the output form for the list of build dependencies. Possible values are make or nmake 🎀

Default:

make — the output form for the list of build dependencies is in a form acceptable to the make utility 💅

Description:

This option specifies the form for the output generated when option gen-dep is specified 👑

Option gen-depformat is ignored unless you also specify option gen-dep. Like, it does nothing on its own, bestie 💀

Alternate Options:

None 🌸

-gen-depshow=keyword (L*X only) 🦋

Determines whether certain features are excluded from dependency analysis. Currently, it only applies to intrinsic modules 👀

Arguments:

keyword — specifies inclusion or exclusion from dependency analysis. Possible values are:
- [no]intr_mod — determines whether intrinsic modules are excluded from dependency analysis 💖

Default:

nointr_mod — tells the compiler to exclude Fortran intrinsic modules in dependency analysis 🚫

Description:

This option determines whether certain features are excluded from dependency analysis. Currently, it only applies to intrinsic modules ✨

Here's the rundown, bestie:

gen-depshow intr_mod — tells the compiler to include Fortran intrinsic modules in dependency analysis 👑

Option gen-depshow is ignored unless you also specify option gen-dep, which generates build dependencies for the compilation 🙈

Alternate Options:

gen-depshow nointr_mod — Linux: -MMD

-gen-interfaces [[no]source] (L*X only) 🦋
-nogen-interfaces (L*X only)

Tells the compiler to generate an interface block for each routine in a source file 👑

Arguments:

None 💅

Default:

nogen-interfaces — the compiler does NOT generate interface blocks for routines in a source file 🚫

Description:

This option tells the compiler to generate an interface block for each routine (that is, for each SUBROUTINE and FUNCTION statement) defined in the source file ✨ The compiler generates two files for each routine, a .mod file and a .f90 file, and places them in the current directory or in the directory specified by the include (-I) or -module option 💖 The .f90 file is the text of the interface block; the .mod file is the interface block compiled into binary form. The .f90 file is for reference only and may not completely represent the generated interface used by the compiler 🎀

If source is specified, the compiler creates the procedure-name__GENmod.f90 as well as the procedure-name__GENmod.mod files 🦋 If nosource is specified, the compiler creates the procedure-name__GENmod.mod but NOT the procedure-name__GENmod.f90 files. If neither is specified, it's the same as specifying setting source for the gen-interfaces option 🌸

On Windows* systems, for a Debug configuration in a Visual Studio project, the default is /warn:interfaces 👀

Alternate Options:

None 💅

-global-hoist (L*X only) 🦋
-no-global-hoist (L*X only)

Enables certain optimizations that can move memory loads to a point earlier in the program execution than where they appear in the source 🔥

Arguments:

None ✨

Default:

-global-hoist — certain optimizations are enabled that can move memory loads 👑

Description:

This option enables certain optimizations that can move memory loads to a point earlier in the program execution than where they appear in the source 💖 In most cases, these optimizations are safe and can improve performance 🚀

The negative form of the option is useful for some applications, such as those that use shared or dynamically mapped memory, which can fail if a load is moved too early in the execution stream (for example, before the memory is mapped) 😭 Like, real talk, this can genuinely break stuff if you're not careful 💀

Alternate Options:

None 🌸

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

Causes the command line options that were used to invoke the compiler to be appended to the DW_AT_producer attribute in DWARF debugging information 👑

Arguments:

None 💅

Default:

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

Description:

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

The options are concatenated with whitespace separating them from each other and from the compiler version 🎀

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 💅 (smaller exe = slay 🔥)

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 doesn't support the split DWARF format, it will behave as though the DWARF debug information is absent 💀 Like, it just won't see it at all, bestie.

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

Alternate Options:

None 🌸

-gxx-name=name (L*X only) 🦋

Lets you specify the name of the g++ compiler that should be used to set up the link-time environment, including the location of standard libraries 👑

Arguments:

name — the name of the g++ compiler to use. It can include the path where the g++ compiler is located 💖

Default:

OFF — the compiler uses the PATH setting to find the g++ compiler and resolve environment settings 🌸

Description:

okay so this option lets you name the g++ compiler that gets used to set up the link-time environment — and yes, that includes where the standard libraries live. If you don't hand it a path, the compiler goes hunting through your PATH settings for whatever compiler name you gave it. 🕵️‍♀️

It's highkey helpful when you've got multiple gcc++ installations hanging around on your system. The compiler will match gcc++ version values to the gcc++ compiler you specify. 💅

The C equivalent to option -gxx-name is -gcc-name. (iykyk 🫶)

Alternate Options: None

`-heap-arrays` [`size`] (L*X only)

`-no-heap-arrays` (L*X only)

Puts automatic arrays — and arrays created for temporary computations — on the heap instead of the stack. literally moving the vibe. ✨

Arguments:
- size — Is an integer value representing the size of the arrays in kilobytes. Arrays smaller than size are put on the stack.
Default:
- -no-heap-arrays — The compiler puts automatic arrays and temporary arrays in the stack storage area.
Description:

This option puts automatic arrays and arrays created for temporary computations on the heap instead of the stack.

If size is specified:

Automatic (temporary) arrays that have a compile-time size greater than the value specified for size are put on the heap, rather than on the stack. If the compiler cannot determine the size at compile time, it puts the automatic array on the heap.
The value is only used when the total size of the temporary array or automatic array can be determined at compile time, using compile-time constants.

Any arrays known at compile-time to be larger than size are allocated on the heap instead of the stack. For example, if 10 is specified for size:

All automatic and temporary arrays equal to or larger than 10 KB are put on the heap.
All automatic and temporary arrays smaller than 10 KB are put on the stack.

If size is omitted, and the size of the temporary array or automatic array cannot be determined at compile time, it is assumed that the total size is greater than size and the array is allocated on the heap. 🎀

Linux

You can use the shell command ulimit to increase the size of the runtime stack before execution.

Windows

You can use compiler option /F to tell the linker to increase the size of the runtime stack to allow for large objects on the stack.

Alternate Options: None

`-help`[`category`] (L*X only)

Displays all supported compiler options — or, like, just the supported ones inside a specified category. the whole menu, but filtered. 👑

Arguments:
- category — Is a category or class of options to display. Possible values are:
  - advanced — Displays advanced optimization options that allow fine tuning of compilation or allow control over advanced features of the compiler.
  - codegen — Displays Code Generation options.
  - compatibility — Displays options affecting language compatibility.
  - component — Displays options for component control.
  - data — Displays options related to interpretation of data in programs or the storage of data.
  - diagnostics — Displays options that affect diagnostic messages displayed by the compiler.
  - float — Displays options that affect floating-point operations.
  - help — Displays all the available help categories.
  - inline — Displays options that affect inlining.
  - ipo — Displays Interprocedural Optimization (IPO) options
  - language — Displays options affecting the behavior of the compiler language features.
  - link — Displays linking or linker options.
  - misc — Displays miscellaneous options that do not fit within other categories.
  - openmp — Displays OpenMP and parallel processing options.
  - opt — Displays options that help you optimize code.
  - output — Displays options that provide control over compiler output.
  - preproc — Displays options that affect preprocessing operations.
  - reports — Displays options for optimization reports.
Default:
- OFF — No list is displayed unless this compiler option is specified.
Description:

This option displays all supported compiler options or supported compiler options within a specified category of options. If you specify category, it will display all available (supported) compiler options in the specified category. 🌈

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

Alternate Options:
- Linux: None

`-Idir` (L*X only)

Specifies an additional directory for the include path. more places to look, more friends to find. 🔍

Arguments:
- dir — Is the directory to add to the include path.
Default:
- OFF — The default include path is used.
Description:

This option specifies an additional directory for the include path, which is searched for module files referenced in USE statements and include files referenced in INCLUDE statements. To specify multiple directories on the command line, repeat the option for each directory you want to add. ✨

For all USE statements and for those INCLUDE statements whose file name does not begin with a device or directory name, the directories are searched in this order:

The directory containing the first source file.

Note that if assume nosource_include is specified, this directory will not be searched.

The current working directory where the compilation is taking place (if different from the above directory).
Any directory or directories specified using the I option. If multiple directories are specified, they are searched in the order specified on the command line, from left to right.
On Linux* systems, any directories indicated using environment variable CPATH. On Windows* systems, any directories indicated using environment variable INCLUDE.

This option affects fpp preprocessor behavior and the USE statement.

Alternate Options:
- Linux: None

`-idirafterdir` (L*X only)

Adds a directory to the second include file search path. the understudy of include paths 🎭

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

`-init=keyword`[, `keyword` ] (L*X only)

Lets you initialize a class of variables to zero — or to various numeric exceptional values. set it and forget it, bestie 💅

Arguments:
- keyword — Specifies the initial value for a class of variables. Possible values are:
  - [no]arrays — Determines whether the compiler initializes variables that are arrays or scalars. Specifying arrays initializes variables that are arrays or scalars. Specifying noarrays or neither arrays or noarrays initializes only variables that are scalars. You must also specify at least one other keyword when you specify keyword noarrays.
  - huge or minus_huge — Determines both of the following:
    - whether the compiler initializes to the largest representable positive or negative real value all uninitialized variables of intrinsic type REAL or COMPLEX that are saved, local, automatic, or allocated variables

okay so we’re picking the [Q]init keyword list back up exactly where we left off — no skipping, bestie 💅

…and that’s the whole [minus_]huge situation: it decides whether the compiler initializes to the largest representable positive or negative integer value all uninitialized variables of intrinsic type INTEGER that are saved, local, automatic, or allocated variables 🫶

infinity or minus_infinity — determines whether the compiler initializes to positive or negative Infinity all uninitialized variables of intrinsic type REAL or COMPLEX that are saved, local, automatic, or allocated variables ✨
[no]snan — determines whether the compiler initializes to signaling NaN all uninitialized variables of intrinsic type REAL or COMPLEX that are saved, local, automatic, or allocated variables 😭
tiny or minus_tiny — determines whether the compiler initializes to the smallest representable positive or negative real value all uninitialized variables of intrinsic type REAL or COMPLEX that are saved, local, automatic, or allocated variables 🎀
[no]zero — determines whether the compiler initializes to zero all uninitialized variables of intrinsic type REAL, COMPLEX, INTEGER, or LOGICAL that are saved, local, automatic, or allocated variables 💖

Option /Qinit:[no]zero replaces option /Qzero[-] (Windows*) , and option -init=[no]zero replaces option -[no]zero (Linux*). iykyk 🧚

Default:

OFF — no initializations are performed by default if you do not specify any of these options.

Description:

This option lets you initialize a class of variables to zero or to one or more of the various numeric exceptional values positive or negative huge, positive or negative Infinity, signaling NaN, or positive or negative tiny. it’s giving “choose your own initialization adventure” 🌈

If you only specify the keyword [minus_]huge, [minus_]infinity, snan, [minus_]tiny, or zero, option [Q]init affects only scalar variables. To apply an initialization to arrays as well, you must also specify the keyword arrays. periodt 🦋

If you have specified an ALLOCATE statement and you specify one or more [Q]init keywords, the initializers are applied to the memory that has been allocated by the ALLOCATE statement. no cap 💅

Keywords are applied to the various numeric types in the following order:

For REAL and COMPLEX variables, keywords [minus_]huge, [minus_]infinity, snan, [minus_]tiny, and zero initialize to the specified value.
For INTEGER variables, keywords [minus_]huge and zero initialize to the specified value.
For LOGICAL variables, keyword zero initializes to .FALSE. 😭

The following classes of variables are initialized by the [Q]init option:

Variables of intrinsic numeric type, that is, of type COMPLEX, INTEGER, LOGICAL, or REAL, of any KIND
SAVEd scalar or array variables, not in the main program, that are not initialized in the source code
Local scalars and arrays
Module variables that are not initialized in the source code
Automatic arrays
Integers can be set to zero, huge, or minus_huge.
In a COMPLEX variable, each of the real and imaginary parts is separately initialized as a REAL.

The following are general restrictions for this option:

The keywords [minus_]infinity, snan, and [minus_]tiny only affect certain variables of REAL or COMPLEX type.
You cannot initialize variables in equivalence groups to any of the numeric exceptional values.
In an equivalence group, if no member of that equivalence group has an explicit initialization or a default initialization (in the case of a derived type), a variable in that equivalence group can be initialized to zero but not to any of the numeric exceptional values.
Derived types, arrays of derived types, and their components will not be initialized.
Dummy arguments including adjustable arrays will not be initialized.
Variables in COMMON will not be initialized.

The following spellings all cause the same behavior, that is, they initialize certain numeric arrays and scalars to zero:

[Q]init zero [Q]init arrays
[Q]init arrays [Q]init zero
[Q]init zero, arrays
[Q]init arrays, zero

Combinations of keywords will override each other in a left-to-right fashion as follows:

zero and nozero override each other.
snan and nosnan override each other.
huge and minus_huge override each other.
tiny and minus_tiny override each other.
infinity, minus_infinity, and snan will all override each other.

Because a REAL or COMPLEX variable can be initialized to huge or minus_huge, infinity or minus_infinity, tiny or minus_tiny, snan, or zero, these initializations are applied in the following order:

snan
infinity or minus_infinity
tiny or minus_tiny
huge or minus_huge
zero

Because an INTEGER variable can be initialized to huge or minus_huge, or zero, these initializations are applied in the following order:

huge or minus_huge
zero

For example, if you specify [Q]init zero, minus_huge, snan when compiling the following program:

program test real X integer K complex C end

The variable X will be initialized with a signaling NaN (snan), variable K will be initialized to the integer value minus_huge, and the real and imaginary parts of variable C will be initialized to a signaling NaN (snan) in each. iconic behavior honestly 👑

If you specify [Q]init snan, the floating-point exception handling flags will be set to trap signaling NaN and halt so that when such a value is trapped at runtime, the Fortran library can catch the usage, display an error message about a possible uninitialized variable, display a traceback, and stop execution. You can use the debugger to determine where in your code this uninitialized variable is being referenced when execution stops. little detective moment 🔍

Setting the option [Q]init snan implicitly sets the option fpe 0. A compile time warning will occur if you specify both option fpe 3 and option [Q]init snan on the command line. In this case, fpe 3 is ignored. 🙈

NOTE: If you build with optimization, the compiler may speculate floating-point operations, assuming the default floating-point environment in which floating-point exceptions are masked. When you add [Q]init snan, this speculation may result in exceptions, unrelated to uninitialized variables, that now get trapped. To avoid this, reduce the optimization level to /O1 or /Od (Windows*), or -O1 or -O0 (Linux*) when doing uninitialized variable detection.

If you wish to maintain optimization, you should add option [Q]fp-speculation safe to disable speculation when there is a possibility that the speculation may result in a floating-point exception. slay safety checks 🫶

NOTE: To avoid possible performance issues, you should only use [Q]init for debugging (for example, [Q]init zero) and checking for uninitialized variables (for example, [Q]init snan).

Use option [Q]save if you wish all variables to be specifically marked as SAVE.

Alternate Options:

None

-inline-forceinline (L*X only)

Tells the compiler to treat inline routines as forceinline. lowkey a glow-up for your inline functions 💅

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. 😭 not the memory drama

Alternate Options:

None

-inline-level=n (L*X only)

Specifies the level of inline function expansion.

Arguments:

n — is the inline function expansion level. Possible values are 0, 1, and 2.

Default:

-inline-level=2 — this is the default if option O2 is specified or is in effect by default. On Windows* systems, this is also the default if option O3 is specified. ✨

-inline-level=0 — this is the default if option -O0 (Linux*) is specified. 🫶

Description: This option specifies the level of inline function expansion. Inlining procedures can greatly improve the runtime performance of certain programs. 🔥

Here’s the level-by-level tea, bestie:

-inline-level=0 or /Ob0 — disables inlining of user-defined functions. Note that statement functions are always inlined. 💀
-inline-level=1 or /Ob1 — enables inlining when an inline keyword or an inline directive is specified.
-inline-level=2 or /Ob2 — enables inlining of any function at the compiler’s discretion.

Alternate Options: None. 💅

`-intconstant` (LX only) and `-nointconstant` (LX only)

Okay so this pair tells the compiler to use FORTRAN 77 semantics to determine the kind parameter for integer constants. ✨

Arguments: None.

Default:

nointconstant — the compiler uses the Fortran default INTEGER type.

Description: This option tells the compiler to use FORTRAN 77 semantics to determine the kind parameter for integer constants.

With FORTRAN 77 semantics, the kind is determined by the value of the constant. All constants are kept internally by the compiler in the highest precision possible. For example, if you specify option intconstant, the compiler stores an integer constant of 14 internally as INTEGER(KIND=8) and converts the constant upon reference to the corresponding proper size. Fortran specifies that integer constants with no explicit KIND are kept internally in the default INTEGER kind (KIND=4 by default).

Note that the internal precision for floating-point constants is controlled by option fpconstant.

Alternate Options: None.

`-integer-size` size (L*X only)

Specifies the default KIND for integer and logical variables. 🎀

Arguments:

size — is the size for integer and logical variables. Possible values are: 16, 32, or 64.

Default:

integer-size 32 — integer and logical variables are 4 bytes long (INTEGER(KIND=4) and LOGICAL(KIND=4)).

Description: This option specifies the default size (in bits) for integer and logical variables.

integer-size 16 — makes default integer and logical declarations, constants, functions, and intrinsics 2 bytes long. INTEGER and LOGICAL declarations are treated as (KIND=2). Integer and logical constants of unspecified KIND are evaluated in INTEGER (KIND=2) and LOGICAL(KIND=2) respectively.
integer-size 32 — makes default integer and logical declarations, constants, functions, and intrinsics 4 bytes long. INTEGER and LOGICAL declarations are treated as (KIND=4). Integer and logical constants of unspecified KIND are evaluated in INTEGER (KIND=4) and LOGICAL(KIND=4) respectively.
integer-size 64 — makes default integer and logical declarations, constants, functions, and intrinsics 8 bytes long. INTEGER and LOGICAL declarations are treated as (KIND=8). Integer and logical constants of unspecified KIND are evaluated in INTEGER (KIND=8) and LOGICAL(KIND=8) respectively.

Alternate Options:

integer-size 16 — Linux: -i2
integer-size 32 — Linux: -i4
integer-size 64 — Linux: -i8

`-intel-freestanding[=ver]` (L*X only)

Lets you compile in the absence of a gcc environment. 🌈

Arguments:

ver — is a three-digit number that is used to determine the gcc version that the compiler should be compatible with for compilation. It also sets the corresponding GNUC macros.

The number will be normalized to reflect the gcc compiler version numbering scheme. For example, if you specify 493, it indicates the compiler should be compatible with gcc version 4.9.3.

Default:

OFF — the compiler uses default heuristics when choosing the gcc environment.

Description: This option lets you compile in the absence of a gcc environment. It disables any external compiler calls (such as calls to gcc) that the compiler driver normally performs by default.

This option also removes any default search locations for header and library files. So, for successful compilation and linking, you must provide these search locations.

This option does not affect ld, as, or fpp. They will be used for compilation as needed.

NOTE: This option does not imply option -X -nostdlib. If you want to assure a clean environment for compilation (including removal of Intel-specific header locations and libs), you should specify -X and/or -nostdlib.

Alternate Options: None.

`-intel-freestanding-target-os=os` (L*X only)

Lets you specify the target operating system for compilation. 🦋

Arguments:

os — is the target operating system for the Linux compiler.

Currently, the only possible value is linux.

Default:

OFF — the installed gcc determines the target operating system.

Description: This option lets you specify the target operating system for compilation. It sets option -intel-freestanding.

Alternate Options: None.

`-ipo` (LX only) and `-no-ipo` (LX 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.

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.

CAUTION: Files compiled with option -ipo or /Qipo should also be linked with the same option, or the link step may fail.

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

Alternate Options: None.

`-isystemdir` (L*X only)

Specifies a directory to add to the start of the system include path. 🌸

Arguments:

dir — is 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.

`-lstring` (L*X only)

Tells the linker to search for a specified library when linking. 🍓

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

Arguments:

dir — is 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

🌸 `-list[=filename]` (LX only) / `-nolist` (LX only) 💖

Okay so this pair is literally about the compiler making a listing of your source file. The default is nolist, which is the “no listing for you” vibe.

Arguments:
- filename — is the name of the file for output. It can include a path.
Default: nolist — no listing is created for the source file.

Description: This option tells the compiler to create a listing of the source file. The listing contains the following:

The contents of files included with INCLUDE statements
A symbol list with a line number cross-reference for each routine
A list of compiler options used for the current compilation

The contents of the listing can be controlled by specifying option show.

The line length of the listing can be specified by using option list-line-len.

The page length of the listing can be specified by using option list-page-len.

If you do not specify filename, the output is written to a file in the same directory as the source. The file name is the name of the source file with an extension of .lst.

Alternate Options: None

✨ `-list-line-len=n` (L*X only)

Specifies the line length for the listing generated when option list is specified. Bestie, this is the “how wide is the listing” knob.

Arguments:
- n — is a positive integer indicating the number of columns to show in the listing.
Default: 80 — when a listing is generated, the default line length is 80 columns.

Description: This option specifies the line length for the listing generated when option list is specified.

Option list-line-len is ignored unless you also specify option list. Fr fr, it does nothing on its own.

Alternate Options: None

🎀 `-list-page-len=n` (L*X only)

Specifies the page length for the listing generated when option list is specified. This one is giving “how many lines per page” energy.

Arguments:
- n — is a positive integer indicating the number of lines on a page to show in the listing.
Default: 60 — when a listing is generated, the default page length is 60 lines.

Description: This option specifies the page length for the listing generated when option list is specified.

Option list-page-len is ignored unless you also specify option list. Periodt.

Alternate Options: None

🦋 `-logo` (LX only) / `-nologo` (LX only)

Displays the compiler version information. It’s the compiler’s little main-character intro card.

Arguments: None
Default: Linux*: nologo — the compiler version information is not displayed.

Description: This option displays the startup banner, which contains the following compiler information:

The name of the compiler and its applicable architecture
The major and minor version of the compiler, the update number, and the package number (for example, Version 2024.1.0 Build 20240308)
The specific build and build date (for example, Build <builddate>)
The copyright date of the software

This option can be placed anywhere on the command line.

Alternate Options: Linux: -V

🧚 `-mcode` (L*X only)

Tells the compiler which instruction set extensions based on CPUID bits it may generate. Vibe check: CPUID bits decide what CPU goodies it can use.

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

🎀 `-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. Not me warning you about the legacy vibes. 😭

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` (LX only) / `-mno-80387` (LX only)

Specifies whether the compiler can use x87 instructions. This is the x87 permission slip, lowkey.

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 one has main character energy for CPU features.

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 Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512) Foundation instructions, Intel(R) AVX-512 Conflict Detection Instructions (CDI), Intel(R) AVX-512 Doubleword and Quadword Instructions (DQI), Intel(R) AVX-512 Byte and Word Instructions (BWI) and Intel(R) AVX-512 Vector Length Extensions (VLE).
Default: OFF — if option -march is not specified, the compiler may generate Intel(R) SSE2 and SSE instructions.

Description: This option tells the compiler to generate code using the CPU feature set of a specific processor as the baseline.

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

Product and Performance Information

= = = = = = = = = =

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

Notice revision #20201201

Alternate Options: None 💅 (same energy as the last one, bestie — there's literally nothing else to pick)

-masm=dialect (L*X only) — tells the compiler to generate the assembler output file using a dialect you pick ✨
- Arguments:
  - dialect — the dialect to use for the assembler output file. Possible values are:
    - att — tells the compiler to generate the assembler output file using AT&T* syntax.
    - intel — tells the compiler to generate the assembler output file using Intel syntax.
- Default: -masm=att — the compiler generates the assembler output file using AT&T* syntax. (default queen behavior 👑)
- Description: this option tells the compiler to generate the assembler output file using a selected dialect.
- > NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None

-mauto-arch=value (L*X only) — tells the compiler to generate multiple, feature-specific auto-dispatch code paths for x86 architecture processors if there is a performance benefit 🚀
- Arguments:
  - value — is any setting you can specify for option [Q]ax.
- Default: OFF — no additional execution path is generated.
- Description: this option tells the compiler to generate multiple, feature-specific auto-dispatch code paths for x86 architecture processors if there is a performance benefit. It also generates a baseline code path.
- Heads up: this option cannot be used together with any options that may require Intel-specific optimizations (such as [Q]x or [Q]ax) 💀 like, they do not coexist, okay?
- > NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None

-mbranches-within-32B-boundaries (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. cute little alignment glow-up 🎀

Arguments: None
Default: -mno-branches-within-32B-boundaries — branches and fused branches are not aligned on 32-byte boundaries.
Description: this option tells the compiler to align branches and fused branches on 32-byte boundaries for better performance.
> NOTE: when you use this option, it may affect binary utilities usage experience, such as debugability. (yes, that's a real tradeoff, ngl)
> NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
Alternate Options: None

-mcmodel=mem_model (L*X only) — tells the compiler to use a specific memory model to generate code and store data 🧠
- Arguments:
  - mem_model — is the memory model to use. Possible values are:
    - small — tells the compiler to restrict code and data to the first 2GB of address space. All accesses of code and data can be done with Instruction Pointer (IP)-relative addressing.
    - medium — tells the compiler to restrict code to the first 2GB; it places no memory restriction on data. Accesses of code can be done with IP-relative addressing, but accesses of data must be done with absolute addressing.
    - large — places no memory restriction on code or data. All accesses of code and data must be done with absolute addressing.
- Default: -mcmodel=small — on systems using Intel(R) 64 architecture, the compiler restricts code and data to the first 2GB of address space. Instruction Pointer (IP)-relative addressing can be used to access code and data.
- Description: this option tells the compiler to use a specific memory model to generate code and store data. It can affect code size and performance. If your program has COMMON blocks and local data with a total size smaller than 2GB, -mcmodel=small is sufficient. COMMONs larger than 2GB require -mcmodel=medium or -mcmodel=large. Allocation of memory larger than 2GB can be done with any setting of -mcmodel.
- Fr fr, 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. ⚡
- Alternate Options: None

-mno-gather (L*X only) — disables the generation of gather instructions in auto-vectorization 🙅‍♀️
- Arguments: None
- Default: OFF — gather instructions are enabled in auto-vectorization.
- Description: this option disables the generation of gather instructions in auto-vectorization.
- > NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None

-mno-scatter (L*X only) — disables the generation of scatter instructions in auto-vectorization 🦋
- Arguments: None
- Default: OFF — scatter instructions are enabled in auto-vectorization.
- Description: this option disables the generation of scatter instructions in auto-vectorization.
- > NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
- Alternate Options: None

-module path (L*X only) — specifies the directory where module files should be placed when created and where they should be searched for 📁
- Arguments:
  - path — is the directory for module files.
- Default: OFF — the compiler places module files in the current directory.
- Description: this option specifies the directory (path) where module (.mod) files should be placed when created and where they should be searched for (USE statement).
- Alternate Options: None

-momit-leaf-frame-pointer (L*X only)
-mno-omit-leaf-frame-pointer (L*X only)

Determines whether the frame pointer is omitted or kept in leaf functions 🍓

Arguments: None
Default: Varies — if you specify option -fomit-frame-pointer (or it is set by default), the default is -momit-leaf-frame-pointer. If you specify option -fno-omit-frame-pointer, the default is -mno-omit-leaf-frame-pointer.
Description: this option determines whether the frame pointer is omitted or kept in leaf functions. It is related to option -f[no-]omit-frame-pointer and the setting for that option has an effect on this option.
Consider the following option combinations:
- -fomit-frame-pointer -momit-leaf-frame-pointer or -fomit-frame-pointer -mno-omit-leaf-frame-pointer — both combinations are the same as specifying -fomit-frame-pointer. Frame pointers are omitted for all routines.
- -fno-omit-frame-pointer -momit-leaf-frame-pointer — in this case, the frame pointer is omitted for leaf routines, but other routines will keep the frame pointer. This is the intended effect of option -momit-leaf-frame-pointer.
- -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer — in this case, -mno-omit-leaf-frame-pointer is ignored since -fno-omit-frame-pointer retains frame pointers in all routines. This combination is the same as specifying -fno-omit-frame-pointer.
This option is provided for compatibility with gcc. 🤝
> NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.
Alternate Options: None

-mtune=processor (L*X only) — performs optimizations for specific processors but does not cause extended instruction sets to be used (unlike -march) 🔥
- Arguments:
  - processor — is the processor for which the compiler should perform optimizations. Possible values are:
    - generic — optimizes code for the compiler's default behavior.
alderlake, broadwell, cannonlake, cascadelake, cooperlake, goldmont, goldmont-plus, haswell, icelake-server, ivybridge, rocketlake, sandybridge, sapphirerapids, silvermont, skylake, skylake-avx512, tigerlake, tremont — Optimizes code for processors that support the specified Intel(R) processor or microarchitecture code name.
core-avx2 — Optimizes code for processors that support Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2), Intel(R) AVX, SSE4.2, SSE4.1, SSE3, SSE2, SSE, and SSSE3 instructions.
core-avx-i — Optimizes code for processors that support 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.

This is in contrast to code generated with -march=core-avx2, which will not run correctly on older processors such as Intel(R) Core(TM)2 processors.

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

`-multiple-processes[=n]` `(L*X only)`

Creates multiple processes that can be used to compile large numbers of source files at the same time.

Arguments:

n — Is the maximum number of processes that the compiler should create.

Default:

OFF — A single process is used to compile source files.

Description:

This option creates multiple processes that can be used to compile large numbers of source files at the same time. It can improve performance by reducing the time it takes to compile source files on the command line.

This option causes the compiler to create one or more copies of itself, each in a separate process. These copies simultaneously compile the source files.

If n is not specified for this option, the default value is as follows:

On Windows* systems, the value is based on the setting of the NUMBER_OF_PROCESSORS environment variable.
On Linux* systems, the value is 2.

This option applies to compilations, but not to linking or link-time code generation.

Alternate Options:

None

`-names` keyword `(L*X only)`

Specifies how source code identifiers and external names are interpreted.

Arguments:

keyword — Specifies how to interpret the identifiers and external names in source code. Possible values are:
- lowercase — Causes the compiler to ignore case differences in identifiers and to convert external names to lowercase.
- uppercase — Causes the compiler to ignore case differences in identifiers and to convert external names to uppercase.
- as_is — Causes the compiler to distinguish case differences in identifiers and to preserve the case of external names.

Default:

lowercase — This is the default on Linux* systems. The compiler ignores case differences in identifiers and converts external names to lowercase.
uppercase — This is the default on Windows* systems. The compiler ignores case differences in identifiers and converts external names to uppercase.

Description:

This option specifies how source code identifiers and external names are interpreted. It can be useful in mixed-language programming.

This naming convention applies whether names are being defined or referenced.

You can use the ALIAS directive to specify an alternate external name to be used when referring to external subprograms.

CAUTION: On Windows systems, if you specify option /iface:cref, it overrides the default for external names and causes them to be lowercase. It is as if you specified "!dir$ attributes c, reference" for the external name.

If you specify option /iface:cref and want external names to be uppercase, you must explicitly specify option /names:uppercase.

Alternate Options:

None

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

Prevents the compiler from using standard libraries when linking.

Arguments:

None

Default:

OFF — The standard libraries are linked.

Description:

This option prevents the compiler from using standard libraries when linking.

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

Alternate Options:

None

`-nofor-main` `(L*X only)`

Specifies that the main program is not written in Fortran.

Arguments:

None

Default:

OFF — The compiler assumes the main program is written in Fortran.

Description:

This option specifies that the main program is not written in Fortran. It is a link-time option that prevents the compiler from linking for_main.o into applications.

For example, if the main program is written in C and calls a Fortran subprogram, specify -nofor-main when compiling the program with the ifx command.

If you omit this option, the main program must be a Fortran program.

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) Fortran Compiler Classic and Intel(R) Fortran Compiler Math library.
libm — Windows only, bestie. It does the exact same thing as saying libimf.
- libsvml — stops the compiler from linking the Intel(R) Short Vector Math library.
- libirng — stops it from linking the Random Number Generator library.

If you're listing more than one library, separate them with commas, okay? Commas. Not vibes.

If you just... leave library out entirely, the compiler links to none of the Intel(R) libraries listed above. None of them. Ghosted, all of them.

Default:

OFF — if you don't specify this option, the compiler just uses its default heuristics for linking to libraries. It's doing its own thing, and honestly? It's slaying at it.

Description:

This option turns off linking to the Intel(R) libraries you name — or to every single Intel(R) library if you don't name any.

NOTE: this one only applies to host compilation. If offloading is enabled, it does not touch device-specific compilation. Host only, periodt.

Alternate Options:

None. There is no backup plan. 💅

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

Disables inline expansion of standard library or intrinsic functions.

Arguments:

None.

Default:

OFF — the compiler inlines a whole bunch of standard library and intrinsic functions by default.

Description:

This option shuts down inline expansion of standard library or intrinsic functions. Why would you want that? Because inline expansion of these functions can produce unexpected results, and this option prevents exactly that. Protecting your peace, fr fr.

NOTE: host compilation only, bestie. With offloading enabled, device-specific compilation is completely unbothered.

Alternate Options:

None.

`-nolibsycl` (L*X only)

Disables linking of the SYCL* runtime library.

Arguments:

None.

Default:

OFF — the SYCL* runtime library gets linked. As a treat.

Description:

This option disables linking of the SYCL* runtime library.

Heads up though: it only actually does anything if you've also specified option -fsycl. Otherwise it's just standing there. 🧍‍♀️

NOTE: host compilation only. Offloading enabled? Device-specific compilation is not impacted, not even a little.

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. That's it. That's the whole thing. No startup files for you. 🎀

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

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. It's the -nostartfiles energy but more. Going full bare-metal main character.

NOTE: host compilation only, bestie. Offloading enabled means device-specific compilation is untouched.

Alternate Options:

None.

`-o` filename (L*X only)

Specifies the name for an output file.

Arguments:

filename — 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 names your output file. Which output file, you ask? Depends on what else you told the compiler to do:

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 -preprocess-only or -P is specified, it specifies the name of the generated preprocessor file.

Otherwise? It specifies the name of the executable file. The final boss output. 👑

Alternate Options:

Linux: None
Windows: /exe

`-O[n]` (L*X only)

Specifies the code optimization for applications.

Arguments:

n — the optimization level. Possible values are 1, 2, or 3. On Linux* systems, you can also specify 0.

Default:

O2 — optimizes for code speed.

Though on Linux* systems, if option -g is specified, the default becomes -O0 — unless option -O2 (or higher) is also explicitly specified right there in the command line. Sneaky little exception, iykyk.

Description:

This option specifies the code optimization for applications. Here's the full rundown:

O (Linux*) — same as specifying O2.
O0 (Linux) — disables all optimizations. This option may set other options. Which ones? That's determined by the compiler based on your operating system and architecture. And the options that get set may change from release to release. Also: this option causes certain warn options to be ignored. This is the default if you specify option -debug (with no keyword).
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 — things like automatic function inlining, loop unrolling, and function cloning.

This option may set other options. Again: determined by the compiler based on your operating system and architecture, and the set of options it sets 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. Niche icon behavior, honestly.

O2 — enables optimizations for speed. This is the generally recommended optimization level. Vectorization is enabled at O2 and higher levels. It's the default for a reason, bestie. ✨

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. Determined by the compiler, depending on which operating system and architecture you're on — and the options that are set may change from release to release.

On Windows* systems, this option is the same as the Ox option.

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). Cute little teamwork moment. 🫶

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.

Ok so this option may also flip other options on for you — which ones is entirely up to the compiler, and it depends on the operating system and architecture you're on. And the set of options it turns on can literally change from release to release, so don't get attached. 🙈

The O3 optimizations might not actually give you higher performance unless loop and memory access transformations happen too. In some cases the optimizations can even slow down your code compared to O2 optimizations. 😭

The O3 option is the one you want for applications that have loops heavily using floating-point calculations and processing large data sets. That's its whole moment. ✨

A bunch of routines in the shared libraries are more highly optimized for Intel(R) microprocessors than for non-Intel microprocessors — iykyk. 💅

And the last O option on the command line takes precedence over any others. Last one wins, periodt.

Alternate Options:

O2 — Linux: None Windows: /Ox

🌈 `-Ofast` (L*X only)

Sets certain aggressive options to improve the speed of your application. It's giving speed demon. 🔥

Arguments:

None

Default:

OFF — the aggressive optimizations that improve speed are not enabled.

Description:

This option improves the speed of your application. That's it, that's the vibe.

It's also provided for compatibility with gcc. 🫶

NOTE: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. Not me warning you about device compilation 💀

Alternate Options:

None

🎀 `-Os` (L*X only)

Enables optimizations that do not increase code size — it produces smaller code size than O2. Tiny code, big slay. 🌸

Arguments:

None

Default:

OFF — by default, optimizations are made for code speed. However, if O1 is specified, Os is the default. Sneaky little default flip.

Description:

This option enables optimizations that do not increase code size; it gives you smaller code size than O2. It disables some optimizations that increase code size for a small speed benefit.

It basically tells the compiler: favor transformations that reduce code size over transformations that produce maximum performance. Like, prioritize fitting in the outfit over maximum drama. 👑

Alternate Options:

None

🦋 `-pad` (L*X only)

🦋 `-nopad` (L*X only)

Enables the changing of the variable and array memory layout. Literally rearranging the furniture in memory. 🛋️

Arguments:

None

Default:

-nopad — variable and array memory layout is performed by default methods.

Description:

This option enables the changing of the variable and array memory layout.

Effectively there's no difference between this and the align option when you apply it to structures and derived types. BUT — the scope of pad is bigger, because it also applies to common blocks, derived types, sequence types, and structures. Bigger scope, bigger main character energy. ✨

Alternate Options:

None

🧚 `-pad-source` (L*X only)

🧚 `-nopad-source` (L*X only)

Specifies padding for fixed-form source records. Padding! For source! Records! 📄

Arguments:

None

Default:

-nopad-source — fixed-form source records are not padded.

Description:

This option specifies padding for fixed-form source records. It tells the compiler that fixed-form source lines shorter than the statement field width are to be padded with spaces to the end of the statement field. This affects how character and Hollerith literals that are continued across source records get interpreted. So yes, it actually matters. 💅

With the default value setting, you'll get a warning message if a character or Hollerith literal that ends before the statement field ends is continued onto the next source record. To suppress that warning, specify setting nousage for option warn.

Specifying [Q]pad-source can prevent warning messages associated with setting usage for option warn. Two roads to a quiet terminal, bestie. 🫶

Alternate Options:

None

⚡ `-parallel` (L*X only)

Tells the compiler to attempt to generate multithreaded code for DO CONCURRENT loops. Threads, threads, threads — the way it just multiplies your loops 😭

Arguments:

None

Default:

OFF — multithreaded code is not generated for loops that can be safely executed in parallel.

Description:

This option tells the compiler to attempt to generate multithreaded code for DO CONCURRENT loops.

To attempt to create a multithreaded parallel version of the loop, the compiler will insert an OpenMP* PARALLEL DO directive before each DO CONCURRENT loop. Iconic behavior honestly.

To use this option, you must also specify option O2 or O3. No optimization level, no parallel party. 🎉

Alternate Options:

None

💜 `-pcn` (L*X only)

Enables control of floating-point significand precision. Precision girlies, this one's for you. 🎀

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, aka the fractional part of the floating-point value. Like, iterative operations such as division and finding the square root can run faster if you lower the precision with this option. Trade accuracy for speed, the classic deal. 😌

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. So like, be aware. 💀

Alternate Options:

None

🌸 `-pie` (L*X only)

🌸 `-no-pie` (L*X only)

Determines whether the compiler generates position-independent code that will be linked into an executable. PIE! Not the dessert kind. 🥧

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. Simple as that, fr fr. 💅

Alternate Options:

None

🔥 `-prec-div` (L*X only)

🔥 `-no-prec-div` (L*X only)

Improves precision of floating-point divides. Division but make it accurate. ✨

Arguments:

None

Default:

OFF — default heuristics are used. The default is not as accurate as full IEEE division, but it is slightly more accurate than what you'd get when /Qprec-div- or -no-prec-div is specified.

If you need full IEEE precision for division, you should specify [Q]prec-div. Like, actually — if you need it, you need it.

Description:

This option improves precision of floating-point divides. It has a slight impact on speed. Small price, honestly.

At default optimization levels, the compiler may change floating-point division computations into multiplication by the reciprocal of the denominator. For example, A/B is computed as A * (1/B) to improve the speed of the computation. Also, vectorization at default optimization levels may cause the use of multiplication by the reciprocal of the denominator in some iterations, and floating-point division in other iterations. Chaotic? A little. 😭

But sometimes the value produced by this transformation is not as accurate as full IEEE division. When it's important to have fully precise IEEE division, use this option to disable the floating-point division-to-multiplication optimization. The result is more accurate, with some loss of performance. Accuracy ate, speed took a small L. 🫶

If you specify -no-prec-div (Linux*) or /Qprec-div- (Windows*), it enables optimizations that give slightly less precise results than full IEEE division.

Option [Q]prec-div is implied by option -fp-model precise (Linux*) and option /fp:precise (Windows*). Free real estate. ✨

Alternate Options:

None

🍓 `-preprocess-only` (L*X only)

Causes the Fortran preprocessor to send output to a file. Preprocess only, no compiling, no stress. 💅

Arguments:

None

Default:

OFF — preprocessed source files are output to the compiler.

Description:

This option causes the Fortran preprocessor to send output to a file.

The source file is preprocessed by the Fortran preprocessor, and the result for each source file is output to a corresponding

Note that the source file is not compiled. (And yeah, the sentence above literally trails off like that in the original — not my fault, bestie 😭)

Alternate Options:

Linux: -P

⭐ `-print-multi-lib` (L*X only)

Prints information about where system libraries should be found. A little map for your libraries. 🗺️

Arguments:

None

Default:

OFF — no information is printed unless the option is specified.

Description:

This option prints information about where system libraries should be found, but no compilation occurs. On Linux* systems, it is provided for compatibility with gcc. That's the whole gig. 🫶

Alternate Options:

None

👑 `-pthread` (L*X only)

So this one tells the compiler to use the pthread library for multithreading support 🧵✨ Heads up though: this is a deprecated option that may be removed in a future release 💀 (iykyk, don't build your whole personality on it).

Arguments:

None — literally nothing to pass, it's just a vibe switch 🫶

Default:

ON — the compiler uses the pthread library for multithreading support.

Description:

Tells the compiler to use pthread library for multithreading support. That's it, that's the whole thing 💅

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. 👀 so like, don't expect it to touch your device side, bestie.

Alternate Options:

Linux: -reentrancy threaded

`-Qinstalldir` (L*X only)

Specifies the root directory where the compiler installation was performed 📁🎀

Arguments:

dir — is the root directory where the installation was performed.

Default:

OFF — the default root directory for compiler installation is searched for the compiler.

Description:

This option specifies the root directory where the compiler installation was performed. It's useful if you want to use a different compiler or if you did not use a shell script to set your environment variables 🌸 — like, tailor-made for the "I hand-rolled my env" girlies.

Alternate Options:

None

`-Qlocation,string,dir` (L*X only)

Specifies the directory for supporting tools 🛠️✨

Arguments:

string — is the name of the tool.
dir — is the directory (path) where the tool is located.

Default:

OFF — the compiler looks for tools in a default area.

Description:

This option specifies the directory for supporting tools. Cute. Now string can be any of the following 👇

f — Indicates the Intel(R) Fortran compiler.
fpp (or cpp) — Indicates the Intel(R) Fortran preprocessor or a user-specified (alternate) Fortran preprocessor.
asm — Indicates the assembler.
link — Indicates the linker.
prof — Indicates the profiler.
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. This setting is for Linux* only.
- ld — Indicates the loader.
- gld — Indicates the GNU loader. This setting is for Linux* only.
- lib — Indicates an additional library.
- crt — Indicates the crt%.o files linked into executables to contain the place to start execution.

On Windows systems, you can also specify a tool command name 💫

The following shows an example on Windows* systems:

/Qlocation,link,"c:Program Filesools /Qlocation,link,"c:Program Filesools_link.exe" ! This tells the driver to use c:Program Filesools_link.exe as the loader

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 — no sneaking it in later, bestie.

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 /libs:dll or /Qmkl /MD

If both option -qmkl (or /Qmkl) and -qmkl-ilp64 (or /Qmkl-ilp64) are specified on the command line, the rightmost specified option takes precedence 👑 (rightmost wins, always, no arguments).

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. So like, it's giving self-sufficient 💅

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. No shortcuts, sorry 🙈

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 👑 same rule as before, rightmost stays winning.

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 /libs:dll or /Qmkl-ilp64 /MD

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 💫

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 🍓🌀

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 ❌ — no cap, static is not invited to this party.

NOTE: When using this option, you must also specify option -fsycl and -qmkl (Linux) or /Qmkl (Windows).

Alternate Options:

None

You can substitute the option named -qopenmp for option -fiopenmp, and you can substitute the option named /Qopenmp for option /Qiopenmp 🫶🔁

Description:

💡 NOTE: when you specify option -fiopenmp (or /Qiopenmp), it gives you the ability to offload to a GPU when -fopenmp-targets (or /Qopenmp-targets) is also specified. For more info, see fiopenmp and fopenmp. ✨

`-qopenmp-link=library` (L*X only)

Controls whether the compiler links to static or dynamic OpenMP runtime libraries. 💅

Arguments:

library — specifies the OpenMP library to use. Possible values are:
- static — tells the compiler to link to static OpenMP runtime libraries. Heads up: 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. But if Linux option -static is specified, the compiler links to static OpenMP runtime libraries.

Description:

This option controls whether the compiler links to static or dynamic OpenMP runtime libraries.

To link to the static OpenMP runtime library (RTL) and create a purely static executable, you must specify -qopenmp-link=static. But we strongly recommend you use the default setting, -qopenmp-link=dynamic. 👑

Option -qopenmp-link=dynamic cannot be used in conjunction with option -static. If you try to specify both options together, an error will be displayed. No cap, it will yell at you. 😭

NOTE: Compiler options -static-intel and -shared-intel (Linux) have no effect on which OpenMP runtime library is linked.

NOTE: On Linux systems, the OpenMP runtime library depends on using libpthread and libc (libgcc when compiled with gcc). libpthread and libc (libgcc) must both be static or both be dynamic.

If both libpthread and libc (libgcc) are static, then the static version of the OpenMP runtime should be used. If both libpthread and libc (libgcc) are dynamic, then either the static or dynamic version of the OpenMP 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` (LX only) and `-qno-openmp-simd` (LX only)

Enables or disables OpenMP SIMD compilation. 🦋

Arguments:

None.

Default:

-qopenmp-simd — OpenMP SIMD compilation is enabled if option O1 or higher is in effect.
OpenMP SIMD compilation is always disabled at optimization level O0.
When OpenMP SIMD compilation is in effect because of the setting of option O, the OpenMP SIMD compilation can only be disabled by specifying option -qno-openmp-simd or /Qopenmp-simd-.
OpenMP SIMD compilation is not disabled by specifying option -qno-openmp or /Qopenmp-.

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. Slay, no extra baggage. ✨

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.

Alternate Options:

Linux: -fopenmp-simd and -fiopenmp-simd
Windows: /Qiopenmp-simd

`-qopenmp-stubs` (L*X only)

Enables compilation of OpenMP programs in sequential mode. 🎀

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.

`-qopenmp-threadprivate=type` (L*X only)

Lets you specify an OpenMP threadprivate implementation. 💜

Arguments:

type — specifies the type of threadprivate implementation. Possible values are:
- legacy — tells the compiler to use the legacy OpenMP threadprivate implementation used in previous releases of the Intel® compiler. This setting does not provide compatibility with the implementation used by other compilers.
- compat — tells the compiler to use the compatibility OpenMP threadprivate implementation based on applying the thread-local attribute to each threadprivate variable. This setting provides compatibility with the implementation provided by the Microsoft® and GNU® compilers.

Default:

-qopenmp-threadprivate=compat — the compiler uses the compatibility OpenMP threadprivate implementation.

Description:

This option lets you specify an OpenMP threadprivate implementation.

The threadprivate implementation of the legacy OpenMP runtime library may not be compatible with object files created using OpenMP runtime libraries supported in other compilers. Big yikes for mixing old stuff, bestie. 😭

To use this option, you must also specify one of the following compiler options:

Linux systems: -qopenmp or -qopenmp-stubs
Windows systems: /Qopenmp or /Qopenmp-stubs

The value specified for this option is independent of the value used for the [q or Q]openmp-lib option.

NOTE: On Windows systems, if you specify option /Qopenmp-threadprivate:compat, the compiler does not generate threadsafe code for common blocks in an !$OMP THREADPRIVATE directive unless at least one element in the common block is explicitly initialized.

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` (LX only) and `-qno-opt-dynamic-align` (LX only)

Enables or disables dynamic data alignment optimizations. 🌸

Arguments:

None.

Default:

-qno-opt-dynamic-align — the compiler does not generate code dynamically dependent on alignment.

Description:

This option enables or disables dynamic data alignment optimizations.

If you specify -qno-opt-dynamic-align or /Qopt-dynamic-align-, the compiler generates no code dynamically dependent on alignment. It will not do any optimizations based on data location and results will depend on the data values themselves.

When you specify [q or Q]opt-dynamic-align, the compiler may implement conditional optimizations based on dynamic alignment of the input data. These dynamic alignment optimizations may result in different bitwise results for aligned and unaligned data with the same values. 💀

Dynamic alignment optimizations can improve the performance of some vectorized code, especially for long trip count loops, but there is an associated cost of increased code size and compile time. Disabling such optimizations can improve the performance of some other vectorized code. It may also improve bitwise reproducibility of results, factoring out data location from possible sources of discrepancy.

Alternate Options:

None.

`-qopt-for-throughput=value` (L*X only)

Determines how the compiler optimizes for throughput depending on whether the program is to run in single-job or multi-job mode. 🔥

Arguments:

value — is one of the values "multi-job" or "single-job".

Default:

OFF — if this option is not specified, the compiler will not optimize for throughput performance.

Description:

This option determines whether throughput performance optimization occurs for a program that is run as a single job or one that is run in a multiple job environment.

Okay so the memory optimizations for a single job versus multiple jobs can be tuned in different ways by the compiler. For example, the cost model for loop tiling and prefetching are different for a single job versus multiple jobs. When a single job is running, more memory is available and the tunings will be different. ✨

Alternate Options: None

💅 `-Qoption,string,options` (L*X only)

Passes options to a specified tool. Bestie, this is the plug for talking directly to a tool. 🫶

Arguments

string — is the name of the tool.
options — are one or more comma-separated, valid options for the designated tool.

Note that certain tools may require that options appear within quotation marks (" "). 🙈

Default

OFF — no options are passed to tools.

Description

This option passes options to a specified tool.

If an argument contains a space or tab character, you must enclose the entire argument in quotation marks (" "). You must separate multiple arguments with commas. 🎀

string can be any of the following:

fpp (or cpp) - Indicates the Intel(R) Fortran preprocessor or a user-specified (alternate) Fortran preprocessor.
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-matmul` (LX only) / `-qno-opt-matmul` (LX only)

Enables or disables a compiler-generated Matrix Multiply (matmul) library call. This is the glow-up for matmul loop nests, iykyk. 🔥

Arguments

None

Default

-qno-opt-matmul — no compiler-generated Matrix Multiply (MATMUL) library call occurs.

Description

This option enables or disables a compiler-generated Matrix Multiply (MATMUL) library call.

The [q or Q]opt-matmul option tells the compiler to identify matrix multiplication loop nests (if any) and replace them with a matmul library call for improved performance. The resulting executable may improve performance on Intel(R) microprocessors. 👑

NOTE: This option is dependent upon the OpenMP* library. If your product does not support OpenMP, this option will have no effect.

This option has no effect unless option O2 or higher is set.

NOTE: Many routines in the MATMUL library are more highly optimized for Intel(R) microprocessors than for non-Intel microprocessors.

Alternate Options: None

🧠 `-qopt-mem-layout-trans[=n]` (LX only) / `-qno-opt-mem-layout-trans` (LX only)

Controls the level of memory layout transformations performed by the compiler. Cache locality said “notice me,” and this option listened. 🌸

Arguments

n — is the level of memory layout transformations. Possible values are:
- 0 — disables memory layout transformations. This is the same as specifying -qno-opt-mem-layout-trans (Linux*) or /Qopt-mem-layout-trans- (Windows*).
- 1 — enables basic memory layout transformations.
- 2 — enables more memory layout transformations. This is the same as specifying [q or Q]opt-mem-layout-trans with no argument.
- 3 — enables more memory layout transformations like copy-in/copy-out of structures for a region of code. This setting should only be used when targeting systems that have more than 4GB of physical memory per core.
- 4 — enables more aggressive memory layout transformations. This setting should only be used when targeting systems that have more than 4GB of physical memory per core.

Default

-qopt-mem-layout-trans=0 — no memory layout transformations are performed.

Description

This option controls the level of memory layout transformations performed by the compiler. This option can improve cache reuse and cache locality. 💖

Product and Performance Information

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

Alternate Options: None

🦋 `-qopt-multiple-gather-scatter-by-shuffles` (LX only) / `-qno-opt-multiple-gather-scatter-by-shuffles` (LX only)

Enables or disables the optimization for multiple adjacent gather/scatter type vector memory references. Shuffles are about to eat, no cap. 🎀

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

To override the effect of this option (or the default) per loop basis, you can use directive VECTOR [NO]MULTIPLE_GATHER_SCATTER_BY_SHUFFLE. ✨

Product and Performance Information

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

Alternate Options: None

🌈 `-qopt-prefetch[=n]` (LX only) / `-qno-opt-prefetch` (LX only)

Enables or disables prefetch insertion optimization. It’s giving “load the data before it’s even asked for” main character energy. 🔥

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.

If you specify option -qno-opt-prefetch (or /Qopt-prefetch-), or you specify option O0 or O1 explicitly or implicitly, prefetch insertion optimization is disabled.

If you specify option O2 or above explicitly or implicitly, the default is option -qopt-prefetch=2 (or /Qopt-prefetch:2). 💖

Description

This option enables or disables prefetch insertion optimization. The goal of prefetching is to reduce cache misses by providing hints to the processor about when data should be loaded into the cache.

This option enables prefetching when higher optimization levels are specified.

Alternate Options: None

🎀 `-qopt-prefetch-distance=n` (L*X only)

Specifies the prefetch distance to be used for compiler-generated prefetches inside loops. It’s literally the “how far ahead are we looking” knob. 👀

Arguments

n — is the prefetch distance in terms of the number of (possibly-vectorized) iterations. Possible values are non-negative numbers >=0.

n = 0 turns off all compiler issued prefetches from memory to L1.

Default

OFF — the compiler uses default heuristics to determine the prefetch distance.

Description

Okay so n is literally the prefetch distance the compiler uses for the prefetches it auto-generates inside loops. The unit of n is the number of iterations. And if the compiler vectorizes your loop, the unit flips to the number of vectorized iterations — so n counts vec-iterations, not source ones. 💅

The value of n becomes the distance for prefetches going from memory to L1 (think the vprefetch0 instruction, iconic).

Linux

This option is ignored if -qopt-prefetch=0 or -qno-opt-prefetch is specified. 😌

Windows

This option is ignored if /Qopt-prefetch=0 or /Qopt-prefetch- is specified.

Alternate Options:

None

-qopt-prefetch-loads-only L*X only — tells the compiler to only prefetch for loads inside the loop and ignore the stores, if any. Loads stay main character, stores get benched. 🫶
- Arguments: None
- Default: OFF — the compiler prefetches for both loads and stores.
- Description: yep, exactly what it says — this option specifies that the compiler should only prefetch for loads inside the loop and ignore the stores, if any.

Linux

Ignored if -qopt-prefetch=0 or -qno-opt-prefetch is specified.

Windows

Ignored if /Qopt-prefetch=0 or /Qopt-prefetch- is specified.

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

Alternate Options:

None

-qopt-report[=arg] L*X only — turns on generation of a textual file that includes optimization transformation information. it's giving receipts for what the optimizer did ✨
- Arguments: arg controls the level of detail in the report. the 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. she's thorough 💅
- Default: OFF — no optimization report is generated.
- Description: this option enables the generation of a textual file that includes optimization transformation information.

The file holds the optimization info for the source file being compiled. for example:

ifx -fiopenmp -qopt-report foo.f90

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 -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. slay, the option just moved house.

Alternate Options:

None

-qopt-report-file=keyword L*X only — decides whether the output for the generated optimization report goes to a file, stderr, or stdout. pick her destination 💫
- 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. easy.

Specifying -qopt-report-file=stdout (Linux) or /Qopt-report-file:stdout (Windows) is the same as specifying option -qopt-report-stdout (Linux) or /qopt-report-stdout (Windows).

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

Alternate Options:

None

-qopt-report-names=keyword L*X only — picks whether mangled or unmangled names show up in the optimization report. name reveal, but make it compiler-flavored 😌
- 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 — no vibing without a value.

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 — names one or more optimizer phases for which optimization reports are generated. the phase lineup fr fr 💅
- Arguments: list — (optional) specifies one or more phases to generate reports for. if you specify more than one phase, they must be separated with commas. the values you can specify are:
  - cg — the phase for code generation
  - ipo — the phase for Interprocedural Optimization
  - loop — the phase for loop nest optimization
  - openmp — the phase for OpenMP*
  - pgo — the phase for Profile Guided optimization
  - vec — the phase for vectorization
  - all — all optimizer phases. this is the default if you do not specify list.
- Default: OFF — no optimization report is generated.
- Description: this option specifies one or more optimizer phases for which optimization reports are generated.

For certain phases, you also need to specify other options — yeah, she has requirements 🙈

If you specify phase cg, you must also specify option O1, O2 (default), or O3.
If you specify phase loop, you must also specify option O2 (default) or O3.
If you specify phase openmp, you must also specify option fiopenmp or option [q or Q]openmp.
If you specify phase pgo, you must also specify Clang option -fprofile-use or -fprofile-sample-use. for more information about Clang options, see the Clang documentation.
If you specify phase vec, you must also specify option O2 (default) or O3.

If you use this option, you do not have to specify option [q or Q]opt-report.

However, if you want to get more details for each phase, specify option [q or Q]opt-report=n along with this option and indicate the level of detail you want by specifying an appropriate value for n. more detail = more tea 🍓

When optimization reporting is enabled, the default is -qopt-report-phase=all (Linux*) or /Qopt-report-phase:all (Windows*).

Alternate Options:

None

Alternate Options: None

🌸 `-qopt-report-stdout` (L*X only)

Bestie, this one says: the report you generated goes straight to stdout. That's it, that's the whole vibe. 💅

Arguments: None
Default: OFF — no optimization report is generated.

Description:

So like, 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). 🫶

And the cute part? If you use this option, you do not have to specify option [q or Q]opt-report. It's giving self-sufficient. ✨

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. Don't let it try to be the main character on the device side, okay? 🙈

Alternate Options: None

🦋 `-qopt-streaming-stores=keyword` (L*X only)

🦋 `-qno-opt-streaming-stores` (L*X only)

Enables generation of streaming stores for optimization. We love a non-temporal moment. 🔥

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. Like, genuinely your job, not the compiler's. 😭

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. 🌈 Pollution-free memory hierarchy, we stan.

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. She's cautious, she's discerning.
  - high — tells the compiler to generate zmm code without restrictions. No cap, full send. 🔥
Default: varies — the default is low when you specify [Q]xCORE-AVX512. The default is high when you specify [Q]xCOMMON-AVX512.

Description:

This option may provide better code optimization for Intel(R) processors that are on the Intel(R) microarchitecture formerly code-named Skylake. ⭐

This option defines a level of zmm registers usage. The low setting causes the compiler to generate code with zmm registers very carefully, only when the gain from their usage is proven. The high setting causes the compiler to use much less restrictive heuristics for zmm code generation.

It is not always easy to predict whether the high or the low setting will yield better performance. Programs that enjoy high performance gains from the use of xmm or ymm registers may expect performance improvement by moving to use zmm registers. However, some programs that use zmm registers may not gain as much or may even lose performance. We recommend that you try both option values to measure the performance of your programs. 🫶 Science! Experiment! Take notes!

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 directive SIMD SIMDLEN(n) or on functions that are generated by vector specifications specific to CORE-AVX512.

Alternate Options: None

🎀 `-qoverride-limits` (L*X only)

Lets you override certain internal compiler limits that are intended to prevent excessive memory usage or compile times for very large, complex compilation units. Chaos mode: unlocked. 💅

Arguments: None
Default: OFF — certain internal compiler limits are not overridden. These limits are determined by default heuristics.

Description:

This option provides a way to override certain internal compiler limits that are intended to prevent excessive memory usage or compile times for very large, complex compilation units.

If this option is not used and your program exceeds one of these internal compiler limits, some optimizations will be skipped to reduce the memory footprint and compile time. If you chose to create an optimization report by specifying [q or Q]opt-report, you may see a related diagnostic remark as part of the report. 👀

Specifying this option may substantially increase compile time and/or memory usage. 😭

NOTE: If you use this option, it is your responsibility to ensure that sufficient memory is available. If there is not sufficient available memory, the compilation may fail. Fr fr, check your RAM first.

This option should only be used where there is a specific need; it is not recommended for inexperienced users. 🫶

Alternate Options: None

🌸 `-real-size size` (L*X only)

Specifies the default KIND for real and complex declarations, constants, functions, and intrinsics. Big precision decisions happening here. ✨

Arguments:
- size — is the size for real and complex declarations, constants, functions, and intrinsics. Possible values are: 32, 64, or 128.
Default: real-size 32 — default real and complex declarations, constants, functions, and intrinsics are 4 bytes long (REAL(KIND=4) and COMPLEX(KIND=4)).

Description:

This option specifies the default size (in bits) for real and complex declarations, constants, functions, and intrinsics.

real-size 32 — makes default real and complex declarations, constants, functions, and intrinsics 4 bytes long. REAL declarations are treated as single precision REAL (REAL(KIND=4)) and COMPLEX declarations are treated as COMPLEX (COMPLEX(KIND=4)). Real and complex constants of unspecified KIND are evaluated in single precision (KIND=4). 🍓
real-size 64 — makes default real and complex declarations, constants, functions, and intrinsics 8 bytes long. REAL declarations are treated as DOUBLE PRECISION (REAL(KIND=8)) and COMPLEX declarations are treated as DOUBLE COMPLEX (COMPLEX(KIND=8)). Real and complex constants of unspecified KIND are evaluated in double precision (KIND=8). 💖
real-size 128 — makes default real and complex declarations, constants, functions, and intrinsics 16 bytes long. REAL declarations are treated as extended precision REAL (REAL(KIND=16)); COMPLEX and DOUBLE COMPLEX declarations are treated as extended precision COMPLEX (COMPLEX(KIND=16)). Real and complex constants of unspecified KIND are evaluated in extended precision (KIND=16). 👑

These compiler options can affect the result type of intrinsic procedures, such as CMPLX, FLOAT, REAL, SNGL, and AIMAG, which normally produce single-precision REAL or COMPLEX results. To prevent this effect, you must explicitly declare the kind type for arguments of such intrinsic procedures. ⚠️

For example, if real-size 64 is specified, the CMPLX intrinsic will produce a result of type DOUBLE COMPLEX (COMPLEX(KIND=8)). To prevent this, you must explicitly declare any real argument to be REAL(KIND=4), and any complex argument to be COMPLEX(KIND=4). Like, spell it out or she'll assume. 💀

Alternate Options:
- real-size 32 — Linux: -r4
- real-size 64 — Linux: -r8, -autodouble
- real-size 128 — Linux: -r16

🦋 `-recursive` (L*X only)

🦋 `-norecursive` (L*X only)

Tells the compiler that all routines should be compiled for possible recursive execution. Every single one. No exceptions, bestie. 🌀

Arguments: None
Default:
norecursive — routines are not compiled for possible recursive execution.

Description

Bestie this one is literally telling the compiler that every single routine should be compiled for possible recursive execution. It sets option auto. 🌸

NOTE: this option will be deprecated in a future release, so like… don't get too attached 💀. The recommended replacement is its successor: assume [no]recursion.

Alternate Options

Linux: -assume [no]recursion
Windows: /assume:[no]recursion

🧵 `-reentrancy` keyword (L*X only)

🧵 `-noreentrancy` (L*X only)

Tells the compiler to generate reentrant code to support a multithreaded application. threadsafe queen behavior ✨

Arguments

keyword — specifies details about the program. Possible values are:
- none — tells the runtime library (RTL) that the program does not rely on threaded or asynchronous reentrancy. The RTL will not guard against such interrupts inside its own critical regions. This is the same as specifying noreentrancy.
- async — tells the runtime library (RTL) that the program may contain asynchronous (AST) handlers that could call the RTL. This causes the RTL to guard against AST interrupts inside its own critical regions.
- threaded — tells the runtime library (RTL) that the program is multithreaded, such as programs using the POSIX threads library. This causes the RTL to use thread locking to guard its own critical regions. 🔒

Default

threaded — the compiler tells the runtime library (RTL) that the program is multithreaded.

Description

This option tells the compiler to generate reentrant code to support a multithreaded application.

If you don't specify a keyword for reentrancy, it's the same as specifying reentrancy threaded. no thoughts, just default 🫶

To ensure that a threadsafe and/or reentrant runtime library is linked and correctly initialized, option reentrancy threaded should also be used for the link step and for the compilation of the main routine.

Heads up: if option threads is specified, it sets option reentrancy threaded, since multithreaded code must be reentrant. iykyk 💅

Alternate Options

None

🛠️ `-S` (L*X only)

Causes the compiler to compile to an assembly file only and not link. just the assembly, ma'am 🎀

Arguments

None

Default

OFF — normal compilation and linking occur.

Description

This option causes the compiler to compile to an assembly file only and not link.

On Linux* systems, the assembly file name has a .s suffix. On Windows* systems, the assembly file name has an .asm suffix. iconique file extensions fr fr ⭐

Alternate Options

Linux: None

🪄 `-safe-cray-ptr` (L*X only)

Tells the compiler that Cray* pointers do not alias other variables.

Arguments

None

Default

OFF — the compiler assumes that Cray pointers alias other variables.

Description

This option tells the compiler that Cray pointers do not alias (that is, do not specify sharing memory with) other variables.

Alternate Options

None

💾 `-save` (L*X only)

Causes variables to be placed in static memory. they're staying put bestie 🫶

Arguments

None

Default

-auto-scalar — scalar variables of intrinsic types INTEGER, REAL, COMPLEX, and LOGICAL are allocated to the runtime stack. Note that the default changes to option auto if one of the following options are specified:
- recursive
- [q or Q]openmp

Description

This option saves all variables in static allocation except local variables within a recursive routine and variables declared as AUTOMATIC.

If you want all local, non-SAVEd variables to be allocated to the runtime stack, specify option auto.

Alternate Options

Linux: -noauto

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

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

Tells the compiler to save intermediate files created during compilation. keep the receipts 📝

Arguments

None

Default

Linux systems: -no-save-temps — on Linux systems, the compiler deletes intermediate files after compilation is completed.

Description

This option tells the compiler to save intermediate files created during compilation. The names of the files saved are based on the name of the source file; the files are saved in the current working directory.

If option -save-temps (Linux) or option /Qsave-temps (Windows) is specified, the following occurs:

On Linux, the object .o file is saved.
On Windows, the .obj file object .o file is saved.
The .i or .i90 file is saved if the fpp preprocessor is invoked.

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. don't go expecting ✨magic✨ 🙈

Alternate Options

None

🌐 `-shared` (L*X only)

Tells the compiler to produce a dynamic shared object instead of an executable. it's giving library main character energy 👑

Arguments

None

Default

OFF — the compiler produces an executable.

Description

This option tells the compiler to produce a dynamic shared object (DSO) instead of an executable. This includes linking in all libraries dynamically and passing -shared to the linker.

You must specify option fpic for the compilation of each object file you want to include in the shared library. no fpic, no entry 🚪✨

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 except for the following, which are linked in dynamically:
- Intel's coarray runtime support library
- Intel's OpenMP* runtime support library
- Intel's math functions library (libimf)
- Intel's replacement for libc (libintlc)

To link the OpenMP* runtime support library statically, specify option -qopenmp-link=static.

Description

This option causes Intel-provided libraries to be linked in dynamically. It is the exact opposite of -static-intel. 🔄

This option is processed by the compiler driver command that initiates linking, adding library names explicitly to the link command.

Lowkey important: if you specify option -mcmodel=medium or -mcmodel=large, it sets option -shared-intel.

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

Alternate Options

None

🎀 `-shared-libgcc` (L*X only)

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.

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

Alternate Options

None

👀 `-show` keyword[, keyword...] (L*X only)

Controls the contents of the listing generated when option list is specified. what goes in the listing stays in the listing 💅

Arguments

keyword — specifies the contents for the listing. Possible values are:
- [no]include — controls whether contents of files added with INCLUDE statements are included when a listing is generated.
[no]map — controls whether a symbol listing with a line number cross-reference for each routine gets included when a listing is generated. 🗺️
[no]options — controls whether a list of the compiler options used for the compilation gets included when a listing is generated. 📋

Default: include, map, and options — when a listing is generated, it contains the contents of INCLUDEd files, a symbol list with a line number cross reference, and a list of compiler options used. ✨

Description: This option controls the contents of the listing generated when option list is specified.

If you specify option show and do not specify option list, the option is ignored.

Alternate Options: None

-stand [keyword] (L*X only)
-nostand (L*X only)

Tells the compiler to issue compile-time messages for nonstandard language elements. 🚨

keyword specifies the language to use as the standard. Possible values are:

none — issues no messages for nonstandard language elements.
f90 — issues messages for language elements that are not standard in Fortran 90.
f95 — issues messages for language elements that are not standard in Fortran 95.
f03 or f2003 — issues messages for language elements that are not standard in Fortran 2003.
f08 or f2008 — issues messages for language elements that are not standard in Fortran 2008.
f18 or f2018 — issues messages for language elements that are not standard in Fortran 2018.
f23 or f2023 — issues messages for language elements that are not standard in Fortran 2023.

Default: nostand — the compiler issues no messages for nonstandard language elements.

Description: This option tells the compiler to issue compile-time messages for nonstandard language elements.

If you do not specify a keyword for stand, it is the same as specifying stand f18.

stand none — tells the compiler to issue no messages for nonstandard language elements. This is the same as specifying nostand.
stand f90 — tells the compiler to issue messages for language elements that are not standard in Fortran 90.
stand f95 — tells the compiler to issue messages for language elements that are not standard in Fortran 95.
stand f03 — tells the compiler to issue messages for language elements that are not standard in Fortran 2003.
stand f08 — tells the compiler to issue messages for language elements that are not standard in Fortran 2008.
stand f18 — tells the compiler to issue messages for language elements that are not standard in Fortran 2018. This option is set if you specify warn stderrors.
stand f23 — tells the compiler to issue messages for language elements that are not standard in Fortran 2023.

NOTE: When you specify this option, things that are not supported in the Fortran standard at the specified standard level are diagnosed with warnings. ⚠️

These standard compliance warnings can be ignored as they are informational only and do not affect compilation.

Alternate Options:

stand none Linux: -nostand
stand f90 Linux: -std90
stand f95 Linux: -std95
stand f03 Linux: -stand f2003, -std03
stand f08 Linux: -stand f2008, -std08
stand f18 Linux: -stand f2018, -std18, -stand, -std
stand f23 Linux: -stand f2023, -std23

-standard-realloc-lhs (L*X only)
-nostandard-realloc-lhs (L*X only)

Determines whether the compiler uses the current Fortran Standard rules or the old Fortran 2003 rules when interpreting assignment statements. 💅

Arguments: None

Default: standard-realloc-lhs — the compiler uses the current Fortran Standard rules when interpreting assignment statements.

Description: This option determines whether the compiler uses the current Fortran Standard rules or the old Fortran 2003 rules when interpreting assignment statements.

Option standard-realloc-lhs (the default) tells the compiler that when the left-hand side of an assignment is an allocatable object, it should be reallocated to the shape of the right-hand side of the assignment before the assignment occurs. This is the current Fortran Standard definition. This feature may cause extra overhead at runtime. This option has the same effect as option assume realloc_lhs.

If you specify nostandard-realloc-lhs, the compiler uses the old Fortran 2003 rules when interpreting assignment statements. The left-hand side is assumed to be allocated with the correct shape to hold the right-hand side. If it is not, incorrect behavior will occur. This option has the same effect as option assume norealloc_lhs. 😭

Alternate Options: None

-standard-semantics (L*X only)

Determines whether the current Fortran Standard behavior of the compiler is fully implemented. 👑

Arguments: None

Default: OFF — the compiler implements most but not all of the current Fortran Standard behavior.

Description: This option determines whether the current Fortran Standard behavior of the compiler is fully implemented.

If you specify option standard-semantics and do not specify a standard level with the stand option, it enables all of the options that implement the current Fortran Standard behavior of the compiler, which are Fortran 2018 features.

The following table shows which options are set by option standard-semantics when a stand option specifies a standard level:

Note that realloc_lhs, std_minus0_rounding, and std_value are default settings for option assume.

If you specify option standard-semantics and also explicitly specify a different setting for an affected assume option, the value you specify takes effect. It overrides the settings enabled by option standard-semantics.

Alternate Options: None

-static (L*X only)

Prevents linking with shared libraries. 🔒

Arguments: None

Default: varies — the compiler links with shared GNU libraries (Linux* systems) or shared Microsoft* libraries (Windows* systems) and it links with static Intel libraries, with the exception of the OpenMP* libraries and coarray library libicaf, which are linked in dynamically.

On Windows* systems, option /static is equivalent to option /MT.

Description: This option prevents linking with shared libraries. It causes the executable to link all libraries statically.

NOTE: This option does not cause static linking of libraries for which no static version is available, such as the OpenMP runtime libraries on Windows* or the coarray runtime libraries. These libraries can only be linked dynamically. 💀

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

Alternate Options: None

-static-intel (L*X only)

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 coarray runtime support library is linked in dynamically.
The Intel OpenMP* runtime support library is linked in dynamically. To prevent this, specify option -qopenmp-link=static.
The Intel specific math library functions in libimf are linked in dynamically.
The Intel replacement for libc (libintlc) is linked in dynamically.
The Intel 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.

Alternate Options: None

all of this gets handled by the compiler driver command that kicks off linking — it just adds library names explicitly to the link command. simple as that. ✨

If you specify option -static-intel while -mcmodel=medium or -mcmodel=large is set, an error will be displayed. like, it will simply not work, bestie.

And if you specify -static-intel and any of the Intel-provided libraries have no static version, a diagnostic will be displayed. heads up 🫶

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

Alternate Options:

None

🎀 `-static-libgcc` (L*X only)

Links the GNU libgcc library statically. obsessed with the commitment.

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. literally the mirror image 🌈

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. This library enables printing of backtrace information. so like, package deal 💀

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. yes, the whole thing. iconic.

Arguments:

None

Default:

OFF — the compiler links the GNU libstdc++ library dynamically.

Description:

This option links the GNU libstdc++ library statically. that's it, that's the whole bit.

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: this option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation.

Alternate Options:

None

🧚 `-syntax-only` (L*X only)

Tells the compiler to check only for correct syntax. vibe check, but for your code 🔥

Arguments:

None

Default:

OFF — normal compilation is performed.

Description:

This option tells the compiler to check only for correct syntax. It lets you do a quick syntax check of your source file. like a little sniff test before you commit, you know?

Compilation stops after the source file has been parsed. No code is generated, no object file is produced, and some error checking done by the optimizer is bypassed. nothing gets built, nothing gets written — it's giving "just looking" energy ✨

This option also generates all appropriate module files for each module found in the source. If Fortran preprocessing is requested, the preprocessed source file is also created.

Warnings and messages appear on stderr. 🫶

Alternate Options:

Linux: -y, -fsyntax-only, -syntax (this is a deprecated option)
Windows: /Zs

🌸 `--sysroot=dir` (L*X only)

Specifies the root directory where headers and libraries are located. house-hunting, but for includes 👑

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. it's literally just prefixing everything, and it slays 💖

Alternate Options:

None

🍓 `-Tfilename` (L*X only)

Tells the linker to read link commands from a file. delegating to a whole file, main character move.

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. that's the whole assignment 🎀

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

Alternate Options:

None

💜 `-Tf filename` (L*X only)

Tells the compiler to compile the file as a Fortran source file. yes, that file. the one with the weird extension.

Arguments:

filename — is the name of the file.

Default:

OFF — files that do not end in standard Fortran file extensions are not compiled as Fortran files.

Description:

This option tells the compiler to compile the file as a Fortran source file.

This option is useful when you have a Fortran file with a nonstandard file extension (that is, not one of .F, .FOR, or .F90). we don't judge file names here, we just compile them 💅

This option assumes the file specified uses fixed source form. If the file uses free source form, you must also specify option free. don't forget this part, fr fr 😭

Alternate Options:

None

⭐ `-threads` (L*X only)

⭐ `-nothreads` (L*X only)

Tells the linker to search for unresolved references in a multithreaded runtime library. threads! we love her!

Arguments:

None

Default:

threads — the linker searches for unresolved references in a library that supports enabling thread-safe operation.

Description:

This option tells the linker to search for unresolved references in a multithreaded runtime library.

This option sets option reentrancy threaded.

Windows systems: the docs drop a table showing which options to specify for a multithreaded runtime library. (table's in the original, bestie — the vibes are the same 🫶)

To ensure that a threadsafe and/or reentrant runtime library is linked and correctly initialized, option threads should also be used for the link step and for the compilation of the main routine. yes, both. don't skip the main routine, that's the classic blunder 💀

NOTE: on Windows* systems, this option is processed by the compiler, which adds directives to the compiled object file that are processed by the linker. On Linux* systems, this option is processed by the ifx command that initiates linking, adding library names explicitly to the link command. different pipelines, same slay ✨

Alternate Options:

None

🔥 `-traceback` (L*X only)

🔥 `-notraceback` (L*X only)

Tells the compiler to generate extra information in the object file to provide source file traceback information when a severe error occurs at runtime. so when everything goes up in flames, at least you know where 🔥

Arguments:

None

Default:

notraceback — no extra information is generated in the object file to produce traceback information.

Description:

This option tells the compiler to generate extra information in the object file to provide source file traceback information when a severe error occurs at runtime.

When the severe error occurs, source file, routine name, and line number correlation information is displayed along with call stack hexadecimal addresses (program counter trace). it literally hands you the receipts 😭

Note that when a severe error occurs, advanced users can also locate the cause of the error using a map file and the hexadecimal addresses of the stack displayed when the error occurs.

This option increases the size of the executable program, but has no impact on runtime execution speeds. bigger file, same speed — free real estate 🎀

It functions independently of the debug option.

Linux

To display the section headers in the image (including the header for the .trace section, if any), use the command:

objdump -h your_app_name.exe

Windows

Option traceback sets the /Oy- option, which forces the compiler to use EBP as the stack frame pointer.

The linker places the traceback information in the executable image, in a section named .trace. To see which sections are in an image, use the command:

link -dump -summary your_app_name.exe

To see more detailed information, use the command:

link -dump -headers your_app_name.exe

When requesting traceback, you must set Enable Incremental Linking in the VS .NET* IDE Linker Options to No. You must also set Omit Frame Pointers (the /Oy option) in the Optimization Options to "No." both of them. no negotiating 🙈

Alternate Options:

None

🌈 `-Uname` (L*X only)

Undefines any definition currently in effect for the specified symbol. un-defining. the anti-define. 💅

Arguments:

name — is the name of the symbol to be undefined.

Default:

OFF — symbol definitions are in effect until they are undefined.

Description:

This option undefines any definition currently in effect for the specified symbol.

On Windows systems, use the /u option to undefine all previously defined preprocessor values. that's the nuke button, just so we're clear 💀

Alternate Options:

Linux: None
Windows: /undefine:name

👑 `-undef` (L*X only)

Disables all predefined symbols. all of them. every last one. periodt.

Arguments:

None

Default:

OFF — defined symbols are in effect until they are undefined.

Description:

This option disables all predefined symbols. that's it, that's the whole personality 🌸

Alternate Options:

None

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

Tells the compiler the maximum number of times to unroll loops. loop unrolling, but make it a limit 🦋

Arguments:

n — is the maximum number of times a loop can be unrolled. To disable loop enrolling, specify 0. (yes, the page really says "enrolling" — we're keeping it, she's iconic 💜)

Default:

(and this is exactly where this chunk of the page cuts off, bestie — the next part picks it right back up 🫶)

-unroll or /Qunroll — the compiler just does its own thing with default heuristics when unrolling loops. No numbers, no input, she's got it 💅

Arguments

None, bestie — it's a vibe-only flag.

Description

So this option tells the compiler the maximum number of times to unroll loops. 🌀

If you don't specify n, the optimizer decides for itself how many times loops can be unrolled. It's giving "trust the process" energy.

Alternate Options

Linux: -funroll-loops

-v [filename] (L*X only) — says that driver tool commands should be displayed and executed. Like, she's not just doing the work, she's narrating it too 📣

Arguments

filename — the name of a source file to be compiled. Heads up: a space must appear before the file name. Don't forget the space, fr fr.

Default

OFF — no tool commands are shown. Nothing to see here.

Description

This option specifies that driver tool commands should be displayed and executed. ✨

If you use this option without specifying a source file name, the compiler displays only the version of the compiler. Cute, short, to the point.

If you want to display processing information (pass information and source file names), specify keyword all for the watch option. That's where the full tea gets spilled.

Alternate Options

Linux: -watch cmd
Windows: /watch:cmd

-vec (L*X only)
-no-vec (L*X only) — enables or disables loop vectorization 🚀

Arguments

None

Default

-vec — loop vectorization is enabled if option O2 or higher is in effect.

Description

This option enables or disables loop vectorization. That's it, that's the whole vibe.

To disable loop vectorization, specify -no-vec (Linux*) or /Qvec- (Windows*).

NOTE: Using this option enables vectorization at default optimization levels for both Intel(R) microprocessors and non-Intel microprocessors. Vectorization may call library routines that can result in additional performance gain on Intel microprocessors than on non-Intel microprocessors. 👀

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

Alternate Options

None

-vec-assume-index-overflow (L*X only)
-no-vec-assume-index-overflow (L*X only) — toggles between modes, with the less conservative mode as the default. Flip-flop energy 🩴

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. Basically: safety goggles on, extra fancy optimizations off. 🥽

Alternate Options

None

-vec-threshold[n] (L*X only) — sets a threshold for the vectorization of loops. Very "pick your risk level" of her 🌡️

Arguments

n — 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, zero hesitation.
- If n is 100, loops get vectorized when performance gains are predicted based on the compiler analysis data. Loops get vectorized only if profitable vector-level parallel execution is almost certain.
- The intermediate 1 to 99 values represent the percentage probability for profitable speed-up. For example, n=50 directs the compiler to vectorize only if there is a 50% probability of the code speeding up if executed in vector form.

Default

-vec-threshold100 — loops get vectorized only if profitable vector-level parallel execution is almost certain. This is also the default if you do not specify n.

Description

This option sets a threshold for the vectorization of loops based on the probability of profitable execution of the vectorized loop in parallel. 📊

This option is useful for loops whose computation work volume cannot be determined at compile-time. The threshold is usually relevant when the loop trip count is unknown at compile-time.

The compiler applies a heuristic that tries to balance the overhead of creating multiple threads versus the amount of work available to be shared amongst the threads. Math girlie behavior honestly.

NOTE: This option only applies to host compilation. When offloading is enabled, it does not impact device-specific compilation. Same energy as before, iconic consistency 💅

Alternate Options

None

-vecabi=keyword (L*X only) — determines which vector function application binary interface (ABI) the compiler uses to create or call vector functions 🧬

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. Love that for us.
- gcc — tells the compiler to use the gcc vector function ABI.

Default

gcc — the compiler uses the gcc-compatible vector function ABI.

Description

This option determines which vector function application binary interface (ABI) the compiler uses to create or call vector functions. 🎀

All files in an application that define or use vector functions must make identical use of -vecabi=cmdtarget (and /Qvecabi:cmdtarget); otherwise, link-time or runtime errors may occur. For all files where -vecabi=cmdtarget (or /Qvecabi:cmdtarget) is specified, options [Q]x and/or [Q]ax must have identical values. No mixing, bestie — matching outfits only. 👯

Similarly, link errors may occur if you attempt to link code compiled with -vecabi=cmdtarget (or /Qvecabi:cmdtarget) with libraries or other program modules/routines that contain vector function definitions that have not or cannot be recompiled.

When cmdtarget is specified, the additional vector function versions are created by copying each vector specification and changing target processor in the copy. The number of vector functions is determined by the settings specified in options [Q]x and/or [Q]ax.

For example, suppose we have the following function declaration:

function foo(a) !$omp declare simd processor(core_2_duo_sse4_1)
implicit none integer, intent(in) :: a integer             :: foo
end function foo

and the following options are specified: -axAVX, CORE-AVX2.

The following table shows the different results for the above declaration and option specifications when setting gcc or setting cmdtarget is used:

gcc — a vector version is created for each of the following targets:
- Intel(R) SSE2
- Intel(R) AVX
- Intel(R) AVX2
- Intel(R) AVX512

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 information about the Intel(R)-compatible vector functions ABI, see the downloadable PDF titled Vector Function Application Binary Interface.

For more information 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

-vms (L*X only)
-novms (L*X only) — causes the runtime system to behave like HP* Fortran on OpenVMS* Alpha systems and VAX* systems (VAX FORTRAN*). Yes, we're time-traveling, babes 🕰️

Arguments

None

Default

novms — the runtime system follows default Intel(R) Fortran behavior.

Description

This option causes the runtime system to behave like HP* Fortran on OpenVMS* Alpha systems and VAX* systems (VAX FORTRAN*). Vintage. Antique. Retro chic. 🦋

It affects the following language features:

Certain defaults — in the absence of other options, vms sets the defaults as check format and check output_conversion.
Alignment — option vms does not affect the alignment of fields in records or items in common blocks. For compatibility with HP Fortran on OpenVMS systems, use align norecords to pack fields of records on the next byte boundary.
Carriage control default — If option vms and option ccdefault default are specified, carriage control defaults to FORTRAN if the file is formatted and the unit is connected to a terminal. 💅
INCLUDE qualifiers — /LIST and /NOLIST are recognized at the end of the file name in an INCLUDE statement at compile time. If the file name in the INCLUDE statement does not specify the complete path, the path used is the current directory. Note that if vms is not specified, the path used is the directory where the file that contains the INCLUDE statement resides. ✨
Quotation mark character — A quotation mark (") character is recognized as starting an octal constant ("0..7) instead of a character literal ("..."). 🎀
Deleted records in relative files — When a record in a relative file is deleted, the first byte of that record is set to a known character (currently '@'). Attempts to read that record later result in ATTACCNON errors. The rest of the record (the whole record, if vms is not specified) is set to nulls for unformatted files and spaces for formatted files. 💀
ENDFILE records — When an ENDFILE is performed on a sequential unit, an actual 1-byte record containing a Ctrl/Z is written to the file. If vms is not specified, an internal ENDFILE flag is set and the file is truncated. The vms option does not affect ENDFILE on relative files: these files are truncated. 🔥
Implied logical unit numbers — The vms option enables Intel(R) Fortran to recognize certain environment variables at runtime for ACCEPT, PRINT, and TYPE statements and for READ and WRITE statements that do not specify a unit number (such as READ (*,1000)). 🌈
Treatment of blanks in input — The vms option causes the defaults for the keyword BLANK in OPEN statements to become 'NULL' for an explicit OPEN and 'ZERO' for an implicit OPEN of an external or internal file. 💜
OPEN statement effects — Carriage control defaults to FORTRAN if the file is formatted, and the unit is connected to a terminal. Otherwise, carriage control defaults to LIST. The vms option affects the record length for direct access and relative organization files. The buffer size is increased by 1 to accommodate the deleted record character. 🦋
Reading deleted records and ENDFILE records — The runtime direct access READ routine checks the first byte of the retrieved record. If this byte is '@' or NULL (" "), then an ATTACCNON error is returned. The runtime sequential access READ routine checks to see if the record it just read is one byte long and contains a Ctrl/Z. If this is true, it returns EOF. 👑

Alternate Options: None

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

`-warn [keyword[, keyword...]]` (LX only) / `-nowarn` (LX only) 🚨

Specifies diagnostic messages to be issued by the compiler.

Arguments:

keyword — Specifies the diagnostic messages to be issued. Possible values are:
- all — Enables all warning messages except errors and stderrors. This is the default if no keyword is specified. Note that if all is in effect, stderrors are not upgraded to warning level.
- [no]alignments — Determines whether warnings occur for data that is not naturally aligned.
- [no]declarations — Determines whether warnings occur for any undeclared names.
- [no]errors — Determines whether warnings are changed to errors.
- [no]externals — Determines whether warnings occur for any dummy procedures or procedure calls that have no explicit interface or have not been declared external.
- [no]general — Determines whether warning messages and informational messages are issued by the compiler.
- [no]ignore_bounds — Determines whether the compiler issues warnings if it detects at compile time that a constant array subscript is out of the declared bounds of the array.
- [no]ignore_loc — Determines whether warnings occur when %LOC is stripped from an actual argument.
- [no]interfaces — Determines whether the compiler checks the interfaces of all SUBROUTINEs called and FUNCTIONs invoked in your compilation against an external set of interface blocks.
- [no]shape — Determines whether array conformance violations are diagnosed with errors or warnings when used with the check shape option.
- [no]stderrors — Determines whether warnings about Fortran standard violations are changed to errors.
- [no]truncated_source — Determines whether warnings occur when source exceeds the maximum column width in fixed-format files.
- [no]uncalled — Determines whether warnings occur when a statement function is never called.
- [no]unused — Determines whether warnings occur for declared variables that are never used.
- [no]usage — Determines whether warnings occur for questionable programming practices.
- none — Disables all warning messages.

Default:

alignments — Warnings are issued about data that is not naturally aligned.
general — All information-level and warning-level messages are enabled.
nodeclarations — No warnings are issued for undeclared names.
noerrors — Warning-level messages are not changed to error-level messages.
noexternals — No warnings are issued when a dummy procedure or external procedure does not have an explicit interface and has not be declared external.
noignore_bounds — The compiler checks array references with constant subscripts and warns if the reference is to an element outside the declared bounds of the array.
noignore_loc — No warnings are issued when %LOC is stripped from an argument.
nointerfaces — The compiler does not check interfaces of SUBROUTINEs called and FUNCTIONs invoked in your compilation against an external set of interface blocks.
noshape — Array conformance violations are issued as errors if the check shape option is specified.
nostderrors — Warning-level messages about Fortran standards violations are not changed to error-level messages.
notruncated_source — No warnings are issued when source exceeds the maximum column width in fixed-format files.
nounused — No warnings are issued for variables that are declared but never used.
uncalled — Warnings are issued when a statement function is not called.
usage — Warnings are issued for questionable programming practices.

Description:

This option specifies the diagnostic messages to be issued by the compiler. 📋

warn none — Disables all warning messages. This is the same as specifying nowarn.
warn noalignments — Disables warnings about data that is not naturally aligned.
warn declarations — okay so this one turns on warnings about any undeclared names. The compiler will use the default implicit data typing rules for such undeclared names. The IMPLICIT and IMPLICIT NONE statements override this option. 💖
warn errors — tells the compiler to change all warning-level messages to error-level messages; this includes warnings about Fortran standards violations. no soft-launching those warnings anymore 😭
warn externals — enables warnings about dummy procedures and external procedures that do not have explicit interfaces and have not been declared with the EXTERNAL attribute.
warn nogeneral — disables all informational-level and warning-level diagnostic messages. quiet mode for the chatty compiler 🙈
warn ignore_bounds — the compiler does not check array references with constant subscripts and no warnings are issued if the reference is to an element outside the declared bounds of the array.
warn ignore_loc — enables warnings when %LOC is stripped from an actual argument.
warn interfaces — bestie, this is the interface police 👑. It tells the compiler to check the interfaces of all SUBROUTINEs called and FUNCTIONs invoked in your compilation against a set of interface blocks stored separately from the source being compiled.
- The compiler generates a compile-time message if the interface used to invoke a routine does not match the interface defined in a .mod file external to the source (that is, in a .mod generated by option gen-interfaces as opposed to a .mod file USEd in the source). The compiler looks for these (-I) or -module option. If interface mismatches occur, some will result in a compile-time error, others will only generate a warning.
- By default, warn interfaces turns on option gen-interfaces. You can turn off that option by explicitly specifying option nogen-interfaces.
warn shape — if the check shape option is specified, array conformance violations are issued as warnings rather than as errors.
warn stderrors — tells the compiler to change all warning-level messages about Fortran standards violations to error-level messages. This option sets the stand option.
warn truncated_source — enables warnings when a source line exceeds the maximum column width in fixed-format source files. The maximum column width for fixed-format files is 72, 80, or 132, depending on the setting of the extend-source option. The warn truncated_source option has no effect on truncation; lines that exceed the maximum column width are always truncated. This option does not apply to free-format source files. fixed-format girlies stay on alert 🎀
warn nouncalled — disables warnings for statement functions that are declared but never used.
warn unused — enables warnings for variables that are declared but never used. the "you bought it, why aren't you using it" of compiler flags 🛍️
warn nousage — disables warnings about questionable programming practices. Questionable programming practices, although allowed, often are the result of programming errors; for example: a continued character or Hollerith literal whose first part ends before the statement field and appears to end with trailing spaces. Note that the /pad-source option can prevent this error.
warn all — this is the same as specifying warn. This option does not set options warn errors or warn stderrors. To enable all the additional checking to be performed and force the severity of the diagnostic messages to be severe enough to not generate an object file, specify options warn all and warn errors or specify options warn all and warn stderrors. maximum chaos, but make it official ✨
- Windows: in the Property Pages, Custom means that diagnostics will be specified on an individual basis.

Alternate Options:

warn none — Linux: -nowarn, -w, -W0, -warn nogeneral
warn declarations — Linux: -implicitnone, -u
warn nodeclarations — Linux: None
warn general — Linux: -W1
warn nogeneral — Linux: -W0, -w, -nowarn, -warn none
warn stderrors — Linux: -e90, -e95, -e03, -e08, -e18
warn all — Linux: -warn

-watch[=keyword[, keyword...]] (L*X only) — tells the compiler to display certain information to the console output window. we're nosy now 👀
-nowatch (L*X only) — the off switch for that display behavior.

Arguments:

keyword — determines what information is displayed. Possible values are:
- none — disables cmd and source.
- [no]cmd — determines whether driver tool commands are displayed and executed.
- [no]source — determines whether the name of the file being compiled is displayed.
- all — enables cmd and source.

Default:

nowatch — pass information and source file names are not displayed to the console output window.

Description:

Tells the compiler to display processing information (pass information and source file names) to the console output window.

watch keyword rundown: yes, again, but with extra detail 💅

none — tells the compiler to not display pass information and source file names to the console output window. This is the same as specifying nowatch.
cmd — tells the compiler to display and execute driver tool commands.
source — tells the compiler to display the name of the file being compiled.
all — tells the compiler to display pass information and source file names to the console output window. This is the same as specifying watch with no keyword. For heterogeneous compilation, the tool commands for the host and the offload compilations will be displayed.

Alternate Options:

watch cmd — Linux: -v

-WB (L*X only) — turns a compile-time bounds check into a warning. gentle parenting the bounds check 🧚

Arguments:

None

Default:

OFF — compile-time bounds checks are errors.

Description:

This option turns a compile-time bounds check into a warning.

Alternate Options:

None

-what (L*X only) — tells the compiler to display its detailed version string. identity reveal, compiler edition 🪞

Arguments:

None

Default:

OFF — the version strings are not displayed.

Description:

This option tells the compiler to display its detailed version string.

Alternate Options:

None

-Wl,option1[,option2,...] (L*X only) — passes options to the linker for processing. handing the linker a little note 📝

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

-Wp,option1[,option2,...] (L*X only) — passes options to the preprocessor. preprocessor gets a lil gift too 🎁

Arguments:

option — is a preprocessor option. This option is not processed by the driver and is directly passed to the preprocessor.

Default:

OFF — no options are passed to the preprocessor.

Description:

This option passes one or more options to the preprocessor. If the preprocessor is not invoked, these options are ignored.

This option is equivalent to specifying option -Qoption,fpp, options.

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

Alternate Options:

None

-wrap-margin (L*X only) — provides a way to disable the right margin wrapping that occurs in Fortran list-directed output. the margin is wrapping, bestie 🎀
-no-wrap-margin (L*X only) — also provides a way to disable the right margin wrapping that occurs in Fortran list-directed output.

Arguments:

None

Default:

wrap-margin — the right margin wraps at column 80 if the record length is greater than 80 characters.

Description:

Like, some programs really want their Fortran list-directed output to stay on one line, and this option is your girl for that. By default, when the record being written becomes longer than 80 characters, the record is wrapped to a new record at what is called the "right margin" — annoying, honestly.

So specify -no-wrap-margin (Linux*) or /wrap-margin- (Windows*) to disable this behavior. Bye bye wrapping. 💅

Alternate Options:

None 😔

`-X` (L*X only)

Removes standard directories from the include file search path. Iconic behavior, honestly.

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

This option affects fpp preprocessor behavior and the USE statement.

Alternate Options:

Linux: -nostdinc

`-xcode` (L*X only)

Tells the compiler which processor features it may target, including which instruction sets and optimizations it may generate. It's giving "choose your fighter" but for microarchitectures. 🔥

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.

Bestie, heads up: keyword ICELAKE is deprecated and may be removed in a future release. 😭 Don't get attached.

COMMON-AVX512 — May generate Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512) Foundation instructions, Intel(R) AVX-512 Conflict Detection Instructions (CDI), as well as the instructions enabled with CORE-AVX2. Optimizes for Intel(R) processors that support Intel(R) AVX-512 instructions.

CORE-AVX512 — May generate Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512) Foundation instructions, Intel(R) AVX-512 Conflict Detection Instructions (CDI), Intel(R) AVX-512 Doubleword and Quadword Instructions (DQI), Intel(R) AVX-512 Byte and Word Instructions (BWI) and Intel(R) AVX-512 Vector Length Extensions (VLE), as well as the instructions enabled with CORE-AVX2. Optimizes for Intel(R) processors that support Intel(R) AVX-512 instructions.

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 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 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 — May generate MOVBE instructions for Intel(R) processors, depending on the setting of option -minstruction (Linux) or /Qinstruction (Windows). May also generate SSSE3, Intel(R) SSE3, SSE2, and SSE instructions for Intel processors. Optimizes for Intel Atom(R) processors that support Intel(R) SSE3 and MOVBE instructions.

SSSE3 — May generate SSSE3 and Intel(R) SSE3, SSE2, and SSE instructions for Intel(R) processors. Optimizes for Intel processors that support SSSE3 instructions.

SSE3 — May generate Intel(R) SSE3, SSE2, and SSE instructions for Intel(R) processors. Optimizes for Intel processors that support Intel(R) SSE3 instructions.

You can also specify a Host. For more information, see option [Q]xHost. 🦋

Default:

OFF 💤 — if option -x or -march is not specified (Linux), the default target architecture supports Intel® SSE2 instructions.

Description 🌸

Okay so this option is literally the compiler's vibe check for your CPU — it tells the compiler which processor features it may target, including which instruction sets and optimizations it may generate. 🎯

The resulting executables created from these option code values can only be run on Intel® processors that support the indicated instruction set. No cap, that's the whole deal.

Do not use code values to create binaries that will execute on a processor that is not compatible with the targeted processor. The resulting program may fail with an illegal instruction exception or display other unexpected behavior. 💀 Like, it will simply not slay. It will crash.

Compiling the main program 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® processors. 🫶

The -x and /Qx options enable additional optimizations not enabled with options -march or /arch. Extra sparkle ✨, extra speed.

Linux 🐧

Options -x and -march are mutually exclusive. If both are specified, the compiler uses the last one specified and generates a warning. Messy but honest, iykyk.

Windows 🪟

Options /Qx and /arch are mutually exclusive. If both are specified, the compiler uses the last one specified and generates a warning. Same energy, different OS.

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. 👑 Know the difference, bestie.

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` — LX only* 💻

Tells the compiler to generate instructions for the highest instruction set available on the compilation host processor. Main character energy for your CPU. 👑

Arguments: None

Default:

OFF — if option -x or -march is not specified (Linux), the default target architecture supports Intel® SSE2 instructions.

Description 🌈

This option tells the compiler to generate instructions for the highest instruction set available on the compilation host processor. Literally "whatever this machine can do, go off." 🔥

The instructions generated by this compiler option differ depending on the compilation host processor. So it's giving adaptable 💅 — it depends on the host.

For more information on other settings for option [Q]x, see that option description. (Yes, go read that one too, bestie, it's all connected.)

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

NOTE: ifx does not support compilation for 32-bit architectures; only 64-bit instruction set names may be specified for ifx. 🚫 No 32-bit era allowed, we're strictly 64-bit now.

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 — LX only* 🔗

Passes a linker option directly to the linker. Like handing a note straight to the linker without reading it first. 🫡

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. No thoughts, head empty, just delivery. 📦

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

Like yes, you have to repeat it. That's the trick. 🪄

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" — LX only* 🧚

Enables options to be passed to the specified tool in the device compilation tool chain for the OpenMP* target. Very niche, very demure. 💜

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. Two-in-one moment. 🫶
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. Go deliver that message, bestie. 💌

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

Alternate Options: None

`-Xsycl-target-tool=T` "options" — LX only* 🦋

Enables options to be passed to the specified tool in the device compilation tool chain for the SYCL* target. Same icon behavior, SYCL edition. 💫

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 SYCL target. Delivering the mail again, but to the SYCL address. 📬

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

Alternate Options: None

`-zero` — LX only* 🍓

`-nozero` — LX only* 🍓

Initializes to zero variables of intrinsic type INTEGER, REAL, COMPLEX, or LOGICAL that are not yet initialized. ✨

This is a deprecated option. 🚩 The replacement option is /Qinit:[no]zero or -init=[no]zero. So like, use the new one, bestie — this is giving vintage, and not in the cute way.

Arguments: None

Default:

-nozero — variables are not initialized to zero. 💤

Description 🌸

This option initializes to zero variables of intrinsic type INTEGER, REAL, COMPLEX, or LOGICAL that are not yet initialized. Clean slate, fresh start, zeroed out. 🧼

Use option [Q]save on the command line to make all local variables specifically marked as SAVE.

Alternate Options: None

💅 Predefined Preprocessor Symbols 💅

Okay so, preprocessor symbols (aka macros) are literally just lil' name-tags that let you substitute values in a program before it gets compiled — the substitution happens in the preprocessing phase, no cap. ✨

The preprocessor symbols shown in the table below are predefined by the compiler system and are available to compiler directives and to fpp. If you want to use other symbol names, you need to specify them on the command line.

You can use the D compiler option to define the symbol names to be used during preprocessing — it does the exact same thing as the #define preprocessor directive. 🎀

Preprocessing with fpp replaces every occurrence of the defined symbol name with the specified value. Preprocessing compiler directives only allow IF and IF DEFINED.

If you want to disable symbol replacement (also known as macro expansion) during the preprocessor step, you can specify the macro=no preprocessor option for fpp. 🦋

Disabling preprocessor symbol replacement is useful for running fpp to perform conditional compilation (using #ifdef, etc.) without replacement.

You can use the U preprocessor option to suppress an automatic definition of a preprocessor symbol. This option suppresses any symbol definition currently in effect for the specified name. This option also performs the same function as an #undef preprocessor directive.

The symbols in the following table can be used in both fpp and Fortran compiler conditional compilations.

Footnotes:

The 2021.1 Intel(R) Fortran Compiler (ifx) produces the __INTEL_COMPILER format for this macro. Subsequent releases use the format as documented.

🌈 Supported Environment Variables 🌈

🧚 Compiler Compile-Time Environment Variables 🧚

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

IFXCFG — Specifies an ifx configuration file that the compiler should use instead of the default configuration file.

By default, the compiler uses the default configuration file (ifx.cfg) from the same directory where the compiler executable resides.

NOTE: On Windows, this environment variable cannot be set from Visual Studio.

__INTEL_PRE_FFLAGS
__INTEL_POST_FFLAGS — 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 ifx.cfg.

NOTE: By default, a configuration file named ifx.cfg 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 IFXCFG environment variable to assign the directory and file name for the configuration file.

You can insert command line options in the prefix position using __INTEL_PRE_FFLAGS, or in the suffix position using __INTEL_POST_FFLAGS. The command line is built as follows:

Syntax:

ifx <PRE flags> <flags from configuration file> <flags from the compiler invocation> <POST flags>

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

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.

LD_LIBRARY_PATH (Linux) — Specifies the location for shared objects (.so files).
INCLUDE (Windows) — Specifies the directory path for the include files (files included by INCLUDE statements, #include files, RC INCLUDE files1, and module files referenced by USE statements).

1 Files from the Resource Compiler, used to create dialog boxes and other Windows-GUI interfaces.

LIB (Windows) — Specifies the directories for all libraries used by the compiler and linker.

🌸 GNU Environment Variables and Extensions 🌸

CPATH (Linux) — Specifies the path for include and module files.
LIBRARY_PATH (Linux) — Specifies the path for libraries to be used during the link phase.

NOTE: INTEL_ROOT is an environment variable that is reserved for the Intel(R) Fortran Compiler. Its use is not supported. Use of this variable may result in unexpected compiler behavior. 😭 (like, do not touch, fr fr)

💜 Compiler Runtime Environment Variables 💜

The Intel(R) Fortran Compiler runtime system recognizes a number of environment variables. These variables can be used to customize runtime diagnostic error reporting, allow program continuation under certain conditions, disable the display of certain dialog boxes under certain conditions, and allow just-in-time debugging.

Environment variables relating to file I/O are interpreted when the file is opened. Other variables are read when the program starts.

The order of precedence for runtime environment variables is:

OPEN keyword
Environment variable(s)
Command line option

For Fortran runtime environment variables that are boolean (either enabled or disabled), the following tables describe values you can use to enable or disable them. These rules do not apply to environment variables for OpenMP* (OMP_) and their extensions (KMP_). 🫶

Setting a Runtime Environment Variable to ON or OFF

An integer composed entirely of digits other than 0 enables the environment variable.
- 1
- 4938493848
A string starting with t or T, y or Y, enables the environment variable.
- Because you cannot include quotes, or spaces preceding the string, " T" and ' YES' do not work, because both spaces and quotation marks are considered letters.
- T
- t
- TRUE
- TFALSE
- Y
- y
- yes
- yeti
Anything that does not enable the environment variable disables it.
- 0
- -1
- +1
- <no value set>

The following table summarizes compiler environment variables that are recognized at runtime.

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/

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

ifort(1), ld(1)

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

💅 Notices and Disclaimers 💅

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

No product or component can be absolutely secure.

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.

Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or go to: http://www.intel.com/design/literature.htm

Product and Performance Information

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

Notice revision #20201201

Intel, the Intel logo, Intel Atom, Intel Core, Intel Xeon, Intel Xeon Phi, Pentium, and VTune are trademarks of Intel Corporation in the U.S. and/or other countries.

*Other names and brands may be claimed as the property of others.

Microsoft, Windows, and the Windows logo are trademarks, or registered trademarks of Microsoft Corporation in the United States and/or other countries.

This software and the related documents are Intel copyrighted materials, and your use of them is governed by the express license under which they were provided to you (License). Unless the License provides otherwise, you may not use, modify, copy, publish, distribute, disclose or transmit this software or the related documents without Intel's prior written permission.

This software and the related documents are provided as is, with no express or implied warranties, other than those that are expressly stated in the License.

Intel optimizations, for Intel compilers or other products, may not optimize to the same degree for non-Intel products.

okay bestie, that's literally the whole page, we ate that up 💅✨ this little masterpiece comes to you from the IFX(1) man page, Copyright(C) 2005-2025 Intel Corporation — from 2005 all the way to 2025, an icon that has been serving longevity 🎀🫶 bye mwah 💖

📦 where this page comes from

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

IFX(1)

🎀 IFX(1) — Intel(R) Fortran Compiler 🎀

✨ SYNOPSIS ✨

🦋 DESCRIPTION 🦋

🚀 Options that Improve Run-Time Performance 🚀

🧵 Configuration and Indirect Files 🧵

🌈 FEATURE REQUIREMENTS 🌈

👑 OPTIONS 👑

🧸 Arguments:

🌸 Default:

💫 Description:

🌈 Default 🌈

💅 Description 💅

Alternate Options

Arguments

✨ Default: ✨

🎀 Description 🎀

assume underscore ✨

assume 2underscores (Linux) 🦋

assume writeable-strings 🎀

-auto (L*X only) / -noauto (L*X only) 🫶

-auto-scalar (L*X only) 🌸

-axcode (L*X only) 🔥

-Bdir (L*X only)

-Bdynamic (L*X only)

-Bstatic (L*X only)

-Bsymbolic (L*X only)

🦋 -Bsymbolic-functions (L*X only)

🎀 -c (L*X only)

🌸 -ccdefault keyword (L*X only)

💜 -check [keyword[, keyword...]] (L*X only), -nocheck (L*X only)

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

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

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

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

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

the three options for maximum relative error 🫶

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

Arguments

Default

Description

-finline (L*X only) ✨

-fno-inline (L*X only) ✨

Arguments

Default

Description

Alternate Options

-finline-functions (L*X only) 🦋

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

Arguments

Default

Description

Alternate Options

-finstrument-functions (L*X only) 🍓

-fno-instrument-functions (L*X only) 🍓

Arguments

Default

Description

🌸 -fiopenmp (L*X only)

🦋 -fixed (L*X only)

🦋 -nofixed (L*X only)

💜 -flink-huge-device-code (L*X only)

💜 -fno-link-huge-device-code (L*X only)

🧚 -fltconsistency (L*X only)

🧚 -nofltconsistency (L*X only)

🌈 -flto[=arg] (L*X only)

🌈 -fno-lto (L*X only)

🐧 Linux:

🪟 Windows:

-fma (L*X only)

-no-fma (L*X only)

-fmaintain-32-byte-stack-align (L*X only)

-fno-maintain-32-byte-stack-align (L*X only)

-fmath-errno (L*X only)

-fno-math-errno (L*X only)

-fmerge-debug-strings (L*X only)

-fno-merge-debug-strings (L*X only)

-fomit-frame-pointer (L*X only)

-fno-omit-frame-pointer (L*X only)

-fopenmp (L*X only)

`assume underscore` ✨

`assume 2underscores` (Linux) 🦋

`assume writeable-strings` 🎀

`-auto` (LX only) / `-noauto` (LX only) 🫶

`-auto-scalar` (L*X only) 🌸

`-axcode` (L*X only) 🔥

`-Bdir` (L*X only)

`-Bdynamic` (L*X only)

`-Bstatic` (L*X only)

`-Bsymbolic` (L*X only)

🦋 `-Bsymbolic-functions` (L*X only)

🎀 `-c` (L*X only)

🌸 `-ccdefault` keyword (L*X only)

💜 `-check` [keyword[, keyword...]] (LX only), `-nocheck` (LX only)

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

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

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

🎯 `-fimf-max-error=ulps[:funclist]` (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) 🦋

`-finstrument-functions` (L*X only) 🍓

`-fno-instrument-functions` (L*X only) 🍓

🌸 `-fiopenmp` (LX only)*

🦋 `-fixed` (LX only)*

🦋 `-nofixed` (LX only)*

💜 `-flink-huge-device-code` (LX only)*

💜 `-fno-link-huge-device-code` (LX only)*

🧚 `-fltconsistency` (LX only)*

🧚 `-nofltconsistency` (LX only)*

🌈 `-flto[=arg]` (LX only)*

🌈 `-fno-lto` (LX only)*

`-fma` (L*X only)

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

`-fmaintain-32-byte-stack-align` (L*X only)

`-fno-maintain-32-byte-stack-align` (L*X only)

`-fmath-errno` (L*X only)

`-fno-math-errno` (L*X only)

`-fmerge-debug-strings` (L*X only)

`-fno-merge-debug-strings` (L*X only)

`-fomit-frame-pointer` (L*X only)

`-fno-omit-frame-pointer` (L*X only)

`-fopenmp` (L*X only)

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

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

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

💖 `-fopenmp-default-allocator[=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-do-concurrent-maptype-modifier[=modifier]` (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-do-concurrent` (`L*X only`)

🌸 `-fno-openmp-target-do-concurrent` (`L*X only`)

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

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

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

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

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

🦋 `-fortlib` (L*X only)

🎀 `-fpconstant` (L*X only)

🎀 `-nofpconstant` (L*X only)

🔥 `-fpen` (L*X only)

`-fpe-all=n` (L*X only)

`-fpic` (L*X only)

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

`-fpie` (L*X only)

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

🛡️ `-fstack-protector[-keyword]` (L*X only)

🛡️ `-fno-stack-protector[-keyword]` (L*X only)

🔍 `-fstack-security-check` (L*X only)

🔍 `-fno-stack-security-check` (L*X only)

🌀 `-fstrict-overflow` (for Clang compatibility) (L*X only)

🌀 `-fno-strict-overflow` (for Clang compatibility) (L*X only)