On 1/18/25 2:41 PM, Palmer Dabbelt wrote:
Ya, and thanks for the help. For anyone else watching, the rest is over
here:
https://inbox.sourceware.org/libc-alpha/78a20579-2d29-4b3b-
af94-434dde755...@rivosinc.com/ (inbox.sourceware.org doesn't seem to
handle threading across lists) -- it certainly looked like a glibc issue
at first, so it ended up over there.
On a sort of related note: last night/this morning I realized that if
calling into glibc with RMM set is UB, then aren't we going to open
ourselves up issues like getting a signal in the middle of an inlined
__builtin_{l,}round() expansion? Maybe fast-math/sigals are far enough
down the rabbit hole nobody cares, though?
I believe it is considered invalid to call into the various libraries
with a different rounding mode set -- I'm pretty sure the libraries
don't set the rounding modes explicitly unless they're doing something
special and know they need non-default rounding semantics.
Essentially we wouldn't want to take the penalty to ensure a rounding
mode as we enter the math libraries for the relatively rare case that
the user's code has set a non-standard rounding mode.
I don't *think* the RV backend changes the rounding mode anywhere unless
the user has explicitly asked for it - at which point I think it's on
the user to make sure it's safe to do so.
jeff
