Project

General

Profile

Actions

Defect #755

closed

-0.0 does not match C/C++ bits conversion

Added by Runar Tenfjord about 1 month ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Category:
Oberon Front-End
Target version:
-
% Done:

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

negative_zero.patch (1.75 KB) negative_zero.patch Florian Negele, 29 June 2026 08:41
Actions #1

Updated by Florian Negele about 1 month ago

Thanks for reporting this issue. Which architecture are you targeting?

Actions #2

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

Actions #3

Updated by Florian Negele about 1 month ago

Sorry, I meant the target of the Oberon code.

Actions #4

Updated by Runar Tenfjord about 1 month ago

Target is obadm64.
I will also test obarmt32

Actions #5

Updated by Florian Negele about 1 month ago

The attached patch should fix the issue. Thanks again.

Actions

Also available in: Atom PDF