Possible inlining bug
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 3.4k
- Forks
- 126
- PR merge metrics
- No merged PRs in 30d
Description
It seems that this function has different results depending on whether or not #[inline(always)] is used:
/// Return `1.0` when `value` is less than or equal to `edge`
/// and `0.0` when `value` is greater than `edge`.
#[inline(always)]
pub fn step_le(value: f32, edge: f32) -> f32 {
((value <= edge) as u32) as f32
}
I have a shader you can see here that uses this function.
Expected Behaviour
Using ((sphere_aabb.max.z <= 1.0) as u32) as f32, which is a manual inlining of the body of the function, produces the expected results.
Using crate::math::step_le(sphere_aabb.max.z, 1.0) while having an #[inline(always)] annotation on step_le produces the expected results.
Using crate::math::step_le(sphere_aabb.max.z, 1.0) without having an #[inline(always)] annotation on step_le produces the opposite of the expected result.
Example & Steps To Reproduce
I can work on a minimal reproducible shader.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the shader in crates/renderling/src/debug.rs at the linked lines and trace its use of crate::math::step_le. Create the minimal reproducible shader mentioned in the issue, comparing manual inlining, #[inline(always)], and no inline annotation; done means the differing result is reproduced and the behavior is corrected or clearly isolated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, computer-graphics
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 42/100