aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/ObjCopy/ELF/ELFObject.cpp
diff options
context:
space:
mode:
authorPeter Klausler <pklausler@nvidia.com>2025-08-13 14:36:13 -0700
committerGitHub <noreply@github.com>2025-08-13 14:36:13 -0700
commit442ae603c5497e2829236fc851291ee8bb417a97 (patch)
tree71ede094fce53a7e74115b5c23b9affbcdc3f30f /llvm/lib/ObjCopy/ELF/ELFObject.cpp
parentc5105c1e0a38671545a092c036b631e30d2e45b4 (diff)
downloadllvm-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