From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22364 invoked by alias); 29 Aug 2011 14:33:40 -0000 Received: (qmail 22345 invoked by uid 22791); 29 Aug 2011 14:33:38 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Aug 2011 14:33:15 +0000 From: "martin at decky dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function Date: Mon, 29 Aug 2011 15:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: martin at decky dot cz X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2011-08/txt/msg02309.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49606 --- Comment #4 from Martin Decky 2011-08-29 14:33:07 UTC --- (In reply to comment #3) > As well as making longs 64 bits wide, -mlong64 makes > pointers 64 bits wide. But you're still using a > 32-bit file format. If you want an LP64 ABI, > then n64 seems like a better choice. Yes, this is indeed the most reasonable solution for me. > So do you actually have a system that uses this ABI > (o64+mlong64)? Actually, no. I was trying to cross-compile our own OS for mips64 and the o64+mlong64 combination was the first one I have tried. The 32-bit file format might or might not be eventually a problem if the compilation works (I can imagine that it might actually work fine at least for user space binaries). But the n64 ABI seems definitively to be a better choice. > If so, could you give a few more details? > TBH, my instinctive reaction is that this is a missing > diagnostic bug, and that we should refuse to compile > -mabi=o64 -mlong64. Well, I do not insist that this bug should be fixed only by making the compilation work. Your suggestion that this combination of options is not very reasonable and should be refused is sound. Either way, the compiler should not end with an internal error.