[llvm-dev] function inlining and undef / poison question
John Regehr via llvm-dev
llvm-dev at lists.llvm.org
Fri Jun 16 08:12:11 PDT 2017
Trap representations are primarily just a funny way to say undefined
behavior, see 22.214.171.124 p5 of C99:
"Certain object representations need not represent a value of the object
type. If the stored value of an object has such a representation and is
read by an lvalue expression that does not have character type, the
behavior is undefined. If such a representation is produced by a side
effect that modifies all or any part of the object by an lvalue
expression that does not have character type, the behavior is undefined.
Such a representation is called a trap representation."
Here's a reasonable discussion of the issues surrounding uninitialized
This is definitely a sucky part of the standards and I hope they manage
to clear it up.
However, none of this causes problems for us at the LLVM level. Whatever
it is that reading uninitialized storage means (and I am uninterested in
debating this further, at least on this list), we almost certainly have
a mechanism for expressing that in LLVM. Thus, as far as I can tell,
there is no problem here.
More information about the llvm-dev