This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH, PR 45934] Devirtualization aware of dynamic type changes

 > Including copying vtable pointers from one object/type to another?  
 > Or perhaps it isn't?  

 > The C++ language does not talk about vtable, so what exactly what operations 
 > do you refer to by `copying vtable pointers'? 
 I understand the language is somewhat abstract. 
 But there is a machine model, mapping, etc. 
 There is much that the standard deliberately does not address. 
 The operations I refer to are exactly casting, dealing with void*, etc. 
I understand "but I can memcpy whatever" is a big monkey wrench that
might or might not upset people's ideas about meanings and optimization opportunity.
Perhaps it is just invalid.
The crux of the matter, that I brought up, is the assertion:
 > If you like fiddling with bytes and casting, be prepared to
 > be on your own.
For example, consider:
int a = -32767;
a -= 1;
As I understand, per the standard, the behavior of that is undefined.
You could have a 16 bit 1's complement int, and that would overflow,
 and the behavior of overflow is undefined.
 (I wouldn't call it underflow, because the magnitude, not the value,
 got too large, but I could be wrong.)
Are such folks doing that "on their own".
In reality, no. ints tend to be 32 bits or larger, 2's complement,
and they tend to silently overflow w/o extra compiler switches.
So I think somewhere there is a blurry gray line.
Perhaps devirtualization is not near it as I was thinking.
 - Jay 		 	   		  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]