Possible issue on windows build (mingw)

[Torbjorn Granlund]

Vlad Gabriel <clampi at yahoo.com> writes:

  I confirm that the assert issue (toom_eval_pm2exp.c:112) was solved by patch 2.
  
Thanks!

  The issue with t-gcd and t-get_d is reproducible. I have to have present either of
  mpn/x86_64/coreinhm/gcd_1.asm
  
  mpn/x86_64/core2/gcd_1.asm
  mpn/x86_64/gcd_1.asm

I am stuck here, since I see nothing wrong with the code, nor am I able
to reproduce the gcd_1 problems on my machine.  This could be a compiler
problem (you're using a prerelease, I think) or a GMP--windoze
compatibility problem.

Can you see someting wrong with (say) core2/gcd_1.asm?

Perhaps you could even run a debugger session over the file, comparing
it to a valid run with the same arguments (on a GNU/Linux or BSD
system)?

There are two things to be suspicious about: (1) the entry/exit sequence
(see the DOS64_ENTRY and DOS64_EXIT macros, and (2) the calls to
mpn_mod_1 and mpn_modexact_1_odd.

Does the code work if you change all

	sub	$8, %rsp
and
	add	$8, %rsp

instructions in the used gcd_1.asm to

	sub	$40, %rsp
and
	add	$40, %rsp

respectively?  (The C version of this file, when compiled to assembly
has such seemingly useless stack allocation.  I'll check the windoze ABI
docs to understand this better, before releasing this code.)

  For reference, 'mpn/x86_64/coreinhm/gcd_1.asm' and
  'mpn/x86_64/core2/gcd_1.asm' are the same file. Even if that would
  have not caused error on my end, I think is not supposed to have the
  same file for 2 processors, but have configure do the link.
  
I don't think there is any file at mpn/x86_64/coreinhm/gcd_1.asm
(neither in the repo nor in any recent snapshot).  There are
"implementation files" in mpn/x86_64/gcd_1.asm and
mpn/x86_64/core2/gcd_1.asm, plus "grabber files" in
mpn/x86_64/nano/gcd_1.asm, mpn/x86_64/bd1/gcd_1.asm, and
mpn/x86_64/k10/gcd_1.asm.
  
  There is something I have not mentioned in any of my previous mails,
  something that was brought up a while ago to your attention but did
  not get any resolution. Test cxx/t-locale is irrelevant for windoze
  targets (PE-COFF). This is due to the test being dependent of the weak
  symbols concept. That is not supported by PE-COFF targets (mingw32/64
  and cygwin as far as I know). In my opinion it should be skipped from
  makefile for those targets, as simply ignoring the test from int
  main(){std::cout<<"Not supported on Windoze"<<endl;} would still cause
  a duplicate symbol at link time in clocale.o.

I am not sure I follow.  Does it cause a real problem?  I prefer to keep
configure complexity down (this my striving might not be obvious from
the current complexity...) and ony address actual problems, not somewhat
hypothetical problems.  (I don't indend to be rude here, please don't
read it as a rude reply!)

-- 
Torbjörn