Community
cancel
Showing results for 
Search instead for 
Did you mean: 
sav
Novice
617 Views

'identifier "L__FUNCTION__" is undefined' error for ICC build on Windows

Jump to solution

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

 

0 Kudos
1 Solution
Judith_W_Intel
Employee
617 Views

 

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 

View solution in original post

14 Replies
Judith_W_Intel
Employee
617 Views

 

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

Judith_W_Intel
Employee
617 Views

 

Not sure what code you removed but you need to #include <algorithm> in order to get the definition of std::sort.

 

sav
Novice
617 Views

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.

 

Judith_W_Intel
Employee
617 Views

 

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

 

sav
Novice
617 Views

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.

 

Judith_W_Intel
Employee
617 Views

 

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

Judith_W_Intel
Employee
618 Views

 

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 

View solution in original post

sav
Novice
617 Views


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

 

Judith_W_Intel
Employee
617 Views

 

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

sav
Novice
617 Views

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

 

Judith_W_Intel
Employee
617 Views

 

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

Judith_W_Intel
Employee
617 Views

 

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
!%

sav
Novice
617 Views

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

 

sav
Novice
617 Views

MESA build error using ICC on Windows not reproduced after moving to IPSXE 2018.

Thank you for fix.

Best,

Alexander

 

Reply