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

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

Ian Lance Taylor <iant@google.com> writes:

> 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.

I realized that I am still not stating my position very clearly.  I
don't think we should make any extra effort to make this code work:
after all, the code is undefined.  I just think 1) we should not
insert a trap; 2) we should not ICE.  That is, we should handle it
just as we handle code like "a[i++] = i++;": caveat lector.

For what it's worth, I tried to recreate the ICE after removing the
trap insertion, but failed.  So I'm not even sure the trap insertion
is fixing a real problem any more.  It works at the moment simply
because it treats the call through a cast as a call through a function
pointer, and therefore does not inline it.

The Objective C frontend does ICE on the test case which Yuri pointed
out, but that ICE is independent of the code in c-typeck.c.  As far as
I can tell in two minutes, that's a type error in the Objective C
frontend: it passes "int d = (double) x;" to the middle-end, and the
middle-end ICEs trying to assign a double value to an int variable.

Ian