From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16966 invoked by alias); 13 Jan 2005 13:32:07 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 16879 invoked by uid 48); 13 Jan 2005 13:31:58 -0000 Date: Thu, 13 Jan 2005 13:32:00 -0000 Message-ID: <20050113133158.16878.qmail@sourceware.org> From: "corsepiu at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050111163457.19379.joel@gcc.gnu.org> References: <20050111163457.19379.joel@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float X-Bugzilla-Reason: CC X-SW-Source: 2005-01/txt/msg01672.txt.bz2 List-Id: ------- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-13 13:31 ------- (In reply to comment #11) > (In reply to comment #10) > One thing that I notice about this is that -msoft-float and -mhard-float are > no longer inverses. Good point. How about these alternatives: 1. Systematically substitute all occurences of MASK_80387 with (MASK_80387|MASK_FLOAT_RETURN) in i386.h. This would keep -msoft-float and -mno-80387, rsp. -mno-soft-float, -mhard-float and -m80387 as synonyms. IMO, this would be the least intrusive way of a proper fix. 2. Completely eliminate MASK_FLOAT_RETURN and to use MASK_80837, instead. This would be a pretty radical way, I am not sure about its consquences, but I don't expect it to do much harm. 3. Keep -[no-]hard-float, -m[no-]80387 and -m[no-]fp-ret-in-387 as they currently are, but only change soft-float to (MASK_80387|MASK_FLOAT_RETURN) and -mno-soft-float to -(MASK_80387|MASK_FLOAT_RETURN). This would satisfy RTEMS without disturbing other targets/OSes (We'd have to change our multilibs, but this wouldn't be an issue). I'd consider this to be a more a hack than an actual fix ;) 4. Fix the cause of this PR. I.e. prevent GCC from generating FPU code in the case this breakdown occurred. Unfortunately, I don't know the cause nor how to work around it. > Perhaps it would be better to modify override_options to > notice when, after all options are processed, that MASK_80387 is off and then > turn off MASK_FLOAT_RETURNS to match. I don't understand. Could you elaborate? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379