summary refs log tree commit diff
path: root/debug/fgetws_u_chk.c
diff options
context:
space:
mode:
authorMarius Hillenbrand <mhillen@linux.ibm.com>2020-11-30 15:53:59 +0100
committerStefan Liebler <stli@linux.ibm.com>2020-12-09 16:26:46 +0100
commitf88242af19dc970949806790f70c6fd6336944a6 (patch)
tree5dbc966ce8356ff8b3f5515f151f2c7de4e61f7e /debug/fgetws_u_chk.c
parentb5eeca8cfd9d0fd92b5633a88901d9ff27f2b496 (diff)
downloadglibc-f88242af19dc970949806790f70c6fd6336944a6.tar.gz
glibc-f88242af19dc970949806790f70c6fd6336944a6.tar.xz
glibc-f88242af19dc970949806790f70c6fd6336944a6.zip
S390: Derive float_t from FLT_EVAL_METHOD
float_t supposedly represents the type that is used to evaluate float
expressions internally. While the isa supports single-precision float
operations, the port of glibc to s390 incorrectly deferred to the
generic definitions which, back then, tied float_t to double. gcc by
default evaluates float in single precision, so that scenario violates
the C standard (sections 5.2.4.2.2 and 7.12 in C11/C17). With
-fexcess-precision=standard, gcc evaluates float in double precision,
which aligns with the standard yet at the cost of added conversion
instructions.

With this patch, we drop the s390-specific definition of float_t and
defer to the default behavior, which aligns float_t with the
compiler-defined FLT_EVAL_METHOD in a standard-compliant way.

Checked on s390x-linux-gnu with 31-bit and 64-bit builds.
Diffstat (limited to 'debug/fgetws_u_chk.c')
0 files changed, 0 insertions, 0 deletions