public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: Antoni Boucher <bouanto@zoho.com>
To: David Malcolm <dmalcolm@redhat.com>,
	"jit@gcc.gnu.org" <jit@gcc.gnu.org>,
	 "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] libgccjit: Fix float playback for cross-compilation
Date: Thu, 25 Jan 2024 16:04:10 -0500	[thread overview]
Message-ID: <9fbf4189ba565f43ba58e678d4673ab1ec6e51a7.camel@zoho.com> (raw)
In-Reply-To: <d39bb6105a3b31460f718990f2f987811a8247b3.camel@redhat.com>

Thanks for the review!

On Wed, 2024-01-24 at 13:10 -0500, David Malcolm wrote:
> On Thu, 2024-01-11 at 18:42 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch fixes the bug 113343.
> > I'm wondering if there's a better solution than using mpfr.
> > The only other solution I found is real_from_string, but that seems
> > overkill to convert the number to a string.
> > I could not find a better way to create a real value from a host
> > double.
> 
> I took a look, and I don't see a better way; it seems weird to go
> through a string stage.  Ideally there would be a
> real_from_host_double, but I don't see one.
> 
> Is there a cross-platform way to directly access the representation
> of
> a host double?

I have no idea.

> 
> > If there's no solution, do we lose some precision by using mpfr?
> > Running Rust's core library tests, there was a difference of one
> > decimal, so I'm wondering if there's some lost precision, or if
> > it's
> > just because those tests don't work on m68k which was my test
> > target.
> 
> Sorry, can you clarify what you mean by "a difference of one decimal"
> above?

Let's say the Rust core tests expected the value "1.23456789", it
instead got the value "1.2345678" (e.g. without the last decimal).
Not sure if this is expected.
Everything works fine for x86-64; this just happened for m68k which is
not well supported for now in Rust, so that might just be that the test
doesn't work on this platform.

> 
> > Also, I'm not sure how to write a test this fix. Any ideas?
> 
> I think we don't need cross-compilation-specific tests, we should
> just
> use and/or extend the existing coverage for
> gcc_jit_context_new_rvalue_from_double e.g. in test-constants.c and
> test-types.c
> 
> We probably should have test coverage for "awkward" values; we
> already
> have coverage for DBL_MIN and DBL_MAX, but we don't yet have test
> coverage for:
> * quiet/signaling NaN
> * +ve/-ve inf
> * -ve zero

Is this something you would want for this patch?

> 
> Thanks
> Dave
> 


  reply	other threads:[~2024-01-25 21:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 23:42 Antoni Boucher
2024-01-24 18:10 ` David Malcolm
2024-01-25 21:04   ` Antoni Boucher [this message]
2024-02-17 16:56     ` Antoni Boucher

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=9fbf4189ba565f43ba58e678d4673ab1ec6e51a7.camel@zoho.com \
    --to=bouanto@zoho.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jit@gcc.gnu.org \
    /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).