This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Maciej W. Rozycki" <macro at imgtec dot com>
- Cc: <linux-mips at linux-mips dot org>, <libc-alpha at sourceware dot org>, <binutils at sourceware dot org>, <gcc at gcc dot gnu dot org>, Matthew Fortune <Matthew dot Fortune at imgtec dot com>, Daniel Sanders <Daniel dot Sanders at imgtec dot com>, Leonid Yegoshin <Leonid dot Yegoshin at imgtec dot com>
- Date: Fri, 27 Nov 2015 18:03:55 +0000
- Subject: Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 00 dot 1511140411050 dot 7097 at tp dot orcam dot me dot uk> <alpine dot DEB dot 2 dot 10 dot 1511171503510 dot 14808 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 00 dot 1511201535580 dot 6915 at tp dot orcam dot me dot uk> <alpine dot DEB dot 2 dot 10 dot 1511201815230 dot 9012 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 00 dot 1511271547290 dot 16168 at tp dot orcam dot me dot uk>
On Fri, 27 Nov 2015, Maciej W. Rozycki wrote:
> I find it highly unlikely though that the writers will (be able to) chase
> individual targets and any obscure hardware-dependent options the targets
> may provide. And we cannot expect people compiling software to be
What that says to me is that there should be an architecture-independent
option (-fieee?) that, for architectures where the default configuration
may have architecture-specific deviations from the normal defaults
regarding conformance to IEEE 754 language bindings but there are options
to disable those deviations, disables those deviations. For example, on
alpha that would imply -mieee-with-inexact. On architectures without such
issues (beyond bugs that should be fixed unconditionally, not conditional
on a command-line option, or issues with the hardware ISA that are
infeasible to fix in software), that option would do nothing (beyond any
architecture-independent effects it might have such as implying
-fno-fast-math).
> As you may see in the GCC patches I have just posted the `-mieee=strict'
> option I've implemented sets `-fno-fast-math', and `-mrelaxed-nan=none',
> the only target-specific option so far. So this does exactly what I
> outlined above.
I am doubtful about the architecture-specific option setting
architecture-independent options here. Having it the other way round as I
suggested above would make more sense to me.
> "Any or all of these options may have effects beyond propagating the IEEE
> Std 754 compliance mode down to the assembler and the linker. In
> particular `-mieee=strict' is expected to produce strictly compliant code,
> which in the context of this specification is defined as: following IEEE
> Std 754 as closely as the programming language binding to the standard
> (defined in the relevant language standard), the compiler implementation
> and target hardware permit. This means the use of this option may affect
> code produced in ways beyond NaN representation only."
>
> > > Does this answer address your concerns?
> >
> > No, the option concept as described seems too irremediably vague.
>
> Does this explanation give you a better idea of what I have in mind? Do
> you still have concerns about the feasibility of the idea?
It's better defined, but I think it would be better for -fieee to imply
-mieee=strict -fno-fast-math (or whatever) rather than for -mieee=strict
to imply architecture-independent options. Cf. i386 and sh where
-ffinite-math-only affects architecture-specific options.
--
Joseph S. Myers
joseph@codesourcery.com