L__FUNCTION__ doesn't appear in Mesa. It's in Microsoft's headers.

Not sure what we can do about that.

Yes, but for some reason it does not reproduced for MSVC Debug builds, which use the same toolchain and headers.
Whether it's possible to figure out, that this is an ICC bug? Then it would be possible to report it on ICC support forum.

> Yes, but for some reason it does not reproduced for MSVC Debug builds, which
> use the same toolchain and headers.
> Whether it's possible to figure out, that this is an ICC bug? Then it would be
> possible to report it on ICC support forum.

I think you can reproduce it by looking what function is implemented at
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\exception:126",
then compiling with ICC a debug build of a simple app just calling that exact
function. If it won't work that simply, try adding options from your output,
particularly  ones starting with D_.

That said, I doubt it's an ICC bug. My understanding is that ICC should use its
own headers, not the ones of MSVC. I'd rather suppose you have misconfigured
toolchain.

Probably I should have explained earlier. ICC tries to be GCC on *unix and MSVC on Windows. E.g. on Windows it has almost the same compiler keys, use MSVC Linker and Librarian, Windows SDK headers, etc. Thus it's an expected behavior, that ICC uses headers from 'Microsoft Visual Studio 14.0\VC\INCLUDE\' folder.


After some investigations found, that this error reproduced if debug run-time library is used for MESA build. It's hard to call it a MESA issue, thus I reported this error on ICC forums (https://software.intel.com/en-us/forums/intel-c-compiler/topic/731357 ).

And since it doesn't relate to MESA I assume this issue could be closed.


P.S. In case you're interested, Windows C++ compilers throw lot of different warnings during MESA build:

(ICC) ir.h(2254): warning #873: function "exec_node::operator new" has no corresponding operator delete (to be called if an exception is thrown during initialization of an allocated object)
        return new(mem_ctx) ir_emit_vertex(this->stream->clone(mem_ctx, ht));
               ^
(MSVC) ir.h(2254): warning C4291: 'void *exec_node::operator new(std::size_t,void *)': no matching operator delete found; memory will not be freed if initialization throws an exception

(ICC) build\windows-x86_64\gallium\auxiliary\indices\u_indices_gen.c(71): warning #592: variable "j" is used before its value is set
    (void)j;
          ^
(ICC) src\mesa\main\shaderobj.h(181): warning #1011: missing return statement at end of non-void function "_mesa_shader_stage_from_subroutine_uniform"


which could be a flaws in MESA sources and

(ICC) icl: command line warning #10381: option '/Qstd=c11' is not valid for C++ compilations

(GCC) cc1plus.exe: warning: command line option '-std=gnu11' is valid for C/ObjC but not for C++


etc., which could be a flaws in MESA build system (since 'CFLAGS' options are applied to C++ compiler).


Are they well known or worth to be reported as a separate issue?

(In reply to sav_ix from comment #4)
> (ICC) ir.h(2254): warning #873: function "exec_node::operator new" has no
> corresponding operator delete (to be called if an exception is thrown during
> initialization of an allocated object)
>         return new(mem_ctx) ir_emit_vertex(this->stream->clone(mem_ctx, ht));
>                ^
> (MSVC) ir.h(2254): warning C4291: 'void *exec_node::operator
> new(std::size_t,void *)': no matching operator delete found; memory will not
> be freed if initialization throws an exception

The warnings are for the same line, and might be worth some attention if anyone
interested (I looked very cursory at it tho).
 
> (ICC) build\windows-x86_64\gallium\auxiliary\indices\u_indices_gen.c(71):
> warning #592: variable "j" is used before its value is set
>     (void)j;
>           ^

This is a funny one. I googled up that such a cast is used to make a compiler
to not show a warning about a unused variable, and it's funny that for ICC it
turned up into another one.

That said, I've no idea who need those unused variables in the file, they
probably worth deleting. It's a trivial cleanup, if nobody wants to do
something to them, I'll send a patch at the weekend.

> (ICC) src\mesa\main\shaderobj.h(181): warning #1011: missing return >
statement at end of non-void function >
"_mesa_shader_stage_from_subroutine_uniform"

This one is false-positive, the function uses a macro "unreachable()" there,
which is defined through built-ins either α) if a compiler has
__builtin_unreachable, or β) through __assume() if a compiler is MSVC, or γ)
just an assert() otherwise. __builtin_unreachable is tested first, and acc. to
google ICC has the function, so it's an ICC flaw (I understand though that as
you said it imitates MSVC on Windows, but I don't see anyway why would they
need to disable the function).
 
> which could be a flaws in MESA sources and
> 
> (ICC) icl: command line warning #10381: option '/Qstd=c11' is not valid for
> C++ compilations
> 
> (GCC) cc1plus.exe: warning: command line option '-std=gnu11' is valid for
> C/ObjC but not for C++

Unless there're compilation errors, these are harmless, but if anyone wanted to
send a fix, could be a nice cleanup.

Created attachment 130879 [details]
ICC and MSVC build warnings

I see. Then I added ICC and MSVC logs with all thrown warnings (see attachment). Just in case it would help to improve MESA code.

ICC Developers figured out, that source of this issue is code:
/* XXX: Use standard `__func__` instead */
#ifndef __FUNCTION__
#  define __FUNCTION__ __func__
#endif

in file 'src/gallium/include/pipe/p_compiler.h'.

If commented, MESA Debug build using ICC finishes successfully. Expected to be fixed in future ICC releases (https://software.intel.com/en-us/forums/intel-c-compiler/topic/731357#comment-1903194).

(In reply to Hi-Angel from comment #5)
> This is a funny one. I googled up that such a cast is used to make a compiler
> to not show a warning about a unused variable, and it's funny that for ICC it
> turned up into another one.
> 
> That said, I've no idea who need those unused variables in the file, they
> probably worth deleting. It's a trivial cleanup, if nobody wants to do
> something to them, I'll send a patch at the weekend.

Well, turns out it indeed was there for a reason. It's because the whole
u_indices_gen.c is autogenerated.