public inbox for
 help / color / mirror / Atom feed
From: Xi Ruoyao <>
To: Lulu Cheng <>,
	Joseph Myers <>
Cc:, Wang Xuerui <>,
	Chenghua Xu <>,
	Xiaolin Tang <>
Subject: Re: [PATCH v2 2/4] LoongArch: Add ftint{,rm,rp}.{w,l}.{s,d} instructions
Date: Fri, 11 Nov 2022 13:29:55 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


So I think the code is correct:

+   (<lrint_allow_inexact>
+    || flag_fp_int_builtin_inexact
+    || !flag_trapping_math)"

<lrint_allow_inexact> is 1 for lrint, 0 for lceil and lfloor.  As N3054

   The lrint and llrint functions provide floating-to-integer conversion as prescribed by IEC 60559.
   They round according to the current rounding direction. If the rounded value is outside the range of
   the return type, the numeric result is unspecified and the "invalid" floating-point exception is raised.
   When they raise no other floating-point exception and the result differs from the argument, they
   raise the "inexact" floating-point exception.
If flag_fp_int_builtin_inexact is set, we allow lceil and lfloor to
raise "inexact".

If flag_trapping_math is not set (it's set by default and can only be
unset explicitly with -fno-trapping-math: it's not even implied by -
ffast-math), we don't care about whether exceptions are raised or not.

So lceil and lfloor can be used if -ffp-int-builtin-inexact, or -fno-

On Fri, 2022-11-11 at 00:07 +0000, Joseph Myers wrote:
> On Thu, 10 Nov 2022, Xi Ruoyao via Gcc-patches wrote:
> > Joseph: can you confirm that -ftrapping-math allows floor and ceil to
> > raise inexact exception?  The man page currently says:
> > 
> > The default is -ffp-int-builtin-inexact, allowing the exception to be
> > raised, unless C2X or a later C standard is selected.  This option does 
> >                                                        ^^^^^^^^^^^
> > nothing unless -ftrapping-math is in effect.
> > 
> > To me it's not very clear that "this option" stands for -fno-fp-int-
> > builtin-inexact or -ffp-int-builtin-inexact.
> The -ftrapping-math option (which is on by default) means that we care
> about whether operations raise exceptions: they should raise exceptions if 
> and only if the relevant standard permit them to do so.
> The combination of -ftrapping-math with -fno-fp-int-builtin-inexact means 
> the listed built-in functions must not raise "inexact".
> If -fno-trapping-math is used, then we don't care about whether exceptions 
> are raised or not (for any floating-point operations, not just those 
> functions).  So given -fno-trapping-math, there is no difference between 
> -fno-fp-int-builtin-inexact and -ffp-int-builtin-inexact.
> If -ffp-int-builtin-inexact (default before C2X), we don't care about 
> whether those functions raise "inexact" (but still care about other 
> exceptions and exceptions for other operations, unless 
> -fno-trapping-math).

Xi Ruoyao <>
School of Aerospace Science and Technology, Xidian University

  reply	other threads:[~2022-11-11  5:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-09 13:53 [PATCH v2 0/4] LoongArch: Add some floating-point operations Xi Ruoyao
2022-11-09 13:53 ` [PATCH v2 1/4] LoongArch: Rename frint_<fmt> to rint<mode>2 Xi Ruoyao
2022-11-10  8:15   ` Lulu Cheng
2022-11-09 13:53 ` [PATCH v2 2/4] LoongArch: Add ftint{,rm,rp}.{w,l}.{s,d} instructions Xi Ruoyao
2022-11-10  6:41   ` Lulu Cheng
2022-11-10  8:49     ` Xi Ruoyao
2022-11-11  0:07       ` Joseph Myers
2022-11-11  5:29         ` Xi Ruoyao [this message]
2022-11-12  1:58           ` Lulu Cheng
2022-11-09 13:53 ` [PATCH v2 3/4] LoongArch: Add fscaleb.{s,d} instructions as ldexp{sf,df}3 Xi Ruoyao
2022-11-12  3:54   ` Lulu Cheng
2022-11-12  4:40     ` Xi Ruoyao
2022-11-12  6:52       ` Lulu Cheng
2022-11-09 13:53 ` [PATCH v2 4/4] LoongArch: Add flogb.{s,d} instructions and expand logb{sf,df}2 Xi Ruoyao
2022-11-12  6:51   ` Lulu Cheng
2022-11-12  7:08 ` [PATCH v2 0/4] LoongArch: Add some floating-point operations Xi Ruoyao
2022-11-12  7:14   ` Lulu Cheng
2022-11-14  2:41   ` tangxiaolin

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

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