[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 6.2.6.1 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 
storage:

   http://queue.acm.org/detail.cfm?id=3041020

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.

John


More information about the llvm-dev mailing list