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

[Ryan Hill]

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)