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 apologize for bringing this up so late in the release cycle. I only found this discussion today while searching for some solution to our openssl issue, which i believe is the only blocker we have left as far as being gcc-4.2 ready. [i] http://permalink.gmane.org/gmane.comp.gcc.devel/80366 -- where to now? if i had to guess dirtyepic gentoo org i'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)
