While chasing butterflies recently, I noticed the code generated by clang didn't match what was created by MSVC and ICC (but does match what gcc was emitting). Here's a simplified C++ example:
void *operator new( unsigned int size ); // note, non-throwing
class Test {
void *data;
};
int main( void ) {
Test *t = new Test();
return (int)t; // ignore this, it's to trick the optimizer
}
This would produce the following assembly:
_main: # @main
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %eax
movl $4, (%esp)
calll __Znwj
movl $0, (%eax) # this is a problem, I think
addl $4, %esp
popl %ebp
ret
After the call to operator new, the assumption is that eax will be
non-null, which isn't a valid assumption. MSVC and ICC generate code
that performs a test for null before performing the initialization.
So clang's code will crash if operator new returns null.
My first question is: do you agree that we should be producing a null
check before initializing the members?
I've attached a patch that's my first attempt at changing this
behavior, and I'm looking for comments on whether it's the right
approach, or if there's a better way (even if it's not considered
behavior we want to change -- I'm using it as a learning experience
with the codegen).
Thanks!
~Aaron
null_check.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
