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.

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

False warnings on unsigned integer overflow #4210

Closed
igor-elovikov opened this issue Feb 4, 2022 · 1 comment · Fixed by #4224
Closed

False warnings on unsigned integer overflow #4210

igor-elovikov opened this issue Feb 4, 2022 · 1 comment · Fixed by #4224
Labels
potential bug Something that looks like a bug but not yet confirmed

Comments

@igor-elovikov
Copy link

Describe the bug
Weird warnings about unsigned integer exceeding the range

To Reproduce

import taichi as ti

ti.init(arch=ti.gpu)

@ti.kernel
def u32_test():
    x: ti.u32 = 2891336453
    print("x = ", x)

u32_test()

Log/Screenshots

[Taichi] version 0.8.11, llvm 10.0.0, commit 9d0973e5, win, python 3.7.8
[Taichi] Starting on arch=cuda
[W 02/04/22 20:57:53.169 24856] [impl.py:_clamp_unsigned_to_range@395] Constant 2891336453 has exceeded the range of 32 int, clamped to -1403630843
x =  2891336453

Additional comments
It wasn't actually clamped and kernel works correctly as far as I can tell, so basically it's just about false warnings

@igor-elovikov igor-elovikov added the potential bug Something that looks like a bug but not yet confirmed label Feb 4, 2022
@ailzhang
Copy link
Contributor

ailzhang commented Feb 7, 2022

Thanks for reporting! This warning is produced since we created x first as i32 and then cast it to u32. so the warning was actually for the first cast. We'll look into a fix to create annotated x properly.

ailzhang pushed a commit to ailzhang/taichi that referenced this issue Feb 7, 2022
Fixes taichi-dev#4210

This PR also simplifies the clamping logic by:
1. Make sure constant is valid in range of specified dtype.
2. Always use int64/float64 to communicate between python and C++ and
converts it to the specified dtype in C++. This is just to avoid
handling each dtype on both python and C++ side.
ailzhang pushed a commit to ailzhang/taichi that referenced this issue Feb 7, 2022
Fixes taichi-dev#4210

This PR also simplifies the clamping logic by:
1. Make sure constant is valid in range of specified dtype.
2. Always use int64/float64 to communicate between python and C++ and
converts it to the specified dtype in C++. This is just to avoid
handling each dtype on both python and C++ side.

We might consider further improve it by moving this logic from python to C++ in the future and this PR made it a step closer.
ailzhang pushed a commit to ailzhang/taichi that referenced this issue Feb 7, 2022
Fixes taichi-dev#4210

This PR also simplifies the clamping logic by:
1. Make sure constant is valid in range of specified dtype.
2. Always use int64/float64 to communicate between python and C++ and
converts it to the specified dtype in C++. This is just to avoid
handling each dtype on both python and C++ side.

We might consider further improve it by moving this logic from python to C++ in the future and this PR made it a step closer.
ailzhang pushed a commit to ailzhang/taichi that referenced this issue Feb 8, 2022
Fixes taichi-dev#4210

This PR also simplifies the clamping logic by:
1. Make sure constant is valid in range of specified dtype.
2. Always use int64/float64 to communicate between python and C++ and
converts it to the specified dtype in C++. This is just to avoid
handling each dtype on both python and C++ side.

We might consider further improve it by moving this logic from python to C++ in the future and this PR made it a step closer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
potential bug Something that looks like a bug but not yet confirmed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants