Skip to content

(potential?) bug: AVR - Incorrect f64 handling #118079

Closed
rust-lang/compiler-builtins
#558
@onkoe

Description

@onkoe

Hi there! I encountered a weird situation when writing a device driver using embedded-hal. Despite getting correct temperature readings in byte form from my thermocouple converter, all readings were incorrect after casting them to f64 floats and applying some fundamental transformations.

After much confusion, I tried using f32 instead and found it worked perfectly!

However, I knew the transformations should be correct either way: I tested this exact setup and formula using Linux and the spidev crate.

That led me to test those transformations on a few different machines. Please take a look at the results below to gain better insight.

If there's any additional context I can give, or checking to be done, please let me know, and I'll happily look into it!

Also, I did check the ufmt_float crate to see if it was working properly! I assume that since the f64 as u32 and ufmt_float'd f64are the same, it must be an issue with f64 itself. Please see the source and serial output of the original test to get more info.

Thank you for taking a look at my problem!

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.O-AVRTarget: AVR processors (ATtiny, ATmega, etc.)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions