Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

Intel C++ Compiler internal error: 04010002_15114

sav
Novice
2,868 Views

Hi everyone,

For MPFR build using ICC on Windows got error:

error : 04010002_15114

which relate to '__assume' statement, as Pavel Holoborodko mentioned below. Reproduced for ICC builds using compiler key '-O3' (Highest Optimization) (logs added in attachment).
 

Environment:
- Windows 10 x64,

- Visual Studio 2015 Update 1 with integrated Intel Parallel Studio XE 2016 Update 1,
- MPIR-2.7.2 sources
 (http://mpir.org/mpir-2.7.2.zip),
- MPFR with Visual Studio 2015 (
https://github.com/BrianGladman/mpfr).
 

Steps to reproduce error:
1. select 'Clone or download → Download ZIP' on https://github.com/wbhart/mpir ,
2. select 'Clone or download → Download ZIP' on https://github.com/BrianGladman/mpfr ,
3. extract both downloaded zip-archives in same directory and rename directory 'mpir-master' to 'mpir', so you'll get directory structure:

<some dir>\mpfr-master\build.vc14
<some dir>\mpfr-master\...
<some dir>\mpir\build.vc14
<some dir>\mpir\...

4. open solution 'mpir\build.vc14\mpir.sln' and:
- convert it to use Intel Compiler,
- select Release configuration and any platform,
- build 'dll_mpir_gc' aor 'lib_mpir_gc' project,
5. open solution 'mpfr-master\build.vc14\dll_mpfr.sln' and/or 'mpfr-master\build.vc14\lib_mpfr.sln' (depending on which of '*_mpir_gc' projects you've built on previous step) and:
- convert it to use Intel Compiler,
- select Release configuration and same platform, which was used while building MPIR binaries,
- set '/O3' compiler parameter to 'dll_mpfr' aor 'lib_mpfr' project (depending on which solution you've opened) and build it; this reproduce 'error 04010002_15114' in build log.

Error inherent to bundle Windows 7 + Visual Studio 2013 + Intel Parallel Studio XE 2015 too, but not reproduced for builds using MSVC. MPFR developers have come to the conclusion that this is an ICC bug.

 

Alexander

 

0 Kudos
1 Solution
pbkenned1
Employee
2,868 Views

The /O1 issue has been isolated and reported to the developers. I will pass along updates I receive from them.

Internal tracking ID:  DPD200380610

Patrick

View solution in original post

0 Kudos
17 Replies
TimP
Honored Contributor III
2,868 Views

To get it fixed, the best route might be to isolate the Visual Studio build which fails, and submit the case on premier.intel.com.

I can't tell from a cursory view of your logs whether you are actually attempt parallel build, and whether that might be implicated.

I guess you haven't tried setting -Qipo- or both that and -Qip- but if you haven't tried those, it's a stretch to claim that only -Od works.  I don't know if there's much value in inter-procedural optimization when it cuts off at an arbitrary point due to hitting compiler limits.

I'd be curious what value might be expected from building mpir/mpfr with Intel compiler with aggressive optimization.  That's not to say that you shouldn't report the bug after going as far as you have done, but it might affect the priority.

I assume it's not normally built with such aggressive optimizations.  MSVC++ cuts down the aggressiveness of the quoted options;  it defaults to /fp:precise, I believe, which might be appropriate anyway to this type of application, and more in line with the options which people use with gcc/g++ (for example, I doubt people would set -ffast-math or even -O3 or -flto, which are nearest equivalents of options you are using with ICL).  Even if you set MSVC++ to /fp:fast, that is closer to ICL /fp:source than to ICL default.

0 Kudos
sav
Novice
2,868 Views

Hi,

I have no access to premier.intel.com , so I can't submit my case there. But it would be great, if someone can do this for me.

I doubt that I can isolate source of error more more accurately than now. Seems that it scattered in various files:

MPFR\src\exceptions.c:
return mpfr_overflow (x, rnd_mode, MPFR_SIGN(x));
or
MPFR_ASSERT_SIGN (sign);
 
MPFR\src\rec_sqrt.c:
MPFR_ASSERTD((a + an <= x) || (x + n <= a));

MPFR\src\set_d.c:
MPFR_ASSERTD(!DOUBLE_ISNAN(d));

etc. I expected that Compiler developers will reproduce the error and thus find its source.

Concerning usage of aggressive Optimization options. MPFR successfully built and passes *all* tests using Microsoft Compiler with (/Ox) key and using MinGW-W64 with (-O3) key. But it fails to build using Intel Compiler even with (/O1) key. Is Intel Optimization (/O1) more aggressive that Microsoft (/Ox) or MinGW-W64 (-O3)?

I've also updated in my previous post, that for all builds using Visual Studio 'Floating Point Model' was set to (/fp:strict). Just tested, changing it to (/fp:precise) didn't solve error.

 

Regards,

Alexander

0 Kudos
pbkenned1
Employee
2,868 Views

Hello,

>>>Visual Studio 2015 Update 1 with integrated Intel Parallel Studio XE 2016 Update 1

VS 2015 Update 1 is not yet supported by IPSXE 2016.  For example, see https://software.intel.com/en-us/articles/limits1120-error-identifier-builtin-nanf-is-undefined

I can't tell if that might be the underlying cause of the obscure internal compiler error or not, but eventually something will break.  You said VS 2013 has a similar issue -- was that an internal compiler error?  I can check with VS2013 or VS2015 (initial release).

Patrick

0 Kudos
sav
Novice
2,868 Views

Hi,

Actually the easiest way to solve 'limits(1120): error' is add lines
#ifdef __INTEL_COMPILER
 #define __builtin_huge_val() HUGE_VAL
 #define __builtin_huge_valf() HUGE_VALF
 #define __builtin_nan nan
 #define __builtin_nanf nanf
 #define __builtin_nans nan
 #define __builtin_nansf nanf
#endif
to file 'Microsoft Visual Studio 14.0\VC\include\limits' until official fix would be released. At least it worked for me (all tests in my first post were made using VS 2015 + IPSXE 2016 both *with* Update 1).

If this not an option, you can use previous versions of VS 2015 + IPSXE 2016 (both without Update 1) to reproduce error 04010002_15114'.

I'm not sure if it's possible to reproduce error with VS 2013 + IPSXE 2015 now, but I got it before with old 'MPFR with Visual Studio' solution (http://173.254.28.24/~brgladma//oldsite/computing/mpfr.svn9046.build.vc12.zip , no warrancy it would work as MPFR svn repository changes rapidly).


Regards,

Alexander

 

0 Kudos
pbkenned1
Employee
2,869 Views

>>>'C:\libMPFR-3.2.0-dev-9769\src\src\exceptions.c(285) (col. 16): internal error: 04010002_15114'

Yes, this can be reproduced at /O1 or higher using icl-16.0.1:

C:\ISN_Forums\U605854\mpfr-master\build.vc14\dll_mpfr>icl  /O1 /c exceptions.c /MP /GS- /W3 /Zc:wchar_t  /I"C:\ISN_Forums\U605854\mpfr-master\build.vc14" /I"C:\ISN_Forums\U605854\mpir\build.vc14\dll_mpir_gc\x64\Release"  /I"C:\ISN_Forums\U605854\mpfr-master\src"  /I"..\" /I"..\..\" /I"..\..\..\mpir\dll\x64\Release\" /Zi /O1 /Fd"x64\Release\vc140.pdb" /fp:strict /D "WIN32" /D"_WIN32" /D "HAVE_CONFIG_H" /D"NDEBUG" /D"_LIB" /D"__MPFR_WITHIN_MPFR" /D"_GMP_IEEE_FLOATS" /D"_CRT_SECURE_NO_WARNINGS" /D "HAVE_STDINT_H" /D "__GMP_LIBGMP_DLL" /D "MPFR_USE_THREAD_SAFE" /D "MPFR_HAVE_GMP_IMPL" /GT /Zc:forScope /Oi /MD /Fa"x64\Release\"
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.1.146 Build 20151021
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

exceptions.c
C:\ISN_Forums\U605854\mpfr-master\build.vc14\dll_mpfr\exceptions.c(388) (col. 3)
: internal error: 04010002_15114

icl: error #10298: problem during post processing of parallel object compilation

I also see the same error for  mpn_exp.c set_z_exp.c at /O1 or higher.  All three will compile without optimization:

C:\ISN_Forums\U605854\mpfr-master\build.vc14\dll_mpfr>comp_icl-16.0.1.146_exceptions_mpn_exp_set_z_exp_arg.bat /Od

C:\ISN_Forums\U605854\mpfr-master\build.vc14\dll_mpfr>icl  /Od /c exceptions.c mpn_exp.c set_z_exp.c /MP /GS- /W3 /Zc:wchar_t  /I"C:\ISN_Forums\U605854\mpfr-master\build.vc14" /I"C:\ISN_Forums\U605854\mpir\build.vc14\dll_mpir_gc\x64\Release
"  /I"C:\ISN_Forums\U605854\mpfr-master\src"  /I"..\" /I"..\..\" /I"..\..\..\mpir\dll\x64\Release\" /Zi /Od /Fd"x64\Release\vc140.pdb" /fp:strict /D "WIN32" /D"_WIN32" /D "HAVE_CONFIG_H" /D "NDEBUG" /D "_LIB" /D "__MPFR_WITHIN_MPFR" /D "_GMP_IEEE_FLOATS" /D "_CRT_SECURE_NO_WARNINGS" /D "HAVE_STDINT_H" /D "__GMP_LIBGMP_DLL" /D "MPFR_USE_THREAD_SAFE" /D "MPFR_HAVE_GMP_IMPL" /GT /Zc:forScope /Oi /MD /Fa"x64\Release\"
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.1.146 Build 20151021
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

exceptions.c
mpn_exp.c
set_z_exp.c

C:\ISN_Forums\U605854\mpfr-master\build.vc14\dll_mpfr>

There's no issue with VC.14, even with full optimization (/Ox), although some interesting warnings:

C:\ISN_Forums\U605854\mpfr-master\build.vc14\dll_mpfr>cl  /Ox /c exceptions.c mpn_exp.c set_z_exp.c /MP /GS- /W3 /Zc:wchar_t  /I"C:\ISN_Forums\U605854\mpfr-master\build.vc14" /I"C:\ISN_Forums\U605854\mpir\build.vc14\dll_mpir_gc\x64\Release"
  /I"C:\ISN_Forums\U605854\mpfr-master\src"  /I"..\" /I"..\..\" /I"..\..\..\mpir\dll\x64\Release\" /Zi /Ox /Fd"x64\Release\vc140.pdb" /fp:strict /D "WIN32" /D "_WIN32" /D "HAVE_CONFIG_H" /D "NDEBUG" /D "_LIB" /D "__MPFR_WITHIN_MPFR" /D "_GMP_IEEE_FLOATS" /D "_CRT_SECURE_NO_WARNINGS" /D "HAVE_STDINT_H" /D "__GMP_LIBGMP_DLL" /D "MPFR_USE_THREAD_SAFE" /D"MPFR_HAVE_GMP_IMPL" /GT /Zc:forScope /Oi /MD /Fa"x64\Release\"
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

exceptions.c
mpn_exp.c
set_z_exp.c
mpn_exp.c(63): warning C4244: '=': conversion from 'UWtype' to 'mpfr_exp_t', possible loss of data
mpn_exp.c(75): warning C4267: '=': conversion from 'size_t' to 'mpfr_exp_t', possible loss of data
mpn_exp.c(78): warning C4244: '=': conversion from 'UWtype' to 'unsigned long',possible loss of data
set_z_exp.c(60): warning C4244: '=': conversion from 'UWtype' to 'int', possible loss of data
mpn_exp.c(90): warning C4267: '=': conversion from 'size_t' to 'unsigned long',possible loss of data
set_z_exp.c(91): warning C4146: unary minus operator applied to unsigned type, result still unsigned
mpn_exp.c(112): warning C4146: unary minus operator applied to unsigned type, result still unsigned
mpn_exp.c(112): warning C4267: '=': conversion from 'size_t' to 'mpfr_exp_t', possible loss of data

C:\ISN_Forums\U605854\mpfr-master\build.vc14\dll_mpfr>

I'll need to do a bit of packaging work, then I'll report this to the developers.

Patrick

0 Kudos
sav
Novice
2,869 Views

I'm not sure whether "conversion from 'UWtype' to 'mpfr_exp_t'" and other warnings of Microsoft Compiler worth the attention of Intel C++ Compiler developers or not. Fortunately IPSXE 2016 has no such troubles. I have got rid lot of MPFR build warnings when moved to C11 standard compliant compilers. Thus one of possible sources of Microsoft Compiler warnings is it non-compliance to C99/C11 standard.

 

Regards,

Alexander

 

0 Kudos
pbkenned1
Employee
2,869 Views

The /O1 issue has been isolated and reported to the developers. I will pass along updates I receive from them.

Internal tracking ID:  DPD200380610

Patrick

0 Kudos
Pavel_Holoborodko__A
2,869 Views

I confirm the same issue happens in XE 2016 Update 2 (+ MSVC 2015 Update 1). Is there any plans when it will be fixed?

Thank you very much for your efforts.

 

 

 

0 Kudos
Pavel_Holoborodko__A
2,869 Views

This bug has something to do with __assume statement (Microsoft specific). Intel compiler chokes with aforementioned error only on this statement. 

To make it work, edit the mpfr-impl.h:

#elif defined(_MSC_VER) && !defined(__INTEL_COMPILER) // <-- add last conditional
# define MPFR_ASSUME(x) __assume(x)
#else
# define MPFR_ASSUME(x) ((void) 0)
#endif

Add conditional, so that there is no __assume used in case of Intel compiler.

0 Kudos
sav
Novice
2,869 Views

Error reproduced for builds using VS 2015 Update 3 + IPSXE 2017 Update 2 with '/O3' compiler key only. Tested for x64+Release+Shared configuration:

mpfr_ICC_build_environment.jpg

 

Alexander

 

0 Kudos
sav
Novice
2,869 Views

I've managed to snatch MPFR build using ICC command from Visual Studio:

mpfr_ICC_command_prompt_build_1.jpg

mpfr_ICC_command_prompt_build_2.jpg

And now a Command Prompt based solution available to reproduce this error:

1. Extract MPFR github sources (see 1st post) from ZIP archive to some directory, e.g. 'C:\TEST', so it would look like:

c:\TEST\mpfr-master\build.vc14\
...
c:\TEST\mpfr-master\VERSION

2. Extract headers from MPIR Shared+x64+Release build (added in attachment) to the same directory, so it would look like:

c:\TEST\mpir\dll\x64\Release\config.h
...
c:\TEST\mpir\dll\x64\Release\longlong.h

(this isn't enough to complete MPFR build, but is a workaround for case, when VS not available to build MPIR binaries),

3. Run 'Compiler 17.0 Update 2 for Intel 64 Visual Studio 2015 environment' command prompt from Windows Start menu,

4. Change to MPFR 'dll_mpfr.vcxproj' project directory:

cd c:\TEST\mpfr-master\build.vc14\dll_mpfr

5. Make output directory for MPFR binaries:

md x64\Release

6. Run command:

icl /c /Qm64 /I..\ /I..\..\ /I..\..\..\mpir\dll\x64\Release\ /Zi /nologo /W3 /O3 /Oi /GT /D __INTEL_COMPILER=1700 /D WIN32 /D _WIN32 /D HAVE_CONFIG_H /D NDEBUG /D _LIB /D __MPFR_WITHIN_MPFR /D _GMP_IEEE_FLOATS /D _CRT_SECURE_NO_WARNINGS /D HAVE_STDINT_H /D __GMP_LIBGMP_DLL /D MPFR_USE_THREAD_SAFE /D MPFR_HAVE_GMP_IMPL /EHsc /MD /GS- /fp:strict /Zc:wchar_t /Zc:forScope /Fo"x64\Release\\" /Fd"x64\Release\vc140.pdb" /TC ..\..\src\abort_prec_max.c ..\..\src\acos.c ..\..\src\acosh.c ..\..\src\add.c ..\..\src\add1.c ..\..\src\add1sp.c ..\..\src\add_d.c ..\..\src\add_ui.c ..\..\src\agm.c ..\..\src\ai.c ..\..\src\asin.c ..\..\src\asinh.c ..\..\src\atan.c ..\..\src\atan2.c ..\..\src\atanh.c ..\..\src\bernoulli.c ..\..\src\beta.c ..\..\src\buildopt.c ..\..\src\cache.c ..\..\src\cbrt.c ..\..\src\check.c ..\..\src\clear.c ..\..\src\clears.c ..\..\src\cmp.c ..\..\src\cmp2.c ..\..\src\cmp_abs.c ..\..\src\cmp_d.c ..\..\src\cmp_ld.c ..\..\src\cmp_si.c ..\..\src\cmp_ui.c ..\..\src\comparisons.c ..\..\src\const_catalan.c ..\..\src\const_euler.c ..\..\src\const_log2.c ..\..\src\const_pi.c ..\..\src\constant.c ..\..\src\copysign.c ..\..\src\cos.c ..\..\src\cosh.c ..\..\src\cot.c ..\..\src\coth.c ..\..\src\csc.c ..\..\src\csch.c ..\..\src\d_div.c ..\..\src\d_sub.c ..\..\src\digamma.c ..\..\src\dim.c ..\..\src\div.c ..\..\src\div_2exp.c ..\..\src\div_2si.c ..\..\src\div_2ui.c ..\..\src\div_d.c ..\..\src\div_ui.c ..\..\src\dump.c ..\..\src\eint.c ..\..\src\eq.c ..\..\src\erandom.c ..\..\src\erf.c ..\..\src\erfc.c ..\..\src\exceptions.c ..\..\src\exp.c ..\..\src\exp10.c ..\..\src\exp2.c ..\..\src\exp3.c ..\..\src\exp_2.c ..\..\src\expm1.c ..\..\src\extract.c ..\..\src\factorial.c ..\..\src\fits_intmax.c ..\..\src\fits_sint.c ..\..\src\fits_slong.c ..\..\src\fits_sshort.c ..\..\src\fits_uint.c ..\..\src\fits_uintmax.c ..\..\src\fits_ulong.c ..\..\src\fits_ushort.c ..\..\src\fma.c ..\..\src\fmma.c ..\..\src\fms.c ..\..\src\fpif.c ..\..\src\frac.c ..\..\src\free_cache.c ..\..\src\frexp.c ..\..\src\gamma.c ..\..\src\gammaonethird.c ..\..\src\gamma_inc.c ..\..\src\get_d.c ..\..\src\get_d64.c ..\..\src\get_exp.c ..\..\src\get_f.c ..\..\src\get_float128.c ..\..\src\get_flt.c ..\..\src\get_ld.c ..\..\src\get_si.c ..\..\src\get_sj.c ..\..\src\get_str.c ..\..\src\get_ui.c ..\..\src\get_uj.c ..\..\src\get_z.c ..\..\src\get_z_exp.c ..\..\src\gmp_op.c ..\..\src\grandom.c ..\..\src\hypot.c ..\..\src\init.c ..\..\src\init2.c ..\..\src\inits.c ..\..\src\inits2.c ..\..\src\inp_str.c ..\..\src\int_ceil_log2.c ..\..\src\isinf.c ..\..\src\isinteger.c ..\..\src\isnan.c ..\..\src\isnum.c ..\..\src\isqrt.c ..\..\src\isregular.c ..\..\src\iszero.c ..\..\src\jn.c ..\..\src\li2.c ..\..\src\lngamma.c ..\..\src\log.c ..\..\src\log10.c ..\..\src\log1p.c ..\..\src\log2.c ..\..\src\logging.c ..\..\src\log_ui.c ..\..\src\min_prec.c ..\..\src\minmax.c ..\..\src\modf.c "..\..\src\mpfr-gmp.c" "..\..\src\mpfr-mini-gmp.c" ..\..\src\mp_clz_tab.c ..\..\src\mpn_exp.c ..\..\src\mul.c ..\..\src\mul_2exp.c ..\..\src\mul_2si.c ..\..\src\mul_2ui.c ..\..\src\mul_d.c ..\..\src\mul_ui.c ..\..\src\mulders.c ..\..\src\neg.c ..\..\src\next.c ..\..\src\nrandom.c ..\..\src\odd_p.c ..\..\src\out_str.c ..\..\src\pow.c ..\..\src\pow_si.c ..\..\src\pow_ui.c ..\..\src\pow_z.c ..\..\src\powerof2.c ..\..\src\print_raw.c ..\..\src\print_rnd_mode.c ..\..\src\printf.c ..\..\src\random_deviate.c ..\..\src\rec_sqrt.c ..\..\src\reldiff.c ..\..\src\rem1.c ..\..\src\rint.c ..\..\src\rndna.c ..\..\src\root.c ..\..\src\round_near_x.c ..\..\src\round_p.c ..\..\src\round_prec.c ..\..\src\scale2.c ..\..\src\sec.c ..\..\src\sech.c ..\..\src\set.c ..\..\src\set_d.c ..\..\src\set_d64.c ..\..\src\set_dfl_prec.c ..\..\src\set_exp.c ..\..\src\set_f.c ..\..\src\set_float128.c ..\..\src\set_flt.c ..\..\src\set_inf.c ..\..\src\set_ld.c ..\..\src\set_nan.c ..\..\src\set_prc_raw.c ..\..\src\set_prec.c ..\..\src\set_q.c ..\..\src\set_rnd.c ..\..\src\set_si.c ..\..\src\set_si_2exp.c ..\..\src\set_sj.c ..\..\src\set_str.c ..\..\src\set_str_raw.c ..\..\src\set_ui.c ..\..\src\set_ui_2exp.c ..\..\src\set_uj.c ..\..\src\set_z.c ..\..\src\set_zero.c ..\..\src\setmax.c ..\..\src\setmin.c ..\..\src\setsign.c ..\..\src\set_z_exp.c ..\..\src\sgn.c ..\..\src\si_op.c ..\..\src\signbit.c ..\..\src\sin.c ..\..\src\sin_cos.c ..\..\src\sinh.c ..\..\src\sinh_cosh.c ..\..\src\sqr.c ..\..\src\sqrt.c ..\..\src\sqrt_ui.c ..\..\src\stack_interface.c ..\..\src\strtofr.c ..\..\src\sub.c ..\..\src\sub1.c ..\..\src\sub1sp.c ..\..\src\sub_d.c ..\..\src\sub_ui.c ..\..\src\subnormal.c ..\..\src\sum.c ..\..\src\swap.c ..\..\src\tan.c ..\..\src\tanh.c ..\..\src\ubf.c ..\..\src\uceil_exp2.c ..\..\src\uceil_log2.c ..\..\src\ufloor_log2.c ..\..\src\ui_div.c ..\..\src\ui_pow.c ..\..\src\ui_pow_ui.c ..\..\src\ui_sub.c ..\..\src\urandom.c ..\..\src\urandomb.c ..\..\src\vasprintf.c ..\..\src\version.c ..\..\src\volatile.c ..\..\src\yn.c ..\..\src\zeta.c ..\..\src\zeta_ui.c ..\get_patches.c

which reproduce error.

 

Alexander

 

0 Kudos
Judith_W_Intel
Employee
2,869 Views

 

Hi,

I was able to follow your instructions but I am not seeing the problem with the latest development 17.0 compiler in my environment.

I don't have access to the sources from 17.0 update 2 so perhaps it's been fixed since that release?

The next 17.0 update should be available soon so perhaps you could try that.

Are you able to reproduce it by just compiling sqrt.c by itself, i.e. (I had to change all the backslashes to forward slashes since I'm using a Unix-like shell):

!% cat doit
icl /c /Qm64 /I../ /I../../  /I../../../mpir/dll/x64/Release/ /Zi /nologo /W3 /O3 /Oi /GT /D __INTEL_COMPILER=1700 /D WIN32 /D _WIN32 /D HAVE_CONFIG_H /D NDEBUG /D _LIB /D __MPFR_WITHIN_MPFR /D _GMP_IEEE_FLOATS /D _CRT_SECURE_NO_WARNINGS /D
 HAVE_STDINT_H /D __GMP_LIBGMP_DLL /D MPFR_USE_THREAD_SAFE /D MPFR_HAVE_GMP_IMPL
 /EHsc /MD /GS- /fp:strict /Zc:wchar_t /Zc:forScope /Fo"x64/Release//" /Fd"x64/Release/vc140.pdb" /TC ../../src/sqrt.c

!% which cl

//hrcna01a.nh.intel.com/wref1/ref/vs2015u3/VC/BIN/amd64/cl.EXE
!% which icl
D:/workspaces/17_0cfe/dev/build_objs/efi2win_debug/bin/icl.EXE
!% ./doit
sqrt.c
!%

Judy

0 Kudos
sav
Novice
2,869 Views

del

0 Kudos
sav
Novice
2,869 Views

Reduced your build command even more (although didn't test to remove preprocessor definitions):

icl /c /nologo /W3 /O3 /I../ /I../../  /I../../../mpir/dll/x64/Release/ /D __INTEL_COMPILER=1700 /D WIN32 /D _WIN32 /D HAVE_CONFIG_H /D NDEBUG /D_LIB /D __MPFR_WITHIN_MPFR /D _GMP_IEEE_FLOATS /D _CRT_SECURE_NO_WARNINGS /D HAVE_STDINT_H /D __GMP_LIBGMP_DLL /D MPFR_USE_THREAD_SAFE /D MPFR_HAVE_GMP_IMPL /Fo"x64/Release//" /TC ../../src/sqrt.c

and it still reproduce error. As before, error not reproduced, if '/O2' key used or Pavel's Holoborodko workaround applied:

mpfr_ICC_O2O3_builds.jpg

As for "The next 17.0 update", I doubt, that after such long history of this issue, it would disappear eventually with next IPSXE release. IMO, it exists in your ICC version too, but not reproduced for some reason (because your ICC Developer's / Debug version differs from Release, since it run in none-Windows environment, etc.). And it would appear in IPSXE 2017 Update 3 *Release* build too. I wish to be wrong.

 

Alexander

 

0 Kudos
Judith_W_Intel
Employee
2,869 Views

 

Well the next update is coming soon so please check and if it still exists we'll try to figure out why I'm not seeing it. Usually the debug version of the compiler tends to show problems that the release does not (due to enabling assertions, etc.). 

It could be a "flaky" fail (i.e. the memory layout has to be just right to see it). That would be hard to debug on Windows, on Linux we use valgrind to detect these problems.

thanks

0 Kudos
sav
Novice
2,869 Views

Tested MPFR build using IPSXE 2017 Update 4 and error not reproduced for builds with '-O1' - '-O3' compiler keys. I assume this issue could be closed. Thank you for a fix!

Alexander

 

0 Kudos
Judith_W_Intel
Employee
2,869 Views

 

great, thanks for the follow-up!

 

0 Kudos
Reply