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

[Ian Lance Taylor]

Ryan Hill <dirtyepic@gentoo.org> 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