Menu
▾
▴
#186 SPEC CPU2006 compile errors
Trying to compile SPEC CPU2006 bench with sezero_20100711_w64 + runtime_update_3510 under Windows 7 x64.
Here is results:
Build errors: 400.perlbench(base; CE), 435.gromacs(base; CE), 436.cactusADM(base; CE), 444.namd(base; CE), 471.omnetpp(base; CE), 481.wrf(base; CE), 483.xalancbmk(base; CE)
Build successes: 401.bzip2(base), 403.gcc(base), 410.bwaves(base), 416.gamess(base), 429.mcf(base), 433.milc(base), 434.zeusmp(base), 437.leslie3d(base), 445.gobmk(base), 447.dealII(base), 450.soplex(base), 453.povray(base), 454.calculix(base), 456.hmmer(base), 458.sjeng(base), 459.GemsFDTD(base), 462.libquantum(base), 464.h264ref(base), 465.tonto(base), 470.lbm(base), 473.astar(base), 482.sphinx3(base), 998.specrand(base), 999.specrand(base)
As you can see, 7 tests couldn't be compiled. I've attached archive with my config, error messages and related source files.
Config, error messages and related sources
I don't have SPEC CPU2006 suite (and I don't think it's free ;), so I can't be sure without seeing all the dependency header & all, but all these errors seem to be arising from bad configuration or something similar. Eg. how is it that stricmp is declared with 'C++' linkage in one the suite's headers?
* 400.perlbench : spec_config.h has a weird configuration about some
HASATTRIBUTE and undefines it at line 893, then defines __attribute__
as nothing at lines 1180-1183 (because HASATTRIBUTE is never defined).
That __attribute__ being an empty definition makes the intrinsics
headers crazy. Commented out 893 and 1180-1183, the av.c file compiled
but I don't know what side effects it may cause.
* 435.gromacs : Why is the -D_maths_h in PORTABILITY switches
in Makefile.spec? That prevents maths.h from including <math.h>
which would have brought the correct prototype of sqrt()
If I remove -D_maths_h from the flags, calch.c compiles OK.
* 436.cactusADM : Can't find the file Cactus/File.c in there, so
I copied it from the small mingw64_cpu2006_errors.zip package.
Problem is with the MKDIR_WRAPPER macro which relies on the
mode_t data type availability: MinGW variants provide this type
for compatibility and it fools File.c. I changed the condition
from #ifdef HAVE_MODE_T
... to
#if defined(HAVE_MODE_T) && !defined(_WIN32)
... and Cactus/File.c compiled OK.
* 444.namd : cast from 'BigReal*' to 'long int' loses precision
warning is to be expected because _WIN64 does not follow _LP64
where long type is pointer size, but it follows _LLP64 where
long is strictly 32 bits. Changing the long cast to intptr_t
may be the solution here.
* 471.omnetpp: deprecated conversion from string constant to 'char*'
are expected with g++-4.x. The ambiguous overload error from the
MACRelayUnitBase.cc file, my 20100711 build does do that, yes. I
cannot reproduce it with linux. Can you please try this one with
one of the automated builds, and see if it still errors out? (And
I am not that good with C++, others may hlep better with this.)
* 481.wrf : Well, netcdf/posixio.c line 1365 assumes too much when
S_IRUSR is defined. Changing the #ifdef S_IRUSR condition there to
#if defined(S_IRUSR) && !defined(_WIN32)
... makes the file to compile OK.
* 483.xalancbmk : GCCDefs.cpp and xercesc/util/Compilers/GCCDefs.hpp
have notes of applied fixes about CYGWIN incompatibilities with the
stricmp and strnicmp functions, but not for MinGW. Editing those two
files and changing the condition from #ifndef __CYGWIN__ to
#if !(defined(__CYGWIN__) || defined(__MINGW32__))
... just eliminates the error and Win32PlatformUtils.cpp compiles OK.
Another errors
I've updated MinGW64 to the last automated build and tried all the solutions. Here is the results:
400.perlbench - SUCCESS
435.gromacs - another error occured.
436.cactusADM - another error occured.
444.namd - I didn't understand what definitely I should patch?
471.omnetpp - the same error on the last automated build.
481.wrf - SUCCESS
483.xalancbmk - another error occured.
All new errors are attached as mingw64_cpu2006_errors_2.zip.
BTW, is it possible for me to patch MinGW headers instead of CPU2006 sources? As I said modifying sources is disallowed.
> 435.gromacs - another error occured.
>
Well, futil.h is declaring a function named eof, whereas the system
provides a similar one but with surely not with the same return type
and argument. Code should be fixed.
> 436.cactusADM - another error occured.
>
Code assumes LP64 ie. sizeof long == sizeof void* which is not
correct for win64 where sizeof long == 4. Code should use uintptr_t
instead of unsigned long.
> 444.namd - I didn't understand what definitely I should patch?
>
Similar case above: casting a pointer to long type on win64
truncates it because win64 is not LP64, it is LLP64. instead of
the casting to long, code should cast to intptr_t
> 471.omnetpp - the same error on the last automated build.
>
I already forwarded this error to our admin
> 481.wrf - SUCCESS
>
> 483.xalancbmk - another error occured.
>
The XMLCh type is typedef'ed as unsigned short instead of wchar_t
through xercesc/util/Compilers/GCCDefs.hpp line 168. Fix the code
and it compiles
> All new errors are attached as mingw64_cpu2006_errors_2.zip.
>
> BTW, is it possible for me to patch MinGW headers instead of CPU2006
> sources? As I said modifying sources is disallowed.
No: We patch our headers when our headers are broken, NOT when an
external source is broken.
The ambiguous overload error from the 471.omnetpp test, I forwarded to Kai. If he spares time to look at it, OK. If not, none of the other errors are due to mingw-w64 crt or headers, so this should be closed by whoever has the privileges.
Closing as invalid as there are no mingw-w64 bugs here.