[PATCH] mpn/generic/perfsqr: Improve alternate (currently disabled) test.

[David Sparks]

On Monday, February 16th, 2026 at 09:10, marco.bodrato at tutanota.com <marco.bodrato at tutanota.com> wrote:
> And for the same reason
> if (lo & lsbit*3 != 0)
> should have been
> if ((lo & lsbit*3) != 0)
> 
> Am I right?

Yes.  Sorry, I was fighting with MSYS2.  It turns out
(https://www.msys2.org/docs/symlinks/) that msys2 by default
implements "ln -s" as a *copy*, which means that when I edit
mpn/generic/perfsqr.c, it doesn't get copied to mpn/perfsqr.c
and therefore compiled unless I re-run config.status.

This resulted in me being very confused about whether certain edits
had passed "make check" or not.

I managed to find the incantation to enable symlinks on Windows
and set the $MSYS environment variable (another issue, some docs
say it's called $MSYS2, but that doesn't do anything) to make
MSYS2 use them, and the problem should hopefully be sorted going
forward.


> The idea is interesting, I'll test it.
> But I'd not mix it with a campaign to remove parenthesis, some are actually not necessary, but avoid ambiguity for some readers, and avoid warnings for some compilers. 

I think GCC goes too far (it complains about "a + b & c"), but I tried
to avoid compiler warnings.  I don't mind that GCC complains about
"a << b + c", but parenthesizing "a >> b % 32" is just silly.
especially if it's spaced as "a >> b%32" to make it clear.

As I just illustrated, it's the weirdly low precedence of & and |
(for historical reasons; && and || didn't exist in early C) that
trips everyone up.

Too many parens obscure rather than clarifying.  For me, at
least, (three (levels (of nesting))) is the ordinary limit and
(four (makes (me look) for (another (way to write) the) expression)).