Ian Lance Taylor <[EMAIL PROTECTED]> 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
