Casting infinity to an intiger sometimes results in a 0 value(with optimizations enabled)

[FractalFir]

This program(which runs fine under MIRI) produces incorrect results when compiled with cg_gcc.

fn main() {
    let _2 = [true, false, true, true, false];
    let _1 = 0;
    let mut _6 = 0.0;
    let RET = 0.0;
    let mut _3 = 51216f32;
    let mut _4 = _3 * _3;
    let _13 = 0;
    let mut _14 = _4;
    let _20 = &mut _14;
    _4 = *_20 * *_20 * _4;
    _6 = *_20;
    *_20 = _4;
    let mut _28 = 0.0;
    let _41 = &mut _28;
    *_41 = *_20;
    let _39 = *_20 = *_41 * *_41;
    let _12 = *_41 = -*_20;
    _3 = *_41;
    let _57 = *_41;
    let _5 = *_41 = _3 * _6 * -_57;
    let val = *_41;
    let tmp = _28 * val;
    let _78 = tmp as u128;
    println!("{_78:?}");
}

[FractalFir]

After further reduction, all of this is just a very long way of obtaining infinity.

fn main() {
    let mut _4 = 2623078656.0;
    _4 = _4 * _4 * _4;
    let val = -(_4 * _4) * _4 * (_4);
    let inf: f32 = val * val;
    let int = inf as u64;
    println!("{inf:?} {:?} {int:?}", inf.to_bits());
}

With optimizations enabled, GCC will optimize the inf as u64 cast to return 0, instead of u64::MAX.

[bjorn3]

In C this is UB. LLVM used to have it be UB too for a long time, requiring rustc to check for overflow before doing the actual cast, but now there is an intrinsic which saturates on overflow. I guess GCC has the same UB.

[FractalFir]

Huh, I did not expect this to remain uncaught for so long.

cg_clr has a workaround for this, but it looks like cg_gcc does not.

https://github.com/rust-lang/rustc_codegen_gcc/blob/master/src%2Fbuilder.rs#L1212-L1216

I guess we will have to implement a workaround here too. Thankfully, it is a fairly simple thing to do.

There is one thing that concerns me, tough. The x86_64 float to int casts are wrapping, right?

So, with the default settings, this should have tripped way more tests.

This suggests to me that there is a workaround in play already, but it is just broken.

@antoyo does cg_gcc set any flags that could influence this? E.g. do you switch float casts to saturating somehow?

[antoyo]

@antoyo does cg_gcc set any flags that could influence this? E.g. do you switch float casts to saturating somehow?

I do not think so. We set some flags like -fwrapv, but I don't think this would influence this.

Any idea of tests that should fail because of this bug?

[FractalFir]

I would have to check. The more fundamental issue here is wrapping vs saturating casts. I believe that on x86_64 C casts wrap around, while in Rust they saturate. It seems to me like they are saturating(in `cg_gcc`), but in a subtly wrong way. If they were wrapping that should cause almost every file generated by rustlantis to fail. Looking at the generated assembly, I might have a rough idea about the case of the bug.

…

On Fri, May 30, 2025, 20:10 antoyo ***@***.***> wrote: *antoyo* left a comment (rust-lang/rustc_codegen_gcc#690) <#690 (comment)> @antoyo <https://github.com/antoyo> does cg_gcc set any flags that could influence this? E.g. do you switch float casts to saturating somehow? I do not think so. We set some flags like -fwrapv, but I don't think this would influence this. Any idea of tests that should fail because of this bug? — Reply to this email directly, view it on GitHub <#690 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR52NDRXOW3AEQAJFCYSF3D3BCNIXAVCNFSM6AAAAAB6IKP4BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMRTGA3DOOJVGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[FractalFir]

Analyzing the GIMPLE we generate is a bit tough - duplicate block names make it hard to see what is happening.

So, it looks like the "saturation check" is present on the GIMPLE level, the problem just is... it happens after the cast.

 if (_37 < _38) goto then; else goto else;
      then:
      selectVar = 0;
      goto after;
      else:
      _39 = loadedValue2 * loadedValue3;
      _40 = -_39;
      _41 = loadedValue4 * _40;
      _42 = loadedValue5 * _41;
      _43 = loadedValue2 * loadedValue3;
      _44 = -_43;
      _45 = loadedValue4 * _44;
      _46 = loadedValue5 * _45;
      _47 = _42 * _46;
     // That seems wrong???
      selectVar = (size_t) _47;
      goto after;
      after:
      _48 = loadedValue2 * loadedValue3;
      _49 = -_48;
      _50 = loadedValue4 * _49;
      _51 = loadedValue5 * _50;
      _52 = loadedValue2 * loadedValue3;
      _53 = -_52;
      _54 = loadedValue4 * _53;
      _55 = loadedValue5 * _54;
      _56 = _51 * _55;
      _57 = 1.844674297419792384e+19;
      if (_56 > _57) goto then; else goto else;
      then:
      selectVar = 18446744073709551615;

Here, it looks like if the float value > 0, then we cast it to a float, and then check if it is larger than the max int value after the fact(swaping the value out in that case).

Since such a cast is UB if the floating point is out of range, GCC is able to "see" the loaded value can't possibly be larger than max(since that is UB), and removes the branch.

So, it seems like all of the muck at the begining is needed to get GCC to "see" that the branch is impossible.

[FractalFir]

I still don't get why the casts are sometimes saturating in the first place.

A piece of code like this works(is saturating):

  for i in 0..1000 {
        println!("{:?}", i as f32 as u8);
    }

But it should not, since a bit of equivalent C, compiled with GCC, does not(it wraps around).

#include <stdio.h>
#include  <float.h> 
int main()
{
    for (int i = 0; i < 1000; i++)printf("%u\n", (unsigned int)(unsigned char)((float)i));
    return 0;
}

[antoyo]

it happens after the cast.

I do not know if this is the problem here, but that kind of ordering issues can happen because GCC uses an AST-based IR while LLVM uses an instruction-based IR.
Which means that sometimes, we need to explicitly tell GCC to insert some instruction right now (for instance, load the value in a variable right now, instead of just forwarding the value which could be dereferenced in a another basic block).

[FractalFir]

I can't find where that branch is inserted. If it is not inserted by cg_gcc(I am not sure about that), then maybe it is inserted by libgccjit?

[antoyo]

It could be inserted in cg_ssa as well.
I would be surprised if libgccjit inserted that.

[FractalFir]

Never mind, it is in cg_gcc - I just could not find it. And, I immediately see the issue:

rustc_codegen_gcc/src/builder.rs

Line 1841 in 706905b

// 1. Cast val to an integer with fpto[su]i. This may result in undef.

At least the comment here suggests the order of operations(cast then check) is simply wrong.

We can work around this by swapping the order of operations around.

For unsigned casts, maybe could do something clever with clamps or min/max, e.g. (int) min(float_max, max(val, 0,0)) which should result in the correct value, even for infinites and NaN.

[FractalFir]

So, I reimplemented the cast in a way that I think should be fully sound:

// unsigned cast
__attribute__((noinline, visibility ("default")))
size_t cast (<float:32> param0)
{
  size_t D.4016;
  size_t fti_cast_res;

  start:
  _1 = 1.844674297419792384e+19;
  if (param0 > _1) goto gt_max; else goto lt_max;
  lt_max:
  _2 = 0.0;
  if (param0 > _2) goto in_bounds; else goto lt_min;
  in_bounds:
  fti_cast_res = (size_t) param0;
  goto after_cast;
  gt_max:
  fti_cast_res = 18446744073709551615;
  goto after_cast;
  lt_min:
  fti_cast_res = 0;
  goto after_cast;
  after_cast:
  D.4016 = fti_cast_res;
  return D.4016;
}

But it is still broken with optimizations. Can you see anything obviously wrong with this cast?
EDIT:
@antoyo
Could you please reopen the issue?

I got fat fingers, and Github's got some short-cuts I don't know about :(. I can't reopen it myself, sadly.