[cfe-dev] MinGW problem with GSL

[Ruben Van Boxem]

2011/7/6 Eric Christopher <echristo at apple.com>:
>
> On Jul 6, 2011, at 2:37 PM, Ruben Van Boxem wrote:
>
>> GCC does not have this problem. I can't discern any notable difference
>> in config.log. Could it be something wrt passing options down to the
>> GNU tools?
>
> Two things:
>
> a) try passing -no-integrated-as to see if it's a problem with passing down arguments

Same problem. I have also verified all the commands being run against
a matching GCC install.

> b) try to get a testcase of the failing instructions

Heh, well, yeah. Euhm... My assembly isn't that... good, and that's
being optimistic. As in, I know *nothing* about it, except that it
exists. So here I go:

The bits of assembly causing the problem are these:

.Ltmp224:
	.loc	4 129 5
	movsd	%xmm6, -616(%rbp)
	fldl	-616(%rbp)
	fstpt	-772(%rbp)
	fld	%ss
	#APP
	fabs;
	#NO_APP
	fstpl	-624(%rbp)
	movsd	.LCPI3_10(%rip), %xmm0
...
.Ltmp521:
	fstpt	-656(%rbp)
	fld	%ss
	#APP
	fabs;
	#NO_APP

I can't find these or even similar bits in GCC's output, which
probably isn't surprising.

The source file this comes from is pretty big, with a lot of GSL
specific functionality being used (kind of expected). I do know GCC
does not have a "fld" instruction anywhere in its version of the
assembler output.

Would this have anything to do with the <ieeefp.h> header? This is
used when Clang is used, but a mingw-w64 (which provides the header)
dev told me it includes ansidecl.h which is a GCC internal header. It
defines (among a *lot* of other things) some va_args things, but
there's no error when clang parses this file, so it probably is not
causing the issue. Plus, the only place where it's being used is GSL's
sys/infnan.c (grep -r , which couldn't possibly be included in the
file causing the error.

I also tried a i686-w64-mingw32 built Clang with matching mingw-w64
CRT and GCC. It hits the same problem.

Any tips on what simple testcase couldd produce an fld instruction?
GCC doesn't in this case, which only adds to the oddity.

Thanks,

Ruben