MinGW problem with GSL

Clang Frontend
1

Hi,

Clang seems to have a problem with some assembler files when building
GSL (configured with --host=x86_64-w64-mingw32 CC="clang -v"):

libtool: compile: clang -v -DHAVE_CONFIG_H -I. -I/m/Development/Source/gsl-1.15/specfunc -I.. -I/m/Development/Source/gsl-1.15 -g -O2 -MT hyperg_1F1.lo -MD -MP -MF .deps/hyperg_1F1.Tpo -c /m/Development/Source/gsl-1.15/specfunc/hyperg_1F1.c
clang version 3.0 (http://llvm.org/git/clang.git 5cbe101b502e06d16bc77df45a27ce8bc13f33c8)
Target: x86_64-w64-mingw32
Thread model: posix
"m:/Development/mingw64/bin/clang.exe" -cc1 -triple x86_64-w64-mingw32 -S -disable-free -disable-llvm-verifier -main-file-name hyperg_1F1.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.1.20110627 -momit-leaf-frame-pointer -v -g -coverage-file C:/Users/Ruben/AppData/Local/Temp/cc-236916.s -resource-dir m:/Development/mingw64/bin\..\lib\clang\3.0 -dependency-file .deps/hyperg_1F1.Tpo -sys-header-deps -MP -MT hyperg_1F1.lo -D HAVE_CONFIG_H -I . -I m:/Development/Source/gsl-1.15/specfunc -I .. -I m:/Development/Source/gsl-1.15 -O2 -ferror-limit 19 -fmessage-length 500 -fno-use-cxa-atexit -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o C:/Users/Ruben/AppData/Local/Temp/cc-236916.s -x c m:/Development/Source/gsl-1.15/specfunc/hyperg_1F1.c
clang -cc1 version 3.0 based upon llvm 3.0svn hosted on x86_64-w64-mingw32
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "m:/Development/mingw64/bin/../lib/clang/3.0/../../../i686-w64-mingw32/include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "c:/mingw/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
.
m:/Development/Source/gsl-1.15/specfunc
..
m:/Development/Source/gsl-1.15
m:/Development/mingw64/bin/../lib/clang/3.0/include
m:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include
m:/Development/mingw64/bin/../lib/clang/3.0/../../../include
End of search list.
"m:/Development/mingw64/bin/gcc.exe" -v -D HAVE_CONFIG_H -I . -I m:/Development/Source/gsl-1.15/specfunc -I .. -I m:/Development/Source/gsl-1.15 -O2 -MT hyperg_1F1.lo -MD -MP -MF .deps/hyperg_1F1.Tpo -c -m64 -o hyperg_1F1.o -x assembler C:/Users/Ruben/AppData/Local/Temp/cc-236916.s
Using built-in specs.
COLLECT_GCC=m:/Development/mingw64/bin/gcc.exe
COLLECT_LTO_WRAPPER=m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure --host=x86_64-w64-mingw32 --build=x86_64-gnu-linux --target=x86_64-w64-mingw32 --with-sysroot=/home/ruben/mingw-w64/toolchain/mingw64/mingw64 --prefix=/home/ruben/mingw-w64/toolchain/mingw64/mingw64 --with-libiconv-prefix=/home/ruben/mingw-w64/toolchain/mingw64/libs --with-libexpat-prefix=/home/ruben/mingw-w64/toolchain/mingw64/libs --with-gmp=/home/ruben/mingw-w64/toolchain/mingw64/libs --with-mpfr=/home/ruben/mingw-w64/toolchain enable-lto --disable-multilib --disable-win32-registry --disable-rpath --disable-werror CFLAGS='-O2 -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all' LDFLAGS=
Thread model: win32
gcc version 4.6.2 20110705 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-D' 'HAVE_CONFIG_H' '-I' '.' '-I' 'm:/Development/Source/gsl-1.15/specfunc' '-I' '..' '-I' 'm:/Development/Source/gsl-1.15' '-O2' '-MT' 'hyperg_1F1.lo' '-MD' '-MP' '-MF' '.deps/hyperg_1F1.Tpo' '-c' '-m64' '-o' 'hyperg_1F1.o' '-mtune=generic' '-march=x86-64'
m:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.2/../../../../x86_64-w64-mingw32/bin/as.exe --64 -o hyperg_1F1.o C:/Users/Ruben/AppData/Local/Temp/cc-236916.s
C:/Users/Ruben/AppData/Local/Temp/cc-236916.s: Assembler messages:
C:/Users/Ruben/AppData/Local/Temp/cc-236916.s:1198: Error: operand type mismatch for `fld'
C:/Users/Ruben/AppData/Local/Temp/cc-236916.s:2824: Error: operand type mismatch for `fld'
clang: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation)
make[2]: *** [hyperg_1F1.lo] Error 1
make[2]: Leaving directory `/home/Ruben/gsl/specfunc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Ruben/gsl'
make: *** [all] Error 2

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?

Ruben

2

Two things:

a) try passing -no-integrated-as to see if it's a problem with passing down arguments
b) try to get a testcase of the failing instructions

Thanks!

-eric

3

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

4

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.

Good to know.

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.

Not sure that's really important at the moment, it might be nice to get
you to file a bug report with a preprocessed source file testcase
and the command line that'll get this to show.

Thanks!

-eric

5

Sorry for the delay in getting these files to you, but since then the
problem has gone away. GSL compiles fine, although the first test
fails (keeps running endlessly). But I will investigate the cause
here.

Ruben

6

Sorry for the delay in getting these files to you, but since then the
problem has gone away. GSL compiles fine, although the first test
fails (keeps running endlessly). But I will investigate the cause
here.

Excellent. Thanks!

-eric