From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24144 invoked by alias); 26 Mar 2007 04:33:59 -0000 Received: (qmail 24112 invoked by uid 48); 26 Mar 2007 04:33:49 -0000 Date: Mon, 26 Mar 2007 04:33:00 -0000 Subject: [Bug other/31359] New: 4.2 branch still generates abort for function casting X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dirtyepic at gentoo dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-03/txt/msg02420.txt.bz2 The eventual consensus of the ml thread "gcc 4.2 more strict check for "function called through a non-compatible type" [1]: 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 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 this weekend 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. [1] http://gcc.gnu.org/ml/gcc/2006-07/msg00037.html -- Summary: 4.2 branch still generates abort for function casting Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dirtyepic at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359