Defect #755
closed-0.0 does not match C/C++ bits conversion
100%
Description
Consider the following code:
MODULE Test;
IMPORT SYSTEM;
PROCEDURE ReinterpretBits(val : REAL32): UNSIGNED32;
BEGIN RETURN SYSTEM.VAL(UNSIGNED32, val)
END ReinterpretBits;
BEGIN
TRACE(ReinterpretBits(-0.0)); (* Does not match C *)
TRACE(ReinterpretBits(+0.0));
TRACE(ReinterpretBits(-1.0));
TRACE(ReinterpretBits(+1.0));
TRACE(ReinterpretBits(-2.0));
TRACE(ReinterpretBits(+2.0));
END Test.
which outputs:
Test.mod:13:26: note: 'ReinterpretBits (-0.0)' = 0
Test.mod:14:26: note: 'ReinterpretBits (+0.0)' = 0
Test.mod:15:26: note: 'ReinterpretBits (-1.0)' = 3212836864
Test.mod:16:26: note: 'ReinterpretBits (+1.0)' = 1065353216
Test.mod:17:26: note: 'ReinterpretBits (-2.0)' = 3221225472
Test.mod:18:26: note: 'ReinterpretBits (+2.0)' = 1073741824
Corresponding C code:
#include <stdio.h>
#include <stdint.h>
static uint32_t ReinterpretBits(float source)
{
union {
float f;
uint32_t u;
} fu;
fu.f = source;
return fu.u;
}
int main() {
printf("%u\n", ReinterpretBits(-0.0));
printf("%u\n", ReinterpretBits(+0.0));
printf("%u\n", ReinterpretBits(-1.0));
printf("%u\n", ReinterpretBits(+1.0));
printf("%u\n", ReinterpretBits(-2.0));
printf("%u\n", ReinterpretBits(+2.0));
}
which outputs:
2147483648
0
3212836864
1065353216
3221225472
1073741824
It seems that the value -0.0 ignores the - sign which is significant for REAL type.
Files
Updated by Florian Negele about 1 month ago
Thanks for reporting this issue. Which architecture are you targeting?
Updated by Runar Tenfjord about 1 month ago
Hello. This was tested with GCC:
$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/16/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues --with-build-config=bootstrap-lto --with-gcc-major-version-only --with-linker-hash-style=gnu --with-system-zlib --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-fixincludes --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 16.1.1 20260625 (GCC)
I can check additional platforms I have access to tomorrow.
Brgds
Updated by Florian Negele about 1 month ago
Sorry, I meant the target of the Oberon code.
Updated by Runar Tenfjord about 1 month ago
Target is obadm64.
I will also test obarmt32
Updated by Florian Negele about 1 month ago
- File negative_zero.patch negative_zero.patch added
- Status changed from New to Closed
- % Done changed from 0 to 100
The attached patch should fix the issue. Thanks again.