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

[arnold]

Hi Andy.

I think you can just push your patch as-is.

Thanks

Arnold

"Andrew J. Schorr" <address@hidden> wrote:

> 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