This is the mail archive of the mailing list for the binutils 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: [PATCH 1/2] Add support for O32 FPXX ABI

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 <> 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.


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