bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gawk] macOS: mpfrsqrt check fails on gawk-4.2-stable and master


From: Andrew J. Schorr
Subject: Re: [bug-gawk] macOS: mpfrsqrt check fails on gawk-4.2-stable and master branches
Date: Fri, 9 Feb 2018 10:22:15 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,

On Fri, Feb 09, 2018 at 02:13:54AM -0700, address@hidden wrote:
> > Another idea is to patch the intdiv extension to issue a warning if
> > it receives MPFR arguments but was not compiled with MPFR support. A
> > possible (untested) patch is attached. I guess the question is whether
> > we want to take the runtime hit of checking this on each call when the
> > extension wasn't built with MPFR.
> 
> I think it's worth doing.

OK. In that case, I guess there's no need to add the new intdiv test I 
suggested. Or should we do both?

> Move the warned variable up and then the check will be less expensive, maybe.

I'm not sure I follow. In the case where HAVE_MPFR is not defined, we generally
expect that gawk will also have been built without MPFR.  So we expect that the
arguments will have type AWK_NUMBER_TYPE_DOUBLE. Thus, I check for other types
before checking the warned flag because it is incredibly unlikely that the type
will be other than double.

I could rewrite as follows, but the performance should be the same as the
current code (and I think a bit less elegant, because I like tightly coupling
the `warning' flag to where the message is printed):

                static int warned = 0;
                if ((nv.num_type != AWK_NUMBER_TYPE_DOUBLE || dv.num_type != 
AWK_NUMBER_TYPE_DOUBLE) && !warned) {
                ...

Are you suggesting something else?

A possible optimization is to check only one of the types (numerator or
denominator), on the assumption that in MPFR mode, everything will be
non-double. That's probably a good idea:

                if (nv.num_type != AWK_NUMBER_TYPE_DOUBLE) {
                        static int warned = 0;
                        if (!warned) {
                ...

> On the mac I have access to via Nelson, configure needs to be told
> to look for MPFR at the top level.  I don't understand why for Hermann
> the top level finds it but the extension one doesn't; they use the
> same snippets.  That is worth investigating separately but Hermann
> will have to try to figure it out.

OK. Yes. That is too hard for me to debug without access to Hermann's machine.

Regards,
Andy



reply via email to

[Prev in Thread] Current Thread [Next in Thread]