Intrinsic Types and Kinds

The standard kind selector is (kind=expr) or just (expr), where expr is a scalar integer constant expression whose value must be a kind the processor supports (S 7.4.1, constraint C717); selecting a missing kind is a compile-time error (example 15 below). Each of these declares the same 64-bit real on gfortran and Flang, but they are not equally good:

The same applies to the other numeric types: integer(int32), complex(dp), logical(selected_logical_kind(8)). For character the length and kind are combined in the char-selector: character(len=20), character(len=*), character(len=:), allocatable, character(kind=ucs4, len=5); the form character*20 is the obsolescent CHARACTER* form (S B.3.8). A type-param-value of * or : is covered on the characters page.

gfortran can promote default kinds for the whole compilation: -fdefault-real-8 makes default real (and constants such as 1.0) 8 bytes wide and, unless -fdefault-double-8 is also given, promotes double precision to 16 bytes; -fdefault-integer-8 makes default integer and logical 8 bytes wide and the kind of constants like 42; -finteger-4-integer-8 and the -freal-4-real-8 family promote entities declared with an explicit kind. They are useful for compiling legacy code that assumes 8-byte reals, but they change the meaning of the source, break interfaces to libraries compiled without them, and do not protect explicit-kind code. New code should not rely on them; use a kinds module instead. Other vendors have comparable options, listed on Compilers and Compiler Options.

Source: GNU Fortran manual: Options controlling Fortran dialect

A common third-party convention, followed by heatflow, is the kinds module defined as sp = real32, dp = real64, qp = real128 and so on, with the C-interoperable kinds (c_double, c_int, …​) taken from iso_c_binding only at interface boundaries (see Interoperability with C).

Fortran 2023 has no unsigned integer type: every integer kind is signed, huge is its largest value, and the bit-manipulation intrinsics such as iand, shiftl and ibits treat integers as bit patterns. A program that needs unsigned arithmetic therefore uses a wider signed integer (int64 to hold a uint32) or the bit intrinsics (bge, bgt, ble, blt compare as unsigned bit patterns). The iso_c_binding kinds c_int, c_long and so on are signed too, so unsigned C arguments are passed as the signed type of the same width and interpreted with bit operations.

GNU Fortran has an experimental extension, enabled by -funsigned, that adds an unsigned type with its own kinds (selected_unsigned_kind), a u literal suffix and the conversion function uint, following the J3 paper J3/24-116. Arithmetic is modulo 2 to the power of the bit size, mixing with other types needs an explicit conversion, and unsigned values cannot be loop variables or array indices. The gfortran manual says that gfortran’s unsigned integers are compatible with Flang’s. It is not part of Fortran 2023, so it is an extension, not standard-conforming code: the example below is rejected under -std=f2023 and was compiled with -funsigned instead of the -std=f2023 -pedantic set.

Compiled with gfortran -funsigned -Wall -Wextra -fimplicit-none -fcheck=all, not with -std=f2023; output:

Source: GNU Fortran manual: Unsigned integers

The grammar (S 7.4.3.2, R714 to R717) allows a significand with a decimal point, an optional exponent and an optional kind suffix. A real constant without a kind parameter is default real when it has no exponent or the exponent letter E, and double precision when the letter is D. With a kind suffix the exponent letter must be E (constraint C721), so 1.5d3_dp is an error. A kind suffix is either a digit string (non-portable) or a named integer constant.

Output (gfortran 16.2, strict flags; LLVM Flang 23 prints the same unless noted in the text):

The key lesson of the output is the 0.1 versus 0.1_dp trap. The constant 0.1 is a default real constant, correctly rounded to 24 bits, even though it is assigned to a real(dp) variable; the conversion to double precision on assignment cannot restore the lost bits, so wrong holds 0.100000001490116... instead of the double nearest 0.1, wrong from the ninth significant digit on. This is a very common precision bug, and gfortran does not warn about it by default. gfortran offers -Wconversion-extra, which warns about the REAL(4) to REAL(8) conversion in the assignment x = 0.1; LLVM Flang 23 prints a -Wreal-constant-widening warning (shown in the example’s run with Flang) saying that the default real literal in a REAL(8) context "might need a kind suffix". Make the habit automatic: every real constant in code that uses a non-default kind carries its kind suffix, including 0.0_dp, 1.0_dp and 2.0_dp, and the constants in heatflow_constants are written 0.01_dp and so on. The legacy exponent form 0.1d0 is equivalent to 0.1_dp on a processor whose double precision is the kind of dp, but it ties the constant to the compiler’s idea of "double" instead of to the project’s kind, and it is rejected in a context that has both d and a suffix.

The trailing-dot form (3.), the leading-dot form (.5e-3_sp) and an integer significand with exponent (15e2_dp) are all valid real constants. The gfortran-specific exponent letter q (for example 1.0q0) is an extension and -Wreal-q-constant warns about it.

Source: J3/23-007r1, 7.4.3.2 (R714 to R717, C721) and GNU Fortran manual: Options to request or suppress errors and warnings

A related, quantitative demonstration uses heatflow's accumulation of a residual: summing ten million increments of 0.1 in single precision ends 8.8 percent away from the exact total, while double precision is accurate to about 1.6e-10.

Output (gfortran 16.2, strict flags; LLVM Flang 23 prints the same unless noted in the text):

Both compilers print the same numbers. Once the running single-precision sum is large compared with the increment divided by epsilon(1.0_sp), each addition is rounded coarsely, so the error is systematic, not random. Accumulating in real(dp) even from single-precision inputs (the third line) removes the loss and leaves only the conversion error of 0.1_sp. Reductions over large arrays should use an accumulator kind at least as wide as the data, and the intrinsic sum makes no promise about accuracy, so the order of summation matters (see Floating-Point and IEEE Arithmetic).

Source: fortran-lang.org: Best practices, floating point numbers

A complex value is an ordered pair of reals; one kind parameter selects the real kind of both parts (S 7.4.3.3), and there is no double complex keyword in the standard (gfortran accepts it as a non-standard extension). A complex literal is (re, im) where each part is a signed integer or real literal or a named constant; if the parts have different real kinds the constant takes the kind of the more precise part, and if both parts are integers the constant is default complex. The parts are accessed with the designators z%re and z%im (Fortran 2008), with real(z) and aimag(z), and set with cmplx(x, y, kind=dp). The kind argument of cmplx matters: cmplx(1.0_dp, 2.0_dp) without kind= returns a default complex and quietly discards precision. Arithmetic and the elemental mathematical functions (abs, exp, sqrt, conjg) are defined for complex. The storage layout is two consecutive reals, which is what the iso_c_binding kind c_double_complex and C99 double _Complex rely on.

Output (gfortran 16.2, strict flags; LLVM Flang 23 prints the same unless noted in the text):

Source: J3/23-007r1, 7.4.3.3, 7.4.4 and 7.4.5

The logical type has the two values .true. and .false.. Each kind is defined by a storage size, and the kind of a relational result is default logical (S 10.1.9.3). Logical kinds do not convert implicitly to integer: if (n) for an integer n is a type error, and .eqv. and .neqv. are the logical comparison operators; the relational operators such as == apply to numeric and character operands, not to logicals (S 7.4.2, 10.1.5.5). In Fortran 2023 selected_logical_kind(bits) returns the kind with at least that many bits of storage (S 16.9.182), as used in example 9, and logical8 to logical64 give kinds by size. Where the compiler lacks them they are -1 or -2. On this machine gfortran offers the logical kinds 1, 2, 4, 8 and 16 and LLVM Flang 23 offers 1, 2, 4 and 8. Default logical is the size of default integer, so an array of one million default logicals is four megabytes and a one-byte logical kind makes it a quarter of that. The iso_c_binding kind c_bool is for interoperating with C’s _Bool.

A character kind selects a character set: the default kind (kind 1 in gfortran) and, where supported, ASCII and ISO 10646 (UCS-4, kind 4 in gfortran). Each kind has its own literal prefix (ucs4_'heat ') and its own length-1 characters; the intrinsic selected_char_kind finds the kind by name. The storage of character(len=5, kind=ucs4) is 160 bits against 40 for the default kind in example 9 (storage_size). Default-kind strings and ISO 10646 strings are different types that do not mix in assignments or in // concatenation without conversion. The details, including substrings, trim, adjustl, len versus len_trim and I/O of non-default kinds, are on Characters and Strings. Fortran 2023 also gives ? and @ a role in the syntax and raises the line-length limit, which are covered on Program Structure and Source Form.

Source: J3/23-007r1, 7.4.3.3, 7.4.4 and 7.4.5 and GNU Fortran manual: SELECTED_LOGICAL_KIND

The quotient of two integers is an integer: the mathematical quotient truncated toward zero (S 10.1.5.2.2), so -7 / 2 is -3, not -4. mod(a, p) has the sign of a and modulo(a, p) the sign of p, which is why mod(-7, 2) is -1 and modulo(-7, 2) is 1. Raising an integer to a negative integer power is 1 / (x ** abs(n)) in integer division, so 2 ** (-3) is 0. A division of integer constants that truncates triggers the warning -Winteger-division in gfortran, which is why the example uses variables. The classic error is ratio = 1 / 3, which assigns 0, because the integer division happens before the conversion to real; write 1.0_dp / 3.0_dp or real(a, dp) / real(b, dp).

Output (gfortran 16.2, strict flags; LLVM Flang 23 prints the same unless noted in the text):

The fix is to convert an operand to real before dividing, not to convert the quotient (the first printed quotient 3.0000 is the integer quotient converted afterwards).

Source: J3/23-007r1, 10.1.5.2.1 and 10.1.5.2.2, GNU Fortran manual: MOD, MODULO and fortran-lang.org: Best practices, integer division

The result of an integer or real operation that the processor’s arithmetic does not define is prohibited (S 10.1.5.2.4); the standard does not require a diagnostic, and in practice gfortran and Flang wrap around in two’s complement. -fcheck=all checks array bounds, pointers, and other conditions but does not check integer overflow. gfortran’s -ftrapv makes signed overflow abort. This program is intentionally non-conforming and is shown only to illustrate the three behaviours:

Output (gfortran 16.2, strict flags; LLVM Flang 23 prints the same unless noted in the text):

Without any option the result wraps silently, and Flang gives the same output. Compiled with -ftrapv in addition to the strict flags, gfortran aborts at the addition:

(an excerpt; the middle frames are omitted). Compile-time constants are checked: an integer literal or constant expression that does not fit its kind is an error in gfortran and a warning (-Wfolding-exception) in Flang, which then continues with the wrapped value (example 15). The portable defence is to test before you compute: widen to integer(lp) for the product and compare against huge, as example 12 does for heatflow's cell count (50000 * 50000 overflows a 32-bit integer), or call the Fortran 2018 elemental out_of_range(x, mold), which reports whether a value of one type cannot be converted to the type and kind of mold (S 16.9.157). -fno-range-check disables gfortran’s compile-time check and is rarely a good idea.

Source: J3/23-007r1, 10.1.5.2.2, 10.1.5.2.4 and 16.9.157 and GNU Fortran manual: OUT_OF_RANGE

When the operands of a numeric operator differ, the result takes the higher type and the larger kind (S 10.1.9.3): integer with real or complex gives that real or complex kind, two integers of different kinds give the one with the greater decimal exponent range, two reals or complexes give the one with the greater decimal precision. The operand of the lower type is converted first, so n * 0.5 with default integer n is default real, and real(x, dp) * 0.1 is a dp product with a single precision constant, which is exactly the 0.1 trap again. Relational operators return default logical regardless of the operand kinds. The compiler is free to evaluate any mathematically equivalent expression that respects parentheses (S 10.1.5.2.4), which is why a + b + c may be evaluated as a + (b + c) and why summation order can change the last digits; parentheses are honoured and a program can rely on them.

Intrinsic assignment converts a numeric right-hand side to the type and kind of the variable (S 10.2.1.3, Table 10.9): real(expr, kind(var)), int(expr, kind(var)) or cmplx(expr, kind=kind(var)). Converting real to integer in an assignment truncates toward zero, so a -Wconversion warning (enabled by -Wall) is the compiler’s hint. Do it with an explicit intrinsic so the intent is visible.

All of int, nint, floor, ceiling and real accept an optional kind that sets the result kind; without it the result is default integer or default real, so int(1.0e10_dp) overflows a default integer while int(1.0e10_dp, lp) does not.

Output (gfortran 16.2, strict flags; LLVM Flang 23 prints the same unless noted in the text):

The line 123456789 -> real32 -> int shows a lossy round trip: a 24-bit significand cannot hold a 27-bit integer, so the value changes to the nearest representable one (123456792). The tests with out_of_range flag the two conversions that would overflow. cmplx(1, 2, dp) produces the double-precision complex number (1, 2), and int of a complex number silently drops the imaginary part. Each conversion in the output was exactly as the rules predict, in both compilers.

Source: GNU Fortran manual: NINT, FLOOR, INT, ANINT and MODULO; fortran-lang.org: Best practices, type casting and integer division