On Mon, Feb 27, 2023 at 09:54:06PM +0100, Jakub Jelinek wrote: > Even if the target-independent code doesn't know what the target dependent > code will do, I don't see how it could emit it safely.
I always understood RTL to not have anything like C "undefined behavior", but be closer in general (exceptions are integer division by zero etc.) to C's "unspecified value". This is quite close to what on Power we call "boundedly undefined": The results of executing a given instruction are said to be boundedly undefined if they could have been achieved by executing an arbitrary finite sequence of instructions (none of which yields boundedly undefined results) in the state the processor was in before executing the given instruction. Boundedly undefined results may include the presentation of inconsistent state to the system error handler as described in Section 1.8.1 of Book II. Boundedly undefined results for a given instruction may vary between implementations, and between different executions on the same implementation. So no trapping, everything writes all bits in all registers always, etc. C undefined behaviour makes the *whole program* undefined, always: it can have effects reaching unlimitedly far into the future, but also unboundedly far into the past (well, not further back then program start, there is that :-) ). RTL unspecified stuff is way more limited than that. It also has a very different goal: C UB is to allow compilers to optimise more programs and to optimise them better, while for RTL we simply do not specify the operation result in some cases. This does not mean such cases cannot happen! And of course there are TARGET_SHIFT_COUNT_TRUNCATED and TARGET_SHIFT_TRUNCATION_MASK, which allow to make more inputs result in known (to the compiler) outputs. Segher
