Re: gcc 4.2 more strict check for "function called through a non-compatible type"

[Ian Lance Taylor <iant at google dot com>]

Andrew Haley <aph@redhat.com> writes:

>  > > keating> Because if you *do* try to inline the call, you will get an ICE.
>  > 
>  > Yes, I agree that the ICE, if it still exists, would have to be fixed,
>  > but to me that seems like a separate issue.
> 
> No, it isn't a separate issue.  We generate an abort rather than
> ICEing.

My point is simply that the ICE is from a completely different part of
the compiler than the point where we insert the trap.

>  > > We could allow this iff someone fixes the ICE.  But we've
>  > > provided a union cast to do the work if it's *really* needed;
>  > > insn't that enough?
>  > 
>  > I don't think gcc should go down the path of inserting trap calls for
>  > all undefined code.
> 
> That is a pretty outrageous strawman.  Nobody has suggested anything
> like that.

I apologize for presenting something which appears to be a strawman
argument.  That would never be my intent.  Let me restate: I don't
think gcc should ever insert a trap call for undefined code.  We
should only insert a trap call for code which will provably trap.

>  > That is reasonable if there is nothing else that can be done.  But
>  > in this case there is something easy to do: compile the function
>  > call as directed.
> 
> If indeed that's easy to do, yes.  But I'm pretty confident the abort
> wouldn't have been inserted if that were the case.

When I read the original e-mail thread that did not seem to be the
case.

> If we're going to guarantee this stuff for the future, we'll have to
> fix the bug, make sure it's doesn't destabilize the compiler and write
> some test cases.  If we're really serious about it we should make it a
> documented extension to C.  I'm not exactly opposed to that, but I do
> wonder if it's the best use of people's time.  But this is free
> software, and people choose their own priorities.

We're currently breaking an existing free software program which
formerly worked although it relied on undefined behaviour.  Therefore,
I think that changing this would not be a complete waste of time.
Obviously I would never ask anybody else to work on it.

I personally don't agree that this needs to be a documented extension.
I'm simply going on a more general rule which I tried to state above:
I don't think we should insert a trap call for undefined code.

Ian