Generally speaking, as a user of a language, stuff should just work while providing identical results to the target arch.
Which means that when cross compiling from x86 to ARM, if lets say, transcendentals provide different results then always the target archs implementations should be used, even if they have to be emulated.
If however, hypothetically, different x86 CPUs produce different results for transcendentals, and we can't control where the user will run our program, then imo the correct solution for the language is to provide a set of knobs for the user to communicate whether they favor accuracy or speed in this scenario. - but we can say there's no 'correct' decision in this case, only tradeoffs.
Forbidding transcendentals is not a correct decision as it adds a ton of compiler complexity (you have to track which functions use them transitively), and baffling UX - the user finds that comptime doesn't work because the function he uses might use transcendentals somewhere down the chain.
The responsible approach is to wait before stabilizing a language feature until a consensus is reached and until we are confident we will not have to roll back or change the feature and break existing code. This is what Rust does.
The discussion how to deal with transcendentals in Rust is ongoing and at some point there will be a conclusion.