- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, everyone,
For MESA build using ICC on Windows got error:
CC="icl" CXX="icl" LD="xilink" scons.py -j1 build=debug verbose=yes machine=x86_64 platform=windows MSVC_VERSION=14.0 libgl-gdi [snip] icl /Fobuild\windows-x86_64-debug\compiler\glsl_types.obj /c src\compiler\glsl_types.cpp /TP /nologo /Od /Oi /Oy- /W3 /wd4018 /wd4056 /wd4244 /wd4267 /wd4305 /wd4351 /wd4756 /wd4800 /wd4996 /MTd -FIinttypes.h /LDd /D__STDC_CONSTANT_MACROS /D__STDC_FORMAT_MACROS /D__STDC_LIMIT_MACROS /DHAVE_NO_AUTOCONF /DDEBUG /DWIN32 /D_WINDOWS /D_WIN32_WINNT=0x0601 /DWINVER=0x0601 /DVC_EXTRALEAN /D_USE_MATH_DEFINES /D_CRT_SECURE_NO_WARNINGS /D_CRT_SECURE_NO_DEPRECATE /D_SCL_SECURE_NO_WARNINGS /D_SCL_SECURE_NO_DEPRECATE /D_ALLOW_KEYWORD_MACROS /D_HAS_EXCEPTIONS=0 /D_DEBUG /DPIPE_SUBSYSTEM_WINDOWS_USER /DPACKAGE_VERSION=\"17.1.0-devel\" /DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\" /Ibuild\windows-x86_64-debug\compiler /Isrc\compiler /Ibuild\windows-x86_64-debug\compiler\nir /Isrc\compiler\nir /Ibuild\windows-x86_64-debug\compiler /Isrc\compiler /Ibuild\windows-x86_64-debug\compiler\glsl /Isrc\compiler\glsl /Iinclude /Isrc /Isrc\mapi /Isrc\mesa /Isrc\gallium\include /Isrc\gallium\auxiliary /Iinclude /Isrc\gallium\include /Isrc\gallium\auxiliary /Isrc\gallium\drivers /Isrc\gallium\winsys /Zi icl: command line warning #10148: option '/Oy-' not supported glsl_types.cpp C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\exception(126): error: identifier "L__FUNCTION__" is undefined _RAISE(*this); // raise this exception ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\exception(155): error: identifier "L__FUNCTION__" is undefined _RAISE(*this); ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\exception(183): error: identifier "L__FUNCTION__" is undefined _RAISE(*this); ^ src\compiler\glsl_types.cpp(755): warning #1011: missing return statement at end of non-void function "glsl_type::get_sampler_instance" } ^ src\compiler\glsl_types.cpp(854): warning #1011: missing return statement at end of non-void function "glsl_type::get_image_instance" } ^ compilation aborted for src\compiler\glsl_types.cpp (code 2) scons: *** [build\windows-x86_64-debug\compiler\glsl_types.obj] Error 2 scons: building terminated because of errors.
which relate to code
#include <new>
in file
src/compiler/glsl/glsl_symbol_table.h
If this code removed, build continue until next error:
CC="icl" CXX="icl" LD="xilink" scons.py -j1 build=debug verbose=yes machine=x86_64 platform=windows MSVC_VERSION=14.0 libgl-gdi [snip] icl /Fobuild\windows-x86_64-debug\mesa\state_tracker\st_glsl_to_tgsi.obj /c src\mesa\state_tracker\st_glsl_to_tgsi.cpp /TP /nologo /Od /Oi /Oy- /W3 /wd4018 /wd4056 /wd4244 /wd4267 /wd4305 /wd4351 /wd4756 /wd4800 /wd4996 /MTd -FIinttypes.h /LDd /D__STDC_CONSTANT_MACROS /D__STDC_FORMAT_MACROS /D__STDC_LIMIT_MACROS /DHAVE_NO_AUTOCONF /DDEBUG /DWIN32 /D_WINDOWS /D_WIN32_WINNT=0x0601 /DWINVER=0x0601 /DVC_EXTRALEAN /D_USE_MATH_DEFINES /D_CRT_SECURE_NO_WARNINGS /D_CRT_SECURE_NO_DEPRECATE /D_SCL_SECURE_NO_WARNINGS /D_SCL_SECURE_NO_DEPRECATE /D_ALLOW_KEYWORD_MACROS /D_HAS_EXCEPTIONS=0 /D_DEBUG /DPIPE_SUBSYSTEM_WINDOWS_USER /DPACKAGE_VERSION=\"17.1.0-devel\" /DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\" /D_GDI32_ /DBUILD_GL32 /D_GLAPI_NO_EXPORTS /Iinclude /Isrc\gallium\include /Isrc\gallium\auxiliary /Isrc\gallium\drivers /Isrc\gallium\winsys /Ibuild\windows-x86_64-debug /Isrc /Ibuild\windows-x86_64-debug\compiler\nir /Isrc\compiler\nir /Ibuild\windows-x86_64-debug\compiler\glsl /Isrc\compiler\glsl /Isrc /Ibuild\windows-x86_64-debug\mapi /Isrc\mapi /Ibuild\windows-x86_64-debug\mesa /Isrc\mesa /Ibuild\windows-x86_64-debug\mesa\main /Isrc\mesa\main /Isrc\gallium\include /Isrc\gallium\auxiliary /Zi icl: command line warning #10148: option '/Oy-' not supported st_glsl_to_tgsi.cpp ../build/src/mesa/main/shaderobj.h(138): warning #1011: missing return statement at end of non-void function "_mesa_shader_enum_to_shader_stage" } ^ ../build/src/mesa/main/shaderobj.h(181): warning #1011: missing return statement at end of non-void function "_mesa_shader_stage_from_subroutine_uniform" } ^ ../build/src/mesa/main/shaderobj.h(201): warning #1011: missing return statement at end of non-void function "_mesa_shader_stage_from_subroutine" } ^ ../build/src/mesa/main/shaderobj.h(221): warning #1011: missing return statement at end of non-void function "_mesa_shader_stage_to_subroutine" } ^ ../build/src/mesa/main/shaderobj.h(241): warning #1011: missing return statement at end of non-void function "_mesa_shader_stage_to_subroutine_uniform" } ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\exception(126): error: identifier "L__FUNCTION__" is undefined _RAISE(*this); // raise this exception ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\exception(155): error: identifier "L__FUNCTION__" is undefined _RAISE(*this); ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\exception(183): error: identifier "L__FUNCTION__" is undefined _RAISE(*this); ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(70): error: identifier "L__FUNCTION__" is undefined _SCL_SECURE_ALWAYS_VALIDATE(_Ptr_container != 0); ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(84): error: identifier "L__FUNCTION__" is undefined _SCL_SECURE_ALWAYS_VALIDATE(_Ptr != 0); ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(94): error: identifier "L__FUNCTION__" is undefined _SCL_SECURE_ALWAYS_VALIDATE(_Count <= (size_t)(-1) / _Sz); ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(99): error: identifier "L__FUNCTION__" is undefined _SCL_SECURE_ALWAYS_VALIDATE( ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(108): error: identifier "L__FUNCTION__" is undefined _SCL_SECURE_ALWAYS_VALIDATE( ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(114): error: identifier "L__FUNCTION__" is undefined _SCL_SECURE_ALWAYS_VALIDATE(_Ptr_container < _Ptr_user); ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(117): error: identifier "L__FUNCTION__" is undefined _SCL_SECURE_ALWAYS_VALIDATE(2 * sizeof(void *) ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xmemory0(125): error: identifier "L__FUNCTION__" is undefined _SCL_SECURE_ALWAYS_VALIDATE(_Ptr_user - _Ptr_container ^ compilation aborted for src\mesa\state_tracker\st_glsl_to_tgsi.cpp (code 2) scons: *** [build\windows-x86_64-debug\mesa\state_tracker\st_glsl_to_tgsi.obj] Error 2 scons: building terminated because of errors.
which relate to code
#include <algorithm>
in file
src/mesa/state_tracker/st_glsl_to_tgsi.cpp
If this code removed, build finishes with error:
CC="icl" CXX="icl" LD="xilink" scons.py -j1 build=debug verbose=yes machine=x86_64 platform=windows MSVC_VERSION=14.0 libgl-gdi [snip] icl /Fobuild\windows-x86_64-debug\mesa\state_tracker\st_glsl_to_tgsi.obj /c src\mesa\state_tracker\st_glsl_to_tgsi.cpp /TP /nologo /Od /Oi /Oy- /W3 /wd4018 /wd4056 /wd4244 /wd4267 /wd4305 /wd4351 /wd4756 /wd4800 /wd4996 /MTd -FIinttypes.h /LDd /D__STDC_CONSTANT_MACROS /D__STDC_FORMAT_MACROS /D__STDC_LIMIT_MACROS /DHAVE_NO_AUTOCONF /DDEBUG /DWIN32 /D_WINDOWS /D_WIN32_WINNT=0x0601 /DWINVER=0x0601 /DVC_EXTRALEAN /D_USE_MATH_DEFINES /D_CRT_SECURE_NO_WARNINGS /D_CRT_SECURE_NO_DEPRECATE /D_SCL_SECURE_NO_WARNINGS /D_SCL_SECURE_NO_DEPRECATE /D_ALLOW_KEYWORD_MACROS /D_HAS_EXCEPTIONS=0 /D_DEBUG /DPIPE_SUBSYSTEM_WINDOWS_USER /DPACKAGE_VERSION=\"17.1.0-devel\" /DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\" /D_GDI32_ /DBUILD_GL32 /D_GLAPI_NO_EXPORTS /Iinclude /Isrc\gallium\include /Isrc\gallium\auxiliary /Isrc\gallium\drivers /Isrc\gallium\winsys /Ibuild\windows-x86_64-debug /Isrc /Ibuild\windows-x86_64-debug\compiler\nir /Isrc\compiler\nir /Ibuild\windows-x86_64-debug\compiler\glsl /Isrc\compiler\glsl /Isrc /Ibuild\windows-x86_64-debug\mapi /Isrc\mapi /Ibuild\windows-x86_64-debug\mesa /Isrc\mesa /Ibuild\windows-x86_64-debug\mesa\main /Isrc\mesa\main /Isrc\gallium\include /Isrc\gallium\auxiliary /Zi icl: command line warning #10148: option '/Oy-' not supported st_glsl_to_tgsi.cpp [snip] src\mesa\state_tracker\st_glsl_to_tgsi.cpp(6138): error: namespace "std" has no member "sort" std::sort(decls, decls + count, sorter); ^ compilation aborted for src\mesa\state_tracker\st_glsl_to_tgsi.cpp (code 2) scons: *** [build\windows-x86_64-debug\mesa\state_tracker\st_glsl_to_tgsi.obj] Error 2 scons: building terminated because of errors.
which, in general, isn't strange.
Environment:
- Windows 10 x64,
- IPSXE 2017 Update 2,
- VS 2015 Update 3,
- Python 2.7.13 + SCons 2.5.1,
- MSYS2 20161025,
- MESA 17.1.0-dev (git://anongit.freedesktop.org/git/mesa/mesa ).
Reproduced for ICC Debug builds only. Not reproduced for ICC Release and MSVC <Debug|Release> builds.
The workaround for this issue is to replace definitions 'DEBUG' and '_DEBUG' with 'NDEBUG' and '_NDEBUG', and compiler key '/MTd' with '/MT' or '/MD' (patch added in attachment).
MESA Developers thinks that this issue doesn't relate to MESA. In this case it turns out that it's somewhere between ICC and MSVC. Is it possible to register this error on internal bugtracker in order to fix it in future ICC builds?
P.S. In order to reproduce error, need to remove an incompatible compiler key '/GL' from SCons MSVC toolchain (patch added in attachment).
Alexander
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've entered this Microsoft incompatibility in our internal bugs database as CMPLRS-42513. The format of the number looks different from the number I usually give because we've just switched from Clearquest to Jira for bug tracking...
Judy
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmmm ... My guess is that the Mesa application is overriding the Microsoft definition of the _RAISE macro with their own and it doesn't work on Windows. Can you confirm or deny my suspicion? Search for "#define __RAISE" in the headers.
On Windows you can add __LPREFIX(__FUNCTION__) but __L__FUNCTION__ does not work with either icl or cl.
Judy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not sure what code you removed but you need to #include <algorithm> in order to get the definition of std::sort.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I removed
#include <new> #include <algorithm>
from MESA sources for testing purposes only (to make sure that it's responsible for '"L__FUNCTION__"
is undefined
' errors). Surely they required for MESA build and run.
Just made search on MESA sources, and it doesn't contain '__RAISE' definition in any file. If it's added somewhere, then, in my case, only by ICC aor MSVC itself.
In case you're interested to reproduce this error, I can provide a simple instruction.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the MSVC++ 2015 sources the _RAISE macro is defined in <xstddef> (depending on whether _HAS_EXCEPTIONS and _DEBUG is defined as one of these:
#define _RAISE(x) throw x
#if defined(_DEBUG)
#define _RAISE(x) \
_invoke_watson(_CRT_WIDE(#x), __FUNCTIONW__, __FILEW__, __LINE__, 0)
#else /* defined(_DEBUG) */
#define _RAISE(x) \
_invoke_watson(0, 0, 0, 0, 0)
#endif /* defined(_DEBUG) */
So let's assume it's invoking the second definition then the macro. It then expands __FUNCTIONW__ which is defined in yvals.h to be:
#define __STR2WSTR(str) L##str
#define _STR2WSTR(str) __STR2WSTR(str)
#define __FUNCTIONW__ _STR2WSTR(__FUNCTION__)
!% cat f.cpp
#include <xstddef>
_RAISE(FOO)
!% tail f.E
#line 4 "f.cpp"
_invoke_watson(L"FOO", __LPREFIX(__FUNCTION__), L"f.cpp", 5, 0)
!%
So it becomes __LPREFIX not L.
Do the mesa sources redefine the __FUNCTIONW or the _STR2WSTR or __STR2WSTR macros?
What do you see when you preprocess the following?
!% cat p.cpp
#define __STR2WSTR(str) L##str
#define _STR2WSTR(str) __STR2WSTR(str)
#define __FUNCTIONW__ _STR2WSTR(__FUNCTION__)
#define _RAISE(x) \
_invoke_watson(_CRT_WIDE(#x), __FUNCTIONW__, __FILEW__, __LINE__, 0)
_RAISE(FOO)
I see:
_invoke_watson(_CRT_WIDE("FOO"), __LPREFIX(__FUNCTION__), __FILEW__, 10, 0)
In other words __LPREFIX(__FUNCTION__) not L__FUNCTION__.
I tried to download the mesa sources but I don't have permission to do a git clone. I don't think my ftp proxies are set up correctly.
Judy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just checked MESA sources. It doesn't contain any of '__FUNCTIONW', '_STR2WSTR' or '__STR2WSTR' macroses. Thus it couldn't redefine them.
Pasted your code to test file, built it using ICC and got:
sh-4.4$ icl f.cpp Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0 Build 20170105 Copyright (C) 1985-2017 Intel Corporation. All rights reserved. f.cpp f.cpp(5): warning #47: incompatible redefinition of macro "__FUNCTIONW__" (declared at line 148 of "C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\ucrt\corecrt.h") #define __FUNCTIONW__ _STR2WSTR(__FUNCTION__) ^ f.cpp(7): warning #47: incompatible redefinition of macro "_RAISE" (declared at line 36 of "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xstddef") #define _RAISE(x) \ ^ f.cpp(10): error #77: this declaration has no storage class or type specifier _RAISE(FOO); ^ f.cpp(10): error: declaration is incompatible with "void __cdecl _invoke_watson(const __wchar_t *, const __wchar_t *, const __wchar_t *, unsigned int, uintptr_t={unsigned __int64})" (declared at line 251 of "C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\ucrt\corecrt.h") _RAISE(FOO); ^ f.cpp(10): error: a value of type "const __wchar_t *" cannot be used to initialize an entity of type "int" _RAISE(FOO); ^ f.cpp(10): error: expected a ")" _RAISE(FOO); ^ compilation aborted for f.cpp (code 2) sh-4.4$
I assume this is hardly what you expected. Could you attach your example file, so we'll be sure that using the same code.
MESA is a free, Open Source library (significantly contributed by Intel, BTW), so getting its sources shouldn't be a problem. I had no troubles with its download using command:
git clone git://anongit.freedesktop.org/git/mesa/mesa
But if your network has restrictions, you can get recent release from MESA archive via https. I just tested build mesa-17.0.4.tar.gz and it reproduces this issue as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for the pointer to the tar file. That helped me reproduce the problem.
If you compile the code below with:
icl /c bug.cpp /D_HAS_EXCEPTIONS=0 /D_DEBUG
You'll see the problem.
Interestingly Microsoft compiles the code just fine.
So I'm guessing the Microsoft compiler doesn't let you
override the predefined meaning of the __FUNCTION__ macro.
// bug.cpp
// from src/gallium/include/pipe/p_compiler.h
# define __FUNCTION__ __func__
// from include/c99_compat.h:
#define __func__ __FUNCTION__
#include <exception>
So as a workaround you can comment out this code in
src/gallium/include/pipe/p_compiler.h:
/* XXX: Use standard `__func__` instead */
#ifndef __FUNCTION__
# define __FUNCTION__ __func__
#endif
In the meantime we'll fix our compiler to behave like Microsoft. We'll ignore any user requests to define the __FUNCTION__ macro...
thanks for reporting this.
Judy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've entered this Microsoft incompatibility in our internal bugs database as CMPLRS-42513. The format of the number looks different from the number I usually give because we've just switched from Clearquest to Jira for bug tracking...
Judy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
And thank you for a quick and patient response. As for registering the issue on new Intel bugtracker.
I just tested your workaround and it works fine. Left a link at MESA bugtracker to this topic so everyone, who experience this issue, could bypass it until it would be fixed in ICC.
In case you're interested, there are few more ICC errors, which move from version to version for about last 5-7 years. Both are somewhat similar, as relate to compiler optimization levels ('/Od' - '/O3'):
- error LNK2001: unresolved external symbol "...::`vftable'",
- Intel C++ Compiler internal error: 04010002_15114.
I just reproduced them using IPSXE 2017 Update 2 and assume they would appear in IPSXE 2018 too. Would be nice to escalate them and register on Intel Jira.
Alexander
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK - if you can get us a reproducer then we can address the problems.
That same internal error was reported here:
https://software.intel.com/en-us/forums/intel-c-compiler/topic/605854
But that one has been fixed since Feb 2016.
Feel free to go through the official channels (Intel Premier Support) and they will get the bugs to the right developers.
thanks
Judy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please consider, that my previous post contain not "error names", but links to topics on ICC forum with steps to reproduce this errors. Today I've slightly updated them, to make even more clear.
BTW, ICC internal error (https://software.intel.com/en-us/forums/intel-c-compiler/topic/605854 ) is still reproduced for '/O3' Optimization level (tested today using IPSXE 2017 Update 2).
Let me know, if any additional information needed.
Alexander
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see. The vftable one has been assigned back to the submitter because us developers don't have access to Microsoft Visual Studio on our local desktops and the developer requested a way to reproduce it via command line options (i.e. a bat file or shell script or Makefile instead of a solution file). Is there a way that you can provide this? I thought there was a way to use Visual Studio to create a .bat file from inside Visual Studio.
The internal error was closed as a duplicate of a different bug that was fixed in Feb 2016 but perhaps that fix didn't really fix it...
I will track these down and get things moving again .. sorry for the delay...
Judy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can't reproduce the internal error even when I changed /O1 to /O3, i.e. I tried the following.
Are you able to reproduce it with the following command line? Should I be using the exceptions.c from the original zip file or are you using a newer version?
Judy
!% cat doit
icl /O3 /c exceptions.c /MP /GS- /W3 /Zc:wchar_t /I"mpfr-master/build.vc14" /I
"mpir/build.vc14/dll_mpir_gc/x64/Release" /I"mpfr-master/src" /I"../" /I"../..
/" /I"mpir/dll/x64/Release/" /Zi /Fd"x64/Release/vc140.pdb" /fp:strict /D "WIN32
" /D"_WIN32" /D "HAVE_CONFIG_H" /D"NDEBUG" /D"_LIB" /D"__MPFR_WITHIN_MPFR" /D"_G
MP_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/"
!%
!% which icl
D:/workspaces/17_0cfe/dev/build_objs/efi2win_debug/bin/icl.EXE
!% ./doit
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0 Beta Build x
Built Apr 5 2017 13:14:29 by jward4 on JWARD4-DESK1 in D:/workspaces/17_0cfe/dev
Copyright (C) 1985-2017 Intel Corporation. All rights reserved.
exceptions.c
!%
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
While running this command from MPFR build directory using 'Compiler 17.0 Update 2 for Intel 64 Visual Studio 2015 environment' command prompt, got different errors, that files/directories not found. Not sure I'll manage to make it.
MPFR could be built using ICC from command shell. But in much other way (see https://sympa.inria.fr/sympa/arc/mpfr/2016-02/msg00000.html), which, due to its complexity, not an option in our case. Any chance, that you'll find for MPFR build a workstation with Visual Studio 2015(13) + IPSXE 2017 installed?
Currently an error occur during 'sqrt.c' build (added updated build logs). To reproduce error used untouched, unchanged MPIR&MPFR sources from github, which downloaded just now.
P.S. How about to move our 'error: 04010002_15114' discussion to the appropriate topic?
Alexander
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
MESA build error using ICC on Windows not reproduced after moving to IPSXE 2018.
Thank you for fix.
Best,
Alexander

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page