This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [x86-64 PATCH] PR target/26223: x86-64 ABI vs -mno-80387

> Hi Honza,
> The following patch resolves PR target/26223 which is an ICE on invalid
> caused by compiling code to return long doubles on x86_64 when the user
> explicitly specifies -mno-80387.  The problem is not in the splitters or
> the machine description, but in the ABI machinery that insists that
> XFmode be returned in REGNO 8, i.e. FIRST_STACK_REG, which isn't available
> with -mno-80387.
> One possible fix, for some point in the future?, is to change the code
> in the i386 backend to instead use REGNO 0 in these cases, but this
> would change the ABI and need to documented/ratified in the x86-64
> ABI specification.
> The alternative approach, implemented below, is to do the same for
> -mno-80387 as we do for -mno-sse, and issue an error if a function's
> prototype ever conflicts with the allowable registers.  This is useful
> for building the kernel with -mno-80387 and -mno-sse, which will warn
> if the programmer makes a simple mistake.
> The new check below is a comprehensive test for any of the returned
> classes being an x87 class.  In theory, one only needs to check the
> first class, and X86_64_X87UP_CLASS should only occur after an
> X86_64_X87_CLASS, but it seemed reasonable to be thorough here as
> this code is guarded by the rare !TARGET_80387, and its better to
> be explicit/clear if we're not on the critical path.
> One clean-up/fallout of this patch is the rationalization of the
> "error_issued" state in construct_container.  Given that we now need
> to issue a separate error for x87, it made sense for these static
> state variables, to be one per error message, such that we issue
> only one error for each type of problem (SSE argument, SSE return and
> x87 return) upon its first occurence.
> The following patch has been tested on x86_64-unknown-linux-gnu, with
> a full "make bootstrap", all default languages, and regression tested
> with a top-level "make -k check" with no new failures.
> Ok for mainline?

This is OK.  It seems to me that error message is quite appropriate
(over the alternative of having silently different ABI with -mno-80387
for 387 types).  Checking X86_64_X87_CLASS class only should be enough,
as the code would crash later in way if it wasn't coupled with
X86_64_X87UP_CLASS, but the code as it is looks fine to me.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]