Repository navigation
long double varargs won't compile #154
Description
Activity
f128is implemented in its crate as#[repr(C)] #[derive(Clone, Copy)] pub struct f128(pub(crate) [u8; 16]);
At first I thought the fix was as simple as enabling
VaArgSafefor aggregates, but looking at the rustc backend I now realize thatva_argis only implemented for scalars, so the compiler would crash with an ICE for any aggregate. To fixf128, we'd need to implement full aggregate support forva_argin rustc.Edit: the problem is that the current variadics implementation in rustc lowers Rust
va_argdown to LLVMva_arg, which doesn't support aggregates. clang gets around this by manually implementingva_argitself using memory operations.- changed the title
[-]Long double varargs won't compile[/-][+]`long double` varargs won't compile[/+]on Jun 29, 2022 f128is implemented in its crate as#[repr(C)] #[derive(Clone, Copy)] pub struct f128(pub(crate) [u8; 16]);
Why wouldn't
f128be implemented usingu128? Doesn't[u8; 16]have the wrong alignment?bindgenusesu128forlong double(ifu128is supported). Ifu128is used as the underlying type, does that fix this issue, asu128is a scalar?Also, rust-lang/rust#61126 seems to be about unsized types, but
f128and[u8; 16]aren't unsized.rust-lang/rfcs#2580 is also now merged, if that was a blocker for rust-lang/rust#61126.
bindgen uses u128 for long double
From rust-lang/rust-bindgen#1549 it sounds like they're not entirely happy with that either.
Why wouldn't f128 be implemented using u128?
IMHO the real problem is that variadics are part of
core, but there is no "official"f128equivalent in Rust. The language and the standard library would first have to pick one, and then add variadics support for it. Thef128type that C2Rust uses (or used, not sure we do anymore) is from an external crate.You could define
f128as a newtype overu128, but I'm not sure that would get accepted intocore.Wow, I didn't realize
{u,i}128was not FFI-safe and that LLVM misaligns it to 8 bytes, not 16 (so it would have the wrong alignment forf128, but then so do{u,i}128).I think the best way to support this would be to get a
c_long_doubleadded inlibc(hopefully that happens one day), as what we want to do is match the Clong doubleanyways, andlong doubleis not alwaysf128(__float128would be different, and would always bef128). But I'm not sure whatlibc's definition forc_long_doublewould be.I also saw that
libmis missing the*lfunctions that operate onlong doubles.The RFC for
f{16,128}got accepted? Awesome!Reacted by Christian Legnitto
Blocked on improved rustc support for arbitrary structs/types, possibly rust-lang/rust#61126