Ryan Hill <[EMAIL PROTECTED]> writes: > Mark Mitchell wrote: > > 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. > > Was there ever any action on this? AFAICS consensus was that the trap > would be removed and this behaviour be documented as an extension. > There was a bit more discussion of how exactly the documentation would > be worded[i] and the thread petered out. Fast forwarding to today the > abort is still present and the 4.2 branch (4.2.0-pre20070317 (rev. > 123016)) is still unable to build a working openssl (0.9.8e).
I don't think anything happened with this. Is there a gcc bug report open about it? If so, Mark can bump up the priority. Ian
