Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2018-02-01 Thread Marc Glisse 

On Wed, 17 Jan 2018, Marc Glisse wrote:


I am currently in favor of removing ASSERT.


Done.

--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2018-01-17 Thread Marc Glisse 

On Wed, 17 Jan 2018, Vincent Lefevre wrote:


On 2018-01-17 18:06:49 +0100, Marc Glisse wrote:

On Wed, 17 Jan 2018, Vincent Lefevre wrote:


On 2018-01-17 17:23:02 +0100, Marc Glisse wrote:

Indeed, it doesn't make sense to have both the assertion and
COUNT_LEADING_ZEROS_0. Would it work to remove the assertion instead?


Yes, this works too (assuming that 0 will always be converted to +0).


You know those details better than me, is that a dangerous assumption to
make? Even when restricted to the architectures / compilers that may use
this code? I was expecting it to be rather safe, but if you think it isn't,
then I'd rather go with your original patch.


I know that both icc -O2 and tcc had issues with signed zeros in the
past. But I haven't done any test for several years.


I expect most compilers still have issues with signed zeros in some 
complicated cases, I just expect that it is very unlikely that conversion 
from integer 0 would suddenly generate -0.0. The case I could imagine is:


int i = ...;
int n = -i;
double d = n;

and the compiler would badly "optimize" that to

double tmp = i;
double d = -tmp;

Well, let's see if someone else wants to comment. I am currently in favor 
of removing ASSERT.


--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2018-01-17 Thread Vincent Lefevre 
On 2018-01-17 17:23:02 +0100, Marc Glisse wrote:
> Indeed, it doesn't make sense to have both the assertion and
> COUNT_LEADING_ZEROS_0. Would it work to remove the assertion instead?

Yes, this works too (assuming that 0 will always be converted to +0).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2018-01-17 Thread Marc Glisse 

On Wed, 17 Jan 2018, Vincent Lefevre wrote:


On 2017-12-27 17:15:43 +0100, Niels Möller wrote:

Vincent Lefevre  writes:


diff -r 20cf1131dc94 longlong.h
--- a/longlong.hThu Aug 31 01:00:02 2017 +0200
+++ b/longlong.hTue Dec 26 10:59:24 2017 +0100
@@ -535,7 +535,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype
 #endif /* defined(__ARM_ARCH_2__) ... */
 #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, x)
 #define count_trailing_zeros(count, x)  count_trailing_zeros_gcc_ctz(count, x)
-#define COUNT_LEADING_ZEROS_0 32
 #endif /* __arm__ */

 #if defined (__aarch64__) && W_TYPE_SIZE == 64
@@ -586,7 +585,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype
 #endif
 #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, x)
 #define count_trailing_zeros(count, x)  count_trailing_zeros_gcc_ctz(count, x)
-#define COUNT_LEADING_ZEROS_0 64
 #endif /* __aarch64__ */

 #if defined (__clipper__) && W_TYPE_SIZE == 32


I confirm that this fixes the problem.


Thanks for testing. Pushed now.


This is not sufficient. I get a failure for 32-bit x86 with MinGW.
This one is incorrect too:


That's a bit different.


#else /* ! pentiummmx || LONGLONG_STANDALONE */
/* The following should be a fixed 14 cycles or so.  Some scheduling
  opportunities should be available between the float load/store too.  This
  sort of code is used in gcc 3 for __builtin_ffs (with "n&-n") and is
  apparently suggested by the Intel optimizing manual (don't know exactly
  where).  gcc 2.95 or up will be best for this, so the "double" is
  correctly aligned on the stack.  */
#define count_leading_zeros(c,n)\
 do {  \
   union { \
 doubled;  \
 unsigned  a[2];   \
   } __u;  \
   ASSERT ((n) != 0);  \
   __u.d = (UWtype) (n);   \
   (c) = 0x3FF + 31 - (__u.a[1] >> 20);\
 } while (0)
#define COUNT_LEADING_ZEROS_0   (0x3FF + 31)
#endif /* pentiummx */

There's also a typo in the latest comment. Patch attached.


Indeed, it doesn't make sense to have both the assertion and 
COUNT_LEADING_ZEROS_0. Would it work to remove the assertion instead?


--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2018-01-17 Thread Vincent Lefevre 
On 2017-12-27 17:15:43 +0100, Niels Möller wrote:
> Vincent Lefevre  writes:
> 
> >> diff -r 20cf1131dc94 longlong.h
> >> --- a/longlong.h   Thu Aug 31 01:00:02 2017 +0200
> >> +++ b/longlong.h   Tue Dec 26 10:59:24 2017 +0100
> >> @@ -535,7 +535,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype 
> >>  #endif /* defined(__ARM_ARCH_2__) ... */
> >>  #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, 
> >> x)
> >>  #define count_trailing_zeros(count, x)  
> >> count_trailing_zeros_gcc_ctz(count, x)
> >> -#define COUNT_LEADING_ZEROS_0 32
> >>  #endif /* __arm__ */
> >>  
> >>  #if defined (__aarch64__) && W_TYPE_SIZE == 64
> >> @@ -586,7 +585,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype 
> >>  #endif
> >>  #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, 
> >> x)
> >>  #define count_trailing_zeros(count, x)  
> >> count_trailing_zeros_gcc_ctz(count, x)
> >> -#define COUNT_LEADING_ZEROS_0 64
> >>  #endif /* __aarch64__ */
> >>  
> >>  #if defined (__clipper__) && W_TYPE_SIZE == 32
> >
> > I confirm that this fixes the problem.
> 
> Thanks for testing. Pushed now.

This is not sufficient. I get a failure for 32-bit x86 with MinGW.
This one is incorrect too:

#else /* ! pentiummmx || LONGLONG_STANDALONE */
/* The following should be a fixed 14 cycles or so.  Some scheduling
   opportunities should be available between the float load/store too.  This
   sort of code is used in gcc 3 for __builtin_ffs (with "n&-n") and is
   apparently suggested by the Intel optimizing manual (don't know exactly
   where).  gcc 2.95 or up will be best for this, so the "double" is
   correctly aligned on the stack.  */
#define count_leading_zeros(c,n)\
  do {  \
union { \
  doubled;  \
  unsigned  a[2];   \
} __u;  \
ASSERT ((n) != 0);  \
__u.d = (UWtype) (n);   \
(c) = 0x3FF + 31 - (__u.a[1] >> 20);\
  } while (0)
#define COUNT_LEADING_ZEROS_0   (0x3FF + 31)
#endif /* pentiummx */

There's also a typo in the latest comment. Patch attached.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -r bd031c4d736b longlong.h
--- a/longlong.hWed Jan 17 05:34:55 2018 +0100
+++ b/longlong.hWed Jan 17 17:05:06 2018 +0100
@@ -965,8 +965,7 @@
 __u.d = (UWtype) (n);  \
 (c) = 0x3FF + 31 - (__u.a[1] >> 20);   \
   } while (0)
-#define COUNT_LEADING_ZEROS_0   (0x3FF + 31)
-#endif /* pentiummx */
+#endif /* pentiummmx */
 
 #else /* ! pentium */
 
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2018-01-02 Thread Torbjörn Granlund 
(Related, I wonder what the effect would be of redefining umul_ppmm as C
expressions involving __uint128_t on compilers that support that).

  We do that already for some CPUs, but this has proven to be somewhat
  fragile, and in unexpected cases lead to libgcc calls.

We brave to do that for at least PowerPC-64, MIPS-64, s390x, Arm64.  For
alpha, gcc provides an _int_mult_upper which we use instead.

Apart from better scheduling, making gcc aware of the semantics allows
for algebraic optimisations and various foldings.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2018-01-02 Thread Torbjörn Granlund 
ni...@lysator.liu.se (Niels Möller) writes:

  Using inline asm instead has the drawback that it leaves a little less
  opportunity for the compiler to schedule this instructions optimally. No
  idea if that matters in practice. Since it seems we don't really need
  count_*_zeros to support zero input, is there any advantage in using
  inline asm?
  
Sure, and that matters chiefly if the instructions have a long latency.
(Now, it is quite likely that CLZ and RBIT didn't get described to the
compiler scheduler, as they are usually not used.)

  (Related, I wonder what the effect would be of redefining umul_ppmm as C
  expressions involving __uint128_t on compilers that support that).
  
We do that already for some CPUs, but this has proven to be somewhat
fragile, and in unexpected cases lead to libgcc calls.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2018-01-02 Thread Niels Möller 
t...@gmplib.org (Torbjörn Granlund) writes:

> We might define these directly, at least for arm64, to CLZ and RBIT+CLZ,
> respectively, instead of using gcc's builtin semi-defined variants?

Using inline asm instead has the drawback that it leaves a little less
opportunity for the compiler to schedule this instructions optimally. No
idea if that matters in practice. Since it seems we don't really need
count_*_zeros to support zero input, is there any advantage in using
inline asm?

(Related, I wonder what the effect would be of redefining umul_ppmm as C
expressions involving __uint128_t on compilers that support that).

/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2018-01-01 Thread Torbjörn Granlund 
ni...@lysator.liu.se (Niels Möller) writes:

  t...@gmplib.org (Torbjörn Granlund) writes:
  
  > The idea with that was to allow some usages that want to pass 0 to avoid
  > a condition.  Isn't that used?
  
  The idea makes sense, but I couldn't find any such use. I was thinking
  that any use like that would be accompanied by an #ifdef
  COUNT_LEADING_ZEROS_0, but I found no matches when greping through the
  sources. I could be missing something, of course.
  
  Or maybe it should be used at some places, but currently isn't.
  
I assume the hardwired values were there because these expanded to fully
defined instructions.

We might define these directly, at least for arm64, to CLZ and RBIT+CLZ,
respectively, instead of using gcc's builtin semi-defined variants?

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2017-12-27 Thread Niels Möller 
t...@gmplib.org (Torbjörn Granlund) writes:

> The idea with that was to allow some usages that want to pass 0 to avoid
> a condition.  Isn't that used?

The idea makes sense, but I couldn't find any such use. I was thinking
that any use like that would be accompanied by an #ifdef
COUNT_LEADING_ZEROS_0, but I found no matches when greping through the
sources. I could be missing something, of course.

Or maybe it should be used at some places, but currently isn't.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2017-12-27 Thread Marco Bodrato 
Ciao,

Il Mer, 27 Dicembre 2017 6:10 pm, Marc Glisse ha scritto:
> On Wed, 27 Dec 2017, Niels Möller wrote:
>> And below, a patch to delete all mention of COUNT_LEADING_ZEROS_0,
>> except for tune/many.pl, which I'm not familiar with. What do you think?

> It seems a bit sad to drop this information, in case we want to use it in
> the future, or if we want to share the file longlong.h with other
> projects.

I fully agree.

> As far as I understand, the issue was an inconsistency between using gcc's
> __builtin_clz (instead of some intrinsic or inline asm for the CLZ
> instruction) and still defining the macro COUNT_LEADING_ZEROS_0 to 32. I
> am not sure that warrants removing all COUNT_LEADING_ZEROS_0 everywhere.

I understood the issue as you describe, and again I fully agree.

Ĝis,
m

-- 
http://bodrato.it/

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2017-12-27 Thread Marc Glisse 

On Wed, 27 Dec 2017, Niels Möller wrote:


ni...@lysator.liu.se (Niels Möller) writes:


Pushed now.


And below, a patch to delete all mention of COUNT_LEADING_ZEROS_0,
except for tune/many.pl, which I'm not familiar with. What do you think?


It seems a bit sad to drop this information, in case we want to use it in 
the future, or if we want to share the file longlong.h with other 
projects.


As far as I understand, the issue was an inconsistency between using gcc's 
__builtin_clz (instead of some intrinsic or inline asm for the CLZ 
instruction) and still defining the macro COUNT_LEADING_ZEROS_0 to 32. I 
am not sure that warrants removing all COUNT_LEADING_ZEROS_0 everywhere.


But if we aren't using it at all, I don't have a very strong opinion.

--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2017-12-27 Thread Torbjörn Granlund 
ni...@lysator.liu.se (Niels Möller) writes:

  And below, a patch to delete all mention of COUNT_LEADING_ZEROS_0,
  except for tune/many.pl, which I'm not familiar with. What do you think?
  
The idea with that was to allow some usages that want to pass 0 to avoid
a condition.  Isn't that used?


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2017-12-27 Thread Niels Möller 
ni...@lysator.liu.se (Niels Möller) writes:

> Pushed now.

And below, a patch to delete all mention of COUNT_LEADING_ZEROS_0,
except for tune/many.pl, which I'm not familiar with. What do you think?

Regards,
/Niels

diff -Nprc2 gmp.0e10f8f34eb4/longlong.h gmp/longlong.h
*** gmp.0e10f8f34eb4/longlong.h 2017-12-27 17:23:38.383996985 +0100
--- gmp/longlong.h  2017-12-27 17:23:38.37013 +0100
*** see https://www.gnu.org/licenses/.  */
*** 88,93 
 5) count_leading_zeros(count, x) counts the number of zero-bits from the
 msb to the first non-zero bit in the UWtype X.  This is the number of
!steps X needs to be shifted left to set the msb.  Undefined for X == 0,
!unless the symbol COUNT_LEADING_ZEROS_0 is defined to some value.
  
 6) count_trailing_zeros(count, x) like count_leading_zeros, but counts
--- 88,92 
 5) count_leading_zeros(count, x) counts the number of zero-bits from the
 msb to the first non-zero bit in the UWtype X.  This is the number of
!steps X needs to be shifted left to set the msb.  Undefined for X == 0.
  
 6) count_trailing_zeros(count, x) like count_leading_zeros, but counts
*** long __MPN(count_leading_zeros) (UDItype
*** 411,415 
 : "=r" (count) \
 : "r" (x))
- #define COUNT_LEADING_ZEROS_0 32
  #endif /* __a29k__ */
  
--- 410,413 
*** extern UWtype __MPN(udiv_qrnnd) (UWtype
*** 947,951 
} while (0)
  #define COUNT_LEADING_ZEROS_NEED_CLZ_TAB
- #define COUNT_LEADING_ZEROS_0   31   /* n==0 indistinguishable from n==1 */
  
  #else /* ! pentiummmx || LONGLONG_STANDALONE */
--- 945,948 
*** extern UWtype __MPN(udiv_qrnnd) (UWtype
*** 966,970 
  (c) = 0x3FF + 31 - (__u.a[1] >> 20);  \
} while (0)
- #define COUNT_LEADING_ZEROS_0   (0x3FF + 31)
  #endif /* pentiummx */
  
--- 963,966 
*** extern UWtype __MPN(udiv_qrnnd) (UWtype
*** 1106,1110 
  (count) = __cbtmp ^ 31;   \
} while (0)
- #define COUNT_LEADING_ZEROS_0 (-32) /* sic */
  #if defined (__i960mx)/* what is the proper symbol to test??? 
*/
  #define rshift_rhlc(r,h,l,c) \
--- 1102,1105 
*** extern UWtype __MPN(udiv_qrnnd) (UWtype
*** 1193,1197 
   : "=d" (count)   \
   : "od" ((USItype) (x)), "n" (0))
- #define COUNT_LEADING_ZEROS_0 32
  #endif
  #endif /* mc68000 */
--- 1188,1191 
*** extern UWtype __MPN(udiv_qrnnd) (UWtype
*** 1212,1216 
  (count) = __cbtmp ^ 31;   \
} while (0)
- #define COUNT_LEADING_ZEROS_0 63 /* sic */
  #if defined (__m88110__)
  #define umul_ppmm(wh, wl, u, v) \
--- 1206,1209 
*** extern UWtype __MPN(udiv_qrnnd) (UWtype
*** 1370,1374 
  #define count_leading_zeros(count, x) \
__asm__ ("cntlzw %0,%1" : "=r" (count) : "r" (x))
- #define COUNT_LEADING_ZEROS_0 32
  #if HAVE_HOST_CPU_FAMILY_powerpc
  #if __GMP_GNUC_PREREQ (4,4)
--- 1363,1366 
*** extern UWtype __MPN(udiv_qrnnd) (UWtype
*** 1487,1491 
  #define count_leading_zeros(count, x) \
__asm__ ("cntlzd %0,%1" : "=r" (count) : "r" (x))
- #define COUNT_LEADING_ZEROS_0 64
  #if __GMP_GNUC_PREREQ (4,8)
  #define umul_ppmm(w1, w0, u, v) \
--- 1479,1482 
*** extern UWtype __MPN(udiv_qrnnd) (UWtype
*** 1711,1716 
__asm__ ("scan %1,1,%0" : "=r" (count) : "r" (x))
  /* Early sparclites return 63 for an argument of 0, but they warn that future
!implementations might change this.  Therefore, leave COUNT_LEADING_ZEROS_0
!undefined.  */
  #endif /* __sparclite__ */
  #endif /* __sparc_v8__ */
--- 1702,1706 
__asm__ ("scan %1,1,%0" : "=r" (count) : "r" (x))
  /* Early sparclites return 63 for an argument of 0, but they warn that future
!implementations might change this.  */
  #endif /* __sparclite__ */
  #endif /* __sparc_v8__ */
*** __GMP_DECLSPEC UWtype __MPN(udiv_w_sdiv)
*** 2145,2149 
} while (0)
  /* This version gives a well-defined value for zero. */
- #define COUNT_LEADING_ZEROS_0 (W_TYPE_SIZE - 1)
  #define COUNT_LEADING_ZEROS_NEED_CLZ_TAB
  #define COUNT_LEADING_ZEROS_SLOW
--- 2135,2138 
diff -Nprc2 gmp.0e10f8f34eb4/tests/t-count_zeros.c gmp/tests/t-count_zeros.c
*** gmp.0e10f8f34eb4/tests/t-count_zeros.c  2017-12-27 17:23:38.383996985 
+0100
--- gmp/tests/t-count_zeros.c   2017-12-27 17:23:38.37013 +0100
*** check_various (void)
*** 59,66 
inti;
  
- #ifdef COUNT_LEADING_ZEROS_0
-   check_clz (COUNT_LEADING_ZEROS_0, CNST_LIMB(0));
- #endif
- 
for (i=0; i < GMP_LIMB_BITS; i++)
  {
--- 59,62 
diff -Nprc2 gmp.0e10f8f34eb4/tune/common.c gmp/tune/common.c
*** gmp.0e10f8f34eb4/tune/common.c  2017-12-27 17:23:38.387996993 +0100
--- gmp/tune/common.c

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2017-12-27 Thread Niels Möller 
Vincent Lefevre  writes:

>> diff -r 20cf1131dc94 longlong.h
>> --- a/longlong.h Thu Aug 31 01:00:02 2017 +0200
>> +++ b/longlong.h Tue Dec 26 10:59:24 2017 +0100
>> @@ -535,7 +535,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype 
>>  #endif /* defined(__ARM_ARCH_2__) ... */
>>  #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, x)
>>  #define count_trailing_zeros(count, x)  count_trailing_zeros_gcc_ctz(count, 
>> x)
>> -#define COUNT_LEADING_ZEROS_0 32
>>  #endif /* __arm__ */
>>  
>>  #if defined (__aarch64__) && W_TYPE_SIZE == 64
>> @@ -586,7 +585,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype 
>>  #endif
>>  #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, x)
>>  #define count_trailing_zeros(count, x)  count_trailing_zeros_gcc_ctz(count, 
>> x)
>> -#define COUNT_LEADING_ZEROS_0 64
>>  #endif /* __aarch64__ */
>>  
>>  #if defined (__clipper__) && W_TYPE_SIZE == 32
>
> I confirm that this fixes the problem.

Thanks for testing. Pushed now.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2017-12-26 Thread Vincent Lefevre 
On 2017-12-26 11:51:28 +0100, Niels Möller wrote:
> Hmm, I guess the problem is
> 
>   #define count_leading_zeros_gcc_clz(count,x)\
> do {  \
>   ASSERT ((x) != 0);  \
>   (count) = __builtin_clzll (x);  \
> } while (0)
> 
> in combination with 
> 
>   #define count_leading_zeros(count, x) count_leading_zeros_gcc_clz(count, x)
>   #define count_trailing_zeros(count, x) count_trailing_zeros_gcc_ctz(count, 
> x)
>   #define COUNT_LEADING_ZEROS_0 32
> 
> in the arm32 and arm64 parts of longlong.h.

Yes.

> diff -r 20cf1131dc94 longlong.h
> --- a/longlong.h  Thu Aug 31 01:00:02 2017 +0200
> +++ b/longlong.h  Tue Dec 26 10:59:24 2017 +0100
> @@ -535,7 +535,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype 
>  #endif /* defined(__ARM_ARCH_2__) ... */
>  #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, x)
>  #define count_trailing_zeros(count, x)  count_trailing_zeros_gcc_ctz(count, 
> x)
> -#define COUNT_LEADING_ZEROS_0 32
>  #endif /* __arm__ */
>  
>  #if defined (__aarch64__) && W_TYPE_SIZE == 64
> @@ -586,7 +585,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype 
>  #endif
>  #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, x)
>  #define count_trailing_zeros(count, x)  count_trailing_zeros_gcc_ctz(count, 
> x)
> -#define COUNT_LEADING_ZEROS_0 64
>  #endif /* __aarch64__ */
>  
>  #if defined (__clipper__) && W_TYPE_SIZE == 32

I confirm that this fixes the problem.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

2017-12-26 Thread Niels Möller 
Vincent Lefevre  writes:

> #ifdef COUNT_LEADING_ZEROS_0
>   check_clz (COUNT_LEADING_ZEROS_0, CNST_LIMB(0));
> #endif
>
> If GMP does a test with CNST_LIMB(0), I wonder why it has an
> assertion (n) != 0. This is not consistent!

The docs say:

   5) count_leading_zeros(count, x) counts the number of zero-bits from the
   msb to the first non-zero bit in the UWtype X.  This is the number of
   steps X needs to be shifted left to set the msb.  Undefined for X == 0,
   unless the symbol COUNT_LEADING_ZEROS_0 is defined to some value.

Which definition of count_leading_zeros is used in your build? It should
be fixed to set COUNT_LEADING_ZEROS_0 to match the implementation.

Hmm, I guess the problem is

  #define count_leading_zeros_gcc_clz(count,x)  \
do {\
  ASSERT ((x) != 0);\
  (count) = __builtin_clzll (x);\
} while (0)

in combination with 

  #define count_leading_zeros(count, x) count_leading_zeros_gcc_clz(count, x)
  #define count_trailing_zeros(count, x) count_trailing_zeros_gcc_ctz(count, x)
  #define COUNT_LEADING_ZEROS_0 32

in the arm32 and arm64 parts of longlong.h.

The gcc docs seem to say that the result of __builtin_clz is undefined
for zero input. So I'd suggest the below patch.

And as far as I find (based on greping for COUNT_LEADING_ZEROS_0), we
don't make use of count_leading_zeros with zero input, even on platforms
where it is allowed. So maybe we can delete this preprocessor constant
altogether and say that count_leading_zeros mustn't be used with zero
input?

Regards,
/Niels

diff -r 20cf1131dc94 longlong.h
--- a/longlong.hThu Aug 31 01:00:02 2017 +0200
+++ b/longlong.hTue Dec 26 10:59:24 2017 +0100
@@ -535,7 +535,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype 
 #endif /* defined(__ARM_ARCH_2__) ... */
 #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, x)
 #define count_trailing_zeros(count, x)  count_trailing_zeros_gcc_ctz(count, x)
-#define COUNT_LEADING_ZEROS_0 32
 #endif /* __arm__ */
 
 #if defined (__aarch64__) && W_TYPE_SIZE == 64
@@ -586,7 +585,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype 
 #endif
 #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, x)
 #define count_trailing_zeros(count, x)  count_trailing_zeros_gcc_ctz(count, x)
-#define COUNT_LEADING_ZEROS_0 64
 #endif /* __aarch64__ */
 
 #if defined (__clipper__) && W_TYPE_SIZE == 32

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

GMP 6.1.2 t-count_zeros failure on ARM with assertions

2017-12-25 Thread Vincent Lefevre 
I've built GMP 6.1.2 with assertions:

  ./configure --enable-assert --prefix=$HOME/opt/gmp-6.1.2

on an old ARM VM (Debian squeeze). But I get the failure:

FAIL: t-count_zeros
===

t-count_zeros.c:31: GNU MP assertion failed: (n) != 0
FAIL t-count_zeros (exit status: 134)

I've added some printf's in the code, and this is due to:

#ifdef COUNT_LEADING_ZEROS_0
  check_clz (COUNT_LEADING_ZEROS_0, CNST_LIMB(0));
#endif

If GMP does a test with CNST_LIMB(0), I wonder why it has an
assertion (n) != 0. This is not consistent!

$ gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' 
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.4 --enable-shared --enable-multiarch 
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc 
--disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi 
--host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8) 

$ uname -a
Linux ypig-arm 2.6.32-5-versatile #1 Wed Jan 12 23:05:11 UTC 2011 armv5tejl 
GNU/Linux

$ ./config.guess
arm9te-unknown-linux-gnueabi

$ ./configfsf.guess
armv5tejl-unknown-linux-gnueabi

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs