From: Richard Sandiford <rdsandiford@googlemail.com>
To: Sandra Loosemore <sandra@codesourcery.com>
Cc: <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, MIPS] -mno-float odds and ends
Date: Mon, 30 Jul 2012 19:39:00 -0000 [thread overview]
Message-ID: <874nop2g5h.fsf@talisman.home> (raw)
In-Reply-To: <5016BE96.9000106@codesourcery.com> (Sandra Loosemore's message of "Mon, 30 Jul 2012 11:04:22 -0600")
Sandra Loosemore <sandra@codesourcery.com> writes:
> The MIPS back end has an option -mno-float that is supported by
> bare-metal configs using the SDE library. However, this option is not
> properly documented in the manual, and MIPS_ARCH_FLOAT_SPEC doesn't know
> about it as one of the explicit floating-point configuration changes
> that should override architecture defaults. This patch addresses both
> problems. OK to commit?
OK, you're touching a sore spot here, but...
> +@item -mno-float
> +@opindex mno-float
> +Prevents the use of all floating-point operations. This option is presently
> +supported only by some bare-metal MIPS configurations.
...unfortunately, it doesn't prevent the use floating-point operations.
That's why it's such a bad option. The only difference from the compiler
proper's point of view between -msoft-float and -mno-float is that they
define different preprocessor macros.
The onus is instead on the programmer to avoid writing anything that
might tempt the compiler into using floating-point operations. If the
user gets it wrong, they get (at best) a link-time error rather than a
compile-time error.
I think we should document it that way. E.g. something like:
@item -mno-float
@opindex mno-float
Equivalent to @option{-msoft-float}, but asserts that the user is
trying to avoid all floating-point operations. This option is presently
supported only by some bare-metal MIPS configurations, where it selects
a special set of libraries that lack all floating-point support
(including, for example, the floating-point @code{printf} formats).
If code compiled with @code{-mno-float} accidentally contains
floating-point operations, it is likely to suffer a link-time
or run-time failure.
but you're better at the wordsmithing than I am.
Perhaps we should document the __mips_no_float preprocessor macro too,
since that's how things like printf() know that they don't need the
floating-point stuff.
The mips.h part is OK though, thanks. Feel free to apply it separately
if that's more convenient than keeping the patch together.
Richard
next prev parent reply other threads:[~2012-07-30 19:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-30 17:45 Sandra Loosemore
2012-07-30 19:39 ` Richard Sandiford [this message]
2012-07-30 21:55 ` Sandra Loosemore
2012-07-30 22:27 ` Sandra Loosemore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874nop2g5h.fsf@talisman.home \
--to=rdsandiford@googlemail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=sandra@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).