Re: gmp 64 bit configure failure on Solaris/SPARC

2017-03-31 Thread Torbjörn Granlund 
Norm Jacobs  writes:

  Pilot error.  Just supplying the triples that I want resolved my problem.

Ideally,

  configure
  make
  make check

should recognise the CPU and use the best ABI available.

If that does not work, then we want to improve the config* files.
  

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

Re: gmp 64 bit configure failure on Solaris/SPARC

2017-03-31 Thread Norm Jacobs 

On 03/29/17 10:29 PM, Norm Jacobs wrote:

On 03/29/17 04:43 PM, t...@gmplib.org wrote:

Norm Jacobs  writes:

  --- gmp-6.1.1/configure.ac.orig 2017-01-04 20:22:16.789422430 
+
  +++ gmp-6.1.1/configure.ac  2017-01-04 20:47:35.488157345 
+

  @@ -1318,7 +1318,7 @@
# reject ABI=64 in favour of ABI=32 if the user has 
forced the flags to

# 32-bit mode.
#
  -abilist="32"
  +abilist="64 32"
cclist="gcc acc cc"
any_testlist="sizeof-long-4"
GMP_INCLUDE_MPN(sparc32/sparc-defs.m4)
   That's not the correct fix.

What needs to be fixed is CPU recognition, i.e., to have config.guess
return the proper CPU type, then make that type (assuming it is unknown
by GMP) be known to the sparc-64 code in configure.ac and also by
config.sub.


Thanks, I will try to take another look in the next several days.


Pilot error.  Just supplying the triples that I want resolved my problem.
Thanks again.
-Norm
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

2017-03-31 Thread Vincent Lefevre 
On 2017-03-31 15:33:13 +0200, Torbjörn Granlund wrote:
> User choice is great; one can choose between malfunctioning libc or
> explicitly ask for a correct one.

Well, GCC has the same kind of issues: one may need to provide options
like -std=c99 or -std=c11, and -frounding-math, to make it conform to
the C standard. Otherwise it may do invalid optimizations, at least
with floating point.

-- 
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: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

2017-03-31 Thread Torbjörn Granlund 
Claude Heiland-Allen  writes:

  > Could the macro __USE_MINGW_ANSI_STDIO be relevant?
  
  Yes, perfect!  I did
  
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO ./configure
  --host=x86_64-w64-mingw32 --prefix=$HOME/win64
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make -j 8
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make install
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make check
  
  and the whole test suite passes now.
  
User choice is great; one can choose between malfunctioning libc or
explicitly ask for a correct one.

Should we pass this option for mingw on GMP's configure.ac?
Or do people expect broken libc on this platform...?


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

Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

2017-03-31 Thread Claude Heiland-Allen 
Hi Marc,

On 31/03/17 00:27, Marc Glisse wrote:
> On Thu, 30 Mar 2017, Vincent Lefevre wrote:
> 
>> On 2017-03-30 10:52:33 +0100, Claude Heiland-Allen wrote:
>>> The failing source code is:
>>>
>>>   /* EOF for no matching */
>>>   {
>>> char buf[128];
>>> ret = gmp_sscanf ("   ", "%s", buf);
>>> ASSERT_ALWAYS (ret == EOF);
>>> ret = fromstring_gmp_fscanf ("   ", "%s", buf);
>>> ASSERT_ALWAYS (ret == EOF);
>>> if (option_libc_scanf)
>>>   {
>>> ret = sscanf ("   ", "%s", buf);
>>> ASSERT_ALWAYS (ret == EOF);
>>> ret = fun_fscanf ("   ", "%s", buf, NULL);
>>> ASSERT_ALWAYS (ret == EOF);
>>>   }
>>>   }
>>>
>>> Commenting out the asserts and 'if' and inserting debugging printf()
>>> statements gives:
>>>
>>> gmp_sscanf() ret = 0
>>> fromstring_gmp_fscanf() ret = 0
>>> sscanf() ret = 0
>>  
>>> fun_fscanf() ret = 0
>>
>> The initial issue is the 0 returned by sscanf(). Then GMP is consistent
>> with the C implementation.
>>
>> Though the C standard may be ambiguous, 0 is not possible as a return
>> value. Thus this is a bug in the C library (or compiler).
> 
> Could the macro __USE_MINGW_ANSI_STDIO be relevant?

Yes, perfect!  I did

CPPFLAGS=-D__USE_MINGW_ANSI_STDIO ./configure
--host=x86_64-w64-mingw32 --prefix=$HOME/win64
CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make -j 8
CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make install
CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make check

and the whole test suite passes now.

Thanks,


Claude
-- 
https://mathr.co.uk
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs