diff options
author | Peter Klausler <pklausler@nvidia.com> | 2025-08-13 14:36:13 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-08-13 14:36:13 -0700 |
commit | 442ae603c5497e2829236fc851291ee8bb417a97 (patch) | |
tree | 71ede094fce53a7e74115b5c23b9affbcdc3f30f /llvm/lib/ObjCopy/ELF/ELFObject.cpp | |
parent | c5105c1e0a38671545a092c036b631e30d2e45b4 (diff) | |
download | llvm-442ae603c5497e2829236fc851291ee8bb417a97.zip llvm-442ae603c5497e2829236fc851291ee8bb417a97.tar.gz llvm-442ae603c5497e2829236fc851291ee8bb417a97.tar.bz2 |
[flang] Warn about inexact real literal implicit widening pitfall (#152799)
When a REAL or COMPLEX literal appears without an explicit kind suffix
or a kind-determining exponent letter, and the conversion of that
literal from decimal to binary is inexact, emit a warning if that
constant is later implicitly widened to a more precise kind, since it
will have a different value than was probably intended.
Values that convert exactly from decimal to default real, e.g. 1.0 and
0.125, do not elicit this warning.
There are many contexts in which Fortran implicitly converts constants.
This patch covers name constant values, variable and component
initialization, constants in expressions, structure constructor
components, and array constructors.
For example, "real(8) :: tenth = 0.1" is a common Fortran bug that's
hard to find, and is one that often trips up even experienced Fortran
programmers. Unlike C and C++, the literal constant 0.1 is *not* double
precision by default, and it does not have the same value as 0.1d0 or
0.1_8 do when it is converted from decimal to real(4) and then to
real(8).
Diffstat (limited to 'llvm/lib/ObjCopy/ELF/ELFObject.cpp')
0 files changed, 0 insertions, 0 deletions