This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
- From: Ryan Hill <dirtyepic at gentoo dot org>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Andrew Haley <aph at redhat dot com>, Yuri Pudgorodsky <yur at ptci dot ru>, gcc at gcc dot gnu dot org
- Date: Wed, 21 Mar 2007 21:56:28 -0600
- Subject: Re: gcc 4.2 more strict check for "function called through a non-compatible type"
- Newsgroups: gmane.comp.gcc.devel
- References: <44AA67AE.4070509@ptci.ru> <m3lkr9e1h1.fsf@localhost.localdomain> <17578.43651.892156.272070@zebedee.pink> <m3d5cldsl8.fsf@localhost.localdomain> <17579.35051.492454.869315@zebedee.pink> <m3zmfocfb1.fsf@localhost.localdomain> <m3wtasytkb.fsf@localhost.localdomain> <44AC95B9.9000001@codesourcery.com>
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)