// Allow call on null pointer
	if (this == 0) return 0;

(gdb) disas
Dump of assembler code for function asCTypeInfo::CastToObjectType():
=> 0x00005555557acc80 <+0>:     mov    eax,DWORD PTR [rdi+0x30]
   0x00005555557acc83 <+3>:     test   eax,0x2000003
   0x00005555557acc88 <+8>:     je     0x5555557acca0 <asCTypeInfo::CastToObjectType()+32>
   0x00005555557acc8a <+10>:    test   eax,0x1000000
   0x00005555557acc8f <+15>:    mov    eax,0x0
   0x00005555557acc94 <+20>:    cmove  rax,rdi
   0x00005555557acc98 <+24>:    ret    
   0x00005555557acc99 <+25>:    nop    DWORD PTR [rax+0x0]
   0x00005555557acca0 <+32>:    xor    eax,eax
   0x00005555557acca2 <+34>:    ret

Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). As a temporary work-around -fno-delete-null-pointer-checks can be used. Wrong code can be identified by using -fsanitize=undefined.

It would be easier to understand if you'd posted the full code instead of just that one line. There is definitely a test there which, if successful, jumps to the end and returns zero. (That's the xor eax,eax bit - anything xored with itself becomes zero.) No idea why the value there is 0x2000003 but maybe someone more competent in this area can explain.

Why do you need to do this anyway? Why not having it as a free-standing function which checks for null directly?

Afaik, standard C++ only defines existence of 'this' inside a method. The GNU compiler at least added 'this' also outside methods, where it is(was?) a null pointer.

I never understood how this is ever useful, but maybe it was normal in one of the very first implementations, before there was a proper C++ compiler.

It looks like they are now removing that extension.

I read an article a while back about compilers treating this == null comparisons as always being false because calling a member function on a null pointer is considered undefined (?) behavior. It's probably removing the if statement altogether.

maybe there is a bug in GCC (as said that kDevelop and qt and chromium have problem with it)

It's not a bug.

Mentioned sw was relying on compiler's specific behavior while walking through the minefield of Undefined Behavior.

It was a matter of time when that mine would explode.