Re: 2 minor issues on Windows
Might you consider (I verified it works):
#if defined (_MSC_VER)
#pragma warning(push)
#pragma warning(disable: 4146) // unary minus operator applied to unsigned
type, result still unsigned
#endif
*__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK;
#if defined (_MSC_VER)
#pragma warning(pop)
#endif
Your code, your call. I understand the above does not enhance
readability. The other alternative is to apply the pragma to the entire
gmp.h file.
Regards,
George Woltman
On Sun, Mar 13, 2022 at 5:24 AM Marco Bodrato
wrote:
> Ciao,
>
> Il 2022-03-13 00:06 Torbjörn Granlund ha scritto:
> > There is some sort of sick competition between certain compilers to
> > have
> > the most warnings for valid C. I don't think we should play their
> > game,
>
> > Incidantally, arithmetic on unsigned types is well-defined. Unlike
> > that
> > of signed types.
>
> > int
> > foo (int a, int b)
> > {
> > return a + b - 1;
> > }
> >
> > $ clank foo.c
> > warning: signed addition might overflow and yield undefined results
> > warning: signed subtraction might overflow and yield undefined results
>
> :-D
> You are right!
>
> Ĝis,
> m
>
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
Ciao,
Il 2022-03-13 00:06 Torbjörn Granlund ha scritto:
There is some sort of sick competition between certain compilers to
have
the most warnings for valid C. I don't think we should play their
game,
Incidantally, arithmetic on unsigned types is well-defined. Unlike
that
of signed types.
int
foo (int a, int b)
{
return a + b - 1;
}
$ clank foo.c
warning: signed addition might overflow and yield undefined results
warning: signed subtraction might overflow and yield undefined results
:-D
You are right!
Ĝis,
m
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
There is some sort of sick competition between certain compilers to have
the most warnings for valid C. I don't think we should play their game,
and as a result obfuscate the GMP sources.
Incidantally, arithmetic on unsigned types is well-defined. Unlike that
of signed types.
Should not these compilers warn about *every* arithmetic operation on
signed integers? Certainly, it should warn about signed negation,
unless it can prove the negated value is not INT_MIN, as -INT_MIN is
undefined in two's complement representation...
int
foo (int a, int b)
{
return a + b - 1;
}
$ clank foo.c
warning: signed addition might overflow and yield undefined results
warning: signed subtraction might overflow and yield undefined results
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
Marco Bodrato writes: - *__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK; + *__gmp_rp = (1 + ~ *__gmp_up) & GMP_NUMB_MASK; Let's please not do this. There is some sort of sick competition between certain compilers to have the most warnings for valid C. I don't think we should play their game, and as a result obfuscate the GMP sources. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
Ciao, Il 2022-02-03 08:50 ni...@lysator.liu.se ha scritto: George Woltman writes: Minor issue #2 (I should have reported this years ago, sorry): In gmp.h, these lines: mpn_neg (mp_ptr __gmp_rp, mp_srcptr __gmp_up, mp_size_t __gmp_n) [...] *__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK; The last line generates this compiler warning: warning C4146: unary minus operator applied to unsigned type, result still I can only suggest that you disable or ignore that warning. Operations on unsigned types is well defined by the C standard, and gmp depends on practically all possible corner cases to work according to spec. Maybe we can avoid this in the file gmp.h; it is used during the compiling process of any project using the library... What about the following? --- a/gmp-h.in Fri Mar 11 21:13:20 2022 +0100 +++ b/gmp-h.in Sat Mar 12 23:23:09 2022 +0100 @@ -2234,7 +2234,7 @@ ++__gmp_up; ++__gmp_rp; } - *__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK; + *__gmp_rp = (1 + ~ *__gmp_up) & GMP_NUMB_MASK; if (--__gmp_n) /* Higher limbs get complemented. */ mpn_com (++__gmp_rp, ++__gmp_up, __gmp_n); For an optimising compiler, there should not be any difference. "+ ~ *" is a funny sequence of operators :-) Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
Ciao, Il Gio, 3 Febbraio 2022 8:50 am, Niels Möller ha scritto: > George Woltman writes: >> I get this compiler warning calling mpz_tstbit: warning C4244: >> 'argument': >> conversion from 'uint64_t' to 'mp_bitcnt_t', possible loss of data >> Yes, I'm creating mpz values with more than 4 billion bits. > > That's kind-of difficult. I agree it would make sense to increase size > of mp_bitcnt_t (perhaps ptrdiff_t would be a reasonable and portable > definition?), but it's going to be an ABI break platforms where that's an > actual change of size. Torbjörn, should this be listed under the things > to fix once we decide to break ABI compatibility? On https://gmplib.org/devel/incompatibility we have the following line: Consider making mp_bitcnt_t a 64-bit integer also on 32-bit hosts. We should consider the windos64 case as well. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
Ciao, Il Gio, 3 Febbraio 2022 8:50 am, Niels Möller ha scritto: > George Woltman writes: >> I get this compiler warning calling mpz_tstbit: warning C4244: >> 'argument': >> conversion from 'uint64_t' to 'mp_bitcnt_t', possible loss of data >> Yes, I'm creating mpz values with more than 4 billion bits. > > That's kind-of difficult. I agree it would make sense to increase size > of mp_bitcnt_t (perhaps ptrdiff_t would be a reasonable and portable > definition?), but it's going to be an ABI break platforms where that's an > actual change of size. Torbjörn, should this be listed under the things > to fix once we decide to break ABI compatibility? On https://gmplib.org/devel/incompatibility we have the following line: Consider making mp_bitcnt_t a 64-bit integer also on 32-bit hosts. We should consider the windos64 case as well. Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
George Woltman writes:
> I've built the library (64-bit) using Cygwin. This creates a DLL and a
> gmp.h file that can be used with Microsoft Visual Studio C compiler.
> As you probably know, MSVC strangely defines long as 32-bits.
Hi, looking through old mail, sorry for the late reply.
> In gmp.h, these lines appear:
>
> #ifdef __GMP_SHORT_LIMB
> typedef unsigned int mp_limb_t;
> typedef int mp_limb_signed_t;
> #else
> #ifdef _LONG_LONG_LIMB
> typedef unsigned long long int mp_limb_t;
> typedef long long int mp_limb_signed_t;
> #else
> typedef unsigned long int mp_limb_t;
> typedef long int mp_limb_signed_t;
> #endif
> #endif
> typedef unsigned long int mp_bitcnt_t;
>
> The problem is that while _LONG_LONG_LIMB is defined, the definition of
> mp_bitcnt_t ought to also use "long long".
> I get this compiler warning calling mpz_tstbit: warning C4244: 'argument':
> conversion from 'uint64_t' to 'mp_bitcnt_t', possible loss of data
> Yes, I'm creating mpz values with more than 4 billion bits.
That's kind-of difficult. I agree it would make sense to increase size
of mp_bitcnt_t (perhaps ptrdiff_t would be a reasonable and portable
definition?), but it's going to be an ABI break platforms where that's an
actual change of size. Torbjörn, should this be listed under the things
to fix once we decide to break ABI compatibility?
Do you also get a 32-bit mp_size_t ?
> Minor issue #2 (I should have reported this years ago, sorry):
>
> In gmp.h, these lines:
>
> mpn_neg (mp_ptr __gmp_rp, mp_srcptr __gmp_up, mp_size_t __gmp_n)
> {
> while (*__gmp_up == 0) /* Low zero limbs are unchanged by negation. */
> {
> *__gmp_rp = 0;
> if (!--__gmp_n) /* All zero */
> return 0;
> ++__gmp_up; ++__gmp_rp;
> }
>
> *__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK;
>
> The last line generates this compiler warning:
> warning C4146: unary minus operator applied to unsigned type, result still
> unsigned
I can only suggest that you disable or ignore that warning. Operations
on unsigned types is well defined by the C standard, and gmp depends on
practically all possible cornercases to work according to spec.
Regards,
/Niels
--
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: 2 minor issues on Windows
On Sun, Jan 16, 2022 at 9:24 PM George Woltman wrote: > The problem is that while _LONG_LONG_LIMB is defined, the definition of > mp_bitcnt_t ought to also use "long long". > I get this compiler warning calling mpz_tstbit: warning C4244: 'argument': > conversion from 'uint64_t' to 'mp_bitcnt_t', possible loss of data > Yes, I'm creating mpz values with more than 4 billion bits. > On windows, we're faced with the irritating fact that sizeof(mp_bitcnt_t) is always 4 bytes. (This is a general Windows issue that's not limited to just MSVC.) I think the gmp developers are aware of this, and that removing this annoyance is on a todo list. I once tried hacking the gmp source such that 'unsigned long long int' would be typedeffed to 'mp_bitcnt_t', but I couldn't get much mileage out of my attempts. (You could try the same, and see how it goes.) In the end I decided that, on Windows, if I currently want to mpz_tstbit() a bit beyond index 4294967295, then I first have to perform a 4294967295-bit right-shift on the mpz_t (or on a copy thereof), and then query the relevant bit For example, if I want to mpz_tstbit() the bit at index 4294967296, I first right-shift the value by 4294967295 bits (using mpz_tdiv_q_2exp), and then mpz_tstbit() the bit at index 1. Cheers, Rob ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
