This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 1/2] Add support for O32 FPXX ABI
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "macro\ at codesourcery dot com" <macro at codesourcery dot com>, "Joseph Myers \(joseph\ at codesourcery dot com\)" <joseph at codesourcery dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Date: Tue, 06 May 2014 13:40:20 +0100
- Subject: Re: [PATCH 1/2] Add support for O32 FPXX ABI
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534DAAAB at LEMAIL01 dot le dot imgtec dot org> <6D39441BF12EF246A7ABCE6654B023534DFD9B at LEMAIL01 dot le dot imgtec dot org> <87fvll1ha9 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534E07CB at LEMAIL01 dot le dot imgtec dot org> <87k3awnuf1 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E0F50 at LEMAIL01 dot le dot imgtec dot org> <87ppknzv7m dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E16D7 at LEMAIL01 dot le dot imgtec dot org> <877g6vzpj1 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E3030 at LEMAIL01 dot le dot imgtec dot org> <87eh0yl4xx dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E3AA8 at LEMAIL01 dot le dot imgtec dot org> <87d2ghk7fu dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023535127C8 at LEMAIL01 dot le dot imgtec dot org> <87r44mve6s dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B02353512A10 at LEMAIL01 dot le dot imgtec dot org> <87r44leu34 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B0235351D76A at LEMAIL01 dot le dot imgtec dot org> <53640082 dot 6070703 at imgtec dot com> <6D39441BF12EF246A7ABCE6654B023535214A4 at LEMAIL01 dot le dot imgtec dot org>
BTW, sorry for the slow response to your original patch. I got about
half way through a review yesterday, but we definitely need to change
the way that the current code reports FPU errors. Just cutting-&-pasting
the meaning of each tag N times isn't good. (I knew I should have
pushed back more than on that...)
So I'm planning to commit a patch to update the code that checks and
prints the tags. Hopefully it should be easy to rebase yours on top.
Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> + /* If floating-point code has been seen and the module is single-float
> + then give this precedence over the double-precision cases below.
> + Single-float can theoretically be used with any width register. */
> + else if (mips_seen_fp_code == TRUE
> + && file_mips_opts.single_float == 1)
> + fpabi = Val_GNU_MIPS_ABI_FP_SINGLE;
>
> This is not OK. As we don't know if the user wrote .module singlefloat or used
> -msingle-float. If it was .module then this shows intent that the code in this
> module is designed for single-float so that would be OK.
But .module should act like the corresponding command-line option,
and vice versa. I don't think any extra trust should be given to
one over the other.
I think we need to keep the interface as simple as possible.
> I propose a further option to fix this. -minfer-abi and .module infer-fpabi.
No!!! :-) Even more options would just make things unnecessarily complicated.
Anything passing the command-line options or generating the .module should
say what the ABI is instead.
The general principle is that an asm file can include code that requires
features outside the module-level setting. We should never infer
anything about the global FPU ABI from something like an ADD.D that
we happen to see. It might be that the ADD.D is part of an ifunc
(or similar mechanism) that only runs when an FPU is available.
IMO we should just leave the FPU ABI as "any" unless a command-line option,
.module or .gnu_attribute says what the ABI actually is.
Thanks,
Richard