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

[Jay K <jay dot krell at cornell dot edu>]

> > The operations I refer to are exactly casting, dealing with void*, etc.
>
> casting exactly what to void*. and exactly what do you mean by
> "dealing with void*"?
 
 
 
Specifically, something like:
 
 
#include <string.h>
#include <stdio.h>
 
struct Base { virtual void F1() { printf("Base\n"); } };
struct C1 : Base { virtual void F1() { printf("C1\n"); } };
struct C2 : Base { virtual void F1() { printf("C2\n"); } };
 
 
int main()
{
 C1 c1;
 C2 c2;
 Base* b = &c2;
 b->F1();
 memcpy(&c2, &c1, sizeof(c1));
 b->F1();
 return 0;
}

 
Can the compiler do the dataflow to know that b is always of type C2
and ignore memcpy and generate code to print C2\nC2\n?
Or should it print C2\nC1\n?
 

> > (I wouldn't call it underflow, because the magnitude, not the value,
> > got too large, but I could be wrong.)
>
>
> but you don't get to define the language semantics either :-)
 
 
(In this case I'm willing to lookup and accept conventional wisdom. :) )
 

> oh yeah, people counting on overflow are setting up themselves
> to be surprised -- and that has happened.
 
 
 
I know. I thought I alluded to my awareness -- I thought it required
certain switches. Perhaps I was confusing it with switches to
turn it off or to get the warnings. I did run -Wstrict-overflow=4 or such
on some code and fixed it to use unsigned to fix the warnings.
Stuff about distributing minus across division.
Still, it's a somewhat dangerous change to give existing code non-silent overflow.
(or rather, I realize runtime overflow remains predominantly silent,
but the compiler is taking advantage of the fact that it might be not silent, and
so on; my wording is poor here, but I do understand...)
 
 
 
I've also written code to check for overflow, and it depended on silent overflow.
Sometimes there is a bit of an arms race between the compiler and the programmer.
That's just how it is. Ok.
People's understandings of using of said understandings continue to increase.
 
 
I actually have some thinking that:
int a = 60000;
 
 
should generate a warning. That the code isn't
portable to other targets.
But it's ultimately probably not worthwhile.
So put it under a switch? Nobody would use it.
 
 
You know, typically compilers warn only in the context of the current
target, not in the context of the more abstract standard.
(Gcc's warning about long strings is a notable counterpoint.)
 
 
Heck, a crazier extreme would be that gcc could warn about code
known to miscompile with older gcc. A sort of "portability warning".
Would be very costly to implement. And little used.
 
 
(I'm reminded of the recent assertion that if you disabled
any optimization that had bugs in any version of gcc,
you wouldn't be left with any!)
 

> > 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.
>
> you are entitled to your opinion, but not to your facts.
> The semantics of `int' is not just what your ultimate hardware
> deliver. It is what the language semantics is (plus what latitude
> the compiler chose to exploit.)
>
> >
> >
> > So I think somewhere there is a blurry gray line.
>
> you may be in a blurry gray line; I don't believe the language
> is for the particular topic at hand. You may deny it. But that won't
> change anything.
 
 
 
Well, I am just not sure, and raising the question.
I don't mean to insist -- any repetition was meant as clarification? :)
 
 
 
"Hey, interesting point about constructors/destructors changing
vtable pointer (or abstract type). What about memcpy?"
 
 
 
 - Jay