Ian Lance Taylor wrote: > 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.
I agree. If the inlining thing is indeed a problem (and I can see how it could be, even though you could not immediately reproduce it), then we should mark the call as uninlinable. Disabling an optimization in the face of such a cast seems more user-friendly than inserting a trap. Since we know the code is undefined, we're not pessimizing correct code, so this is not a case where to support old code we'd be holding back performance for valid code. I also agree with Gaby that we should document this as an extension. If we go to the work of putting it back in, we should ensure that it continues to work for the foreseeable future. Part of that is writing down what we've decided. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
