Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

UB in the implementation of the 128 bit ctlz intrinsic #604

Open
FractalFir opened this issue Jan 22, 2025 · 3 comments · May be fixed by #635
Open

UB in the implementation of the 128 bit ctlz intrinsic #604

FractalFir opened this issue Jan 22, 2025 · 3 comments · May be fixed by #635
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@FractalFir
Copy link

Originally discovered by running compiler tests with -Cllvm-args=santize-undefined.

Running the following piece of code:

#[no_mangle]
fn ub()->u32{
    black_box(1_u128).leading_zeros()
}

will trip UB checks. This is caused by an improper implementation of the 128 bit ctlz intrinsic. Currently, this intrinsic first checks if the argument is not 0, and then counts the leading zeroes in the high and low 8 bytes of the value - separately.

This is incorrect: if either the low xor the high bytes are zero, then counting the leading zeroes in those 8 byte numbers is UB.

Here is the relevant part of GIMPLE, which shows the underlying issue:

  if (param0 == 0) goto then; else goto else;
      then:
      zeros = 128;
      goto after;
      else:
      _2 = param0 >> 64;
      _3 = (size_t) _2;
      _4 = __builtin_clzll (_3);
      _5 = (uint128_t) _4;
      count_loading_zeroes_results[0] = _5;
      _6 = (size_t) param0;
      _7 = __builtin_clzll (_6);

In the case of param0 = 1_u128, the top if will jump to else. There, the value _2 will be zero(the high 8 bytes of 1_u128 are zero). This means that the value of _3 will also be zero, and on this line:

_4 = __builtin_clzll (_3);

__builtin_clzll will be called with an argument of 0, which is UB.
@antoyo antoyo added bug Something isn't working good first issue Good for newcomers labels Jan 22, 2025
@dvermd
Copy link

dvermd commented Feb 18, 2025

I'd like to try to solve this one to get started.
I found what I think is the implementation in src/intrinsic/mod.rs. The first part is fn codegen_intrinsic_call and the other part in fn count_leading_zeros.

One thing I don't know is how to test the changes I will make.
How to run the compiler tests with -Cllvm-args=santize-undefined ?
How to view the update GIMPLE output ?
Is there a smaller test than the whole compiler tests suite to check the behaviour ?

@antoyo
Copy link
Contributor

antoyo commented Feb 19, 2025

How to run the compiler tests with -Cllvm-args=santize-undefined ?

You can just create a normal Rust project with cargo new and compile it with:

y cargo rustc --bin test-rust -- -Cllvm-args=-fsanitize=undefined -Clink-args=-lubsan

How to view the update GIMPLE output ?

There are many environment variables as you can see in the readme.
The one to output GIMPLE is CG_GCCJIT_DUMP_GIMPLE.

Is there a smaller test than the whole compiler tests suite to check the behaviour ?

Putting the ub function from the above post in a new cargo project that calls this function should be enough.

@dvermd
Copy link

dvermd commented Feb 19, 2025

There are many environment variables as you can see in the readme.
The one to output GIMPLE is CG_GCCJIT_DUMP_GIMPLE.

That's the part I was missing. I figured out the new project with the ub function. Thanks for the tip.

@dvermd dvermd linked a pull request Feb 21, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix 128bits ctlz intrinsincs UB dvermd/rustc_codegen_gcc
3 participants
@dvermd @antoyo @FractalFir