Re: Tests fail on MinGW

[Peter Rosin <peda at lysator dot liu dot se>]

Peter Rosin skrev 2012-03-14 10:05:
> Hi!
> 
> I experience failures in the testsuite when I run on MinGW.
> 
> I have:
> 
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=C:\MinGW\bin\gcc.exe
> COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
> Target: mingw32
> Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
> Thread model: win32
> gcc version 4.6.2 (GCC)
> 
> Which is a standard install from MinGW. I'm using libffi from
> git-master.
> 
> Since I don't have dejagnu in my MSYS install, I tried to run some
> of the tests in the testsuite manually and I'm seeing things that
> don't look right.
> 
> E.g.
> 
> After:
> 
> mkdir mingw; cd mingw; ../configure; make # all looks good
> 
> I do this:
> 
> $ ./libtool --tag=CC --mode=link gcc -g -Iinclude -I../include -I. \
>   ../testsuite/libffi.call/huge_struct.c libffi.la -o huge_struct
> $ ./huge_struct
> 1 2 3 4 5 6 7 8 9 10 -0 0x4002 305419896 1 2 3 4 5 30064771078 34359738368 0 0 0 0xb0000000 16386 305419896 1 2 3 4 25769803781 7 0 9 10 0 2952790016 16386 22136 1 2 3 21474836484 30064771078 0 0 0 0x40240000 0 -1342177280: 16386 305419896 1 2 2 3 21474836484 30064771078 0 0 10 0 1076232192 0 0 16386 305419897 3 21474836484 30064771078 0 0 0 0x40260000 0 1076363264 0 0 2637826 305419898 21474836484 30064771078 0 0 0 0 1076363264 0 0 0 3758096384 16386 21780256379 30064771078 0 0 0 0 0 1076494336
> res: 2 3 4 5 6 7 8 9 10 11 -2 0x4002 305419897 3 4 5 6 7 38654705672 42949672960 0 0 0 0xd0000000 2637826 305419898 4 5 6 7 38654705672 10 0 12 13 0 3758096384 2010923010 22139 5 6 7 38654705672 47244640266 0 0 0 0x402c0000 0 -268435456
> 1 2 3 4 5 6 7 8 9 10 -0 0xc0004002 305419896 1 2 3 4 5 30064771078 34359738368 0 0 0 0xb0000000 16386 305419896 1 2 3 4 25769803781 7 0 9 10 0 2952790016 1076510722 22136 1 2 3 21474836484 30064771078 0 0 0 0x40240000 0 -1342177280: 16386 305419896 1 2 2 3 21474836484 30064771078 0 0 10 0 1076232192 0 0 16386 305419897 3 21474836484 30064771078 0 0 0 0x40260000 0 1076363264 0 0 2637826 305419898 21474836484 30064771078 0 0 0 0 1076363264 0 0 0 3758096384 16386 21780256379 30064771078 0 0 0 0 0 1076494336
> res: 2 3 4 5 6 7 8 9 10 11 -2 0x12344002 305419897 3 4 5 6 7 38654705672 42949672960 0 0 0 0xd0000000 16386 305419898 4 5 6 7 38654705672 10 0 12 13 0 3758096384 16386 22139 5 6 7 38654705672 47244640266 0 0 0 0x402c0000 0 -268435456
> 
> From reading the comments in the huge_struct.c source, I gather that the
> output should be:
> 
> 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7
> res: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7
> 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7
> res: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7
> 
> Question is, am I doing something bad, or should the above work?

The web suggests that the MinGW printf thinks that "long double" is 64 bits
(or rather, the MSVCRT printf thinks that) but that can be changed (to 80
bits) by adding -posix when compiling. Doing that, I get:

$ ./libtool --tag=CC --mode=link gcc -posix -g ../testsuite/libffi.call/huge_struct.c -Iinclude -I../include -I. libffi.la -o huge_struct
$ ./huge_struct
1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7
res: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7
1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7
res: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7

So, it seems this is a testsuite issue...

Cheers,
Peter