Hello,

I would like to report an error during the compilation of a code that uses the beast component of Boost (v1.71.0).

Basically, I obtain the following error when I call the function boost::beast::http::read :

H:/3rdParty_lib/Boost/boost_1_71_0/boost/beast/http/message.hpp(265): error: static assertion failed with "Fields type requirements not met"
      static_assert(is_fields<Fields>::value,
      ^
          detected during:
            instantiation of class "boost::beast::http::header<0, Fields> [with Fields=boost::beast::http::fields]" at line 495
            instantiation of class "boost::beast::http::message<isRequest, Body, Fields> [with isRequest=0, Body=boost::beast::http::string_body, Fields=boost::beast::http::fields]" at line 22 of "H:/TestIntelBoost/main.cpp"
H:/3rdParty_lib/Boost/boost_1_71_0/boost/beast/http/message.hpp(61): error: static assertion failed with "Fields type requirements not met"
      static_assert(is_fields<Fields>::value,
      ^
          detected during:
            instantiation of class "boost::beast::http::header<1, Fields> [with Fields=boost::beast::http::detail::fields_model]" at line 487 of "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits"
            instantiation of class "std::is_constructible<_Ty, _Args...> [with _Ty=boost::beast::http::basic_string_body<char, std::char_traits<char>, std::allocator<char>>::reader, _Args=<boost::beast::http::header<1, boost::beast::http::detail::fields_model> &, std::basic_string<char, std::char_traits<char>, std::allocator<char>> &>]" at line 188 of "H:/3rdParty_lib/Boost/boost_1_71_0/boost/beast/http/type_traits.hpp"
            instantiation of class "boost::beast::http::is_body_reader<T, boost::beast::detail::void_t<decltype((<expression>))>> [with T=boost::beast::http::string_body]" at line 489 of "H:/3rdParty_lib/Boost/boost_1_71_0/boost/beast/http/impl/read.hpp"
            instantiation of "size_t={unsigned __int64} boost::beast::http::read(SyncReadStream &, DynamicBuffer &, boost::beast::http::message<isRequest, Body, boost::beast::http::basic_fields<Allocator>> &) [with SyncReadStream=boost::beast::tcp_stream, DynamicBuffer=boost::beast::flat_buffer, isRequest=0, Body=boost::beast::http::string_body, Allocator=std::allocator<char>]" at line 22 of "H:/TestIntelBoost/main.cpp"
H:/3rdParty_lib/Boost/boost_1_71_0/boost/beast/http/message.hpp(265): error: static assertion failed with "Fields type requirements not met"
      static_assert(is_fields<Fields>::value,
      ^
          detected during:
            instantiation of class "boost::beast::http::header<0, Fields> [with Fields=boost::beast::http::detail::fields_model]" at line 487 of "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits"
            instantiation of class "std::is_constructible<_Ty, _Args...> [with _Ty=boost::beast::http::basic_string_body<char, std::char_traits<char>, std::allocator<char>>::reader, _Args=<boost::beast::http::header<0, boost::beast::http::detail::fields_model> &, std::basic_string<char, std::char_traits<char>, std::allocator<char>> &>]" at line 191 of "H:/3rdParty_lib/Boost/boost_1_71_0/boost/beast/http/type_traits.hpp"
            instantiation of class "boost::beast::http::is_body_reader<T, boost::beast::detail::void_t<decltype((<expression>))>> [with T=boost::beast::http::string_body]" at line 489 of "H:/3rdParty_lib/Boost/boost_1_71_0/boost/beast/http/impl/read.hpp"
            instantiation of "size_t={unsigned __int64} boost::beast::http::read(SyncReadStream &, DynamicBuffer &, boost::beast::http::message<isRequest, Body, boost::beast::http::basic_fields<Allocator>> &) [with SyncReadStream=boost::beast::tcp_stream, DynamicBuffer=boost::beast::flat_buffer, isRequest=0, Body=boost::beast::http::string_body, Allocator=std::allocator<char>]" at line 22 of "H:/TestIntelBoost/main.cpp"

Please, find in attach a minimal example reproducing the issue which does not happen with Microsoft compiler and note that the same issue is described at the following link without a solution:

https://github.com/boostorg/beast/issues/1259

Here is the version of icl I am using:

$ icl
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.0.4.245 Build 20190417
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

icl: command line error: no files specified; for help type "icl /help"

Can you please check?

Thanks and best regards.

Does the C++ standard library have these C++11 features?

My simple program:

#include <iostream>                     
                                        
std::error_code code;                   
                                        
int main() {                            
    std::cout << "Hello"<< std::endl;
}                                       

fails to compile with the following error:

error: namespace "std" has no member "error_code"

This is the compile command I'm using:

icpc -std=c++11 -o test test.cpp

I am compiling the most basic hello.c on Mac OS X Catalina 10.5.2, Xcode 11.3, ICC 19.0.4.233 20190416

#include <stdio.h>
int main()
{
printf("Hello!\n");
return(0);
}

gcc  hello.c
ls -l a.out
-rwxr-xr-x  1 dusan  staff  12556 Jan 13 17:27 a.out
otool -L a.out
a.out:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)

Gcc (or actually clang) gives reasonable binary size and does not link to anything extra.

But with icc, it is a different story:

icc hello.c
ls -l aout
-rwxr-xr-x  1 dusan  staff  38856 Jan 13 17:19 a.out
otool -L  a.out
a.out:
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)

Why does icc link to libc++, if I only use C language?

And why is the resulting binary so big?
Setting setting optimization options does not change the result

Binary contains tons of messages, many of which are not necessary, for example the one about Windows XP:

Fatal Error: This program was not built to run on the processor in your system.
Run-Time Check Failure: The variable '%s' is being used without being initialized
Windows XP 64-bit Edition Version 2003 or newer should be used.
Intel(R) Core(TM) Duo processors and compatible Intel processors with supplemental Streaming SIMD Extensions 3 (SSSE3) instruction support
Intel(R) Pentium(R) 4 and compatible Intel processors with Intel(R) Streaming SIMD Extensions 3 (Intel(R) SSE3) instruction support
Intel(R) Pentium(R) 4 and compatible Intel processors. Enables new optimizations in addition to Intel processor-specific optimizations
Intel(R) processors with SSE4.2 and POPCNT instructions support
Please verify that both the operating system and the processor support Intel(R) AVX.
Please verify that both the operating system and the processor support Intel(R) AVX, F16C and RDRAND instructions.
Please verify that both the operating system and the processor support Intel(R) AVX2, BMI, LZCNT, HLE, RTM and FMA instructions.
Please verify that both the operating system and the processor support Intel(R) %s instructions.
Please verify that your application was built with compatible Intel(R) libirc library
Use of incompatible or internally inconsistent Intel(R) libirc library
Run-Time Check Failure: The variable '%s' is being used in %s without being initialized
Cache size is incorrectly reported as 0. Please engage your hardware and/or OS support to address the problem.
irc_msg.cat
Constant propagation error (%s substitution):
FORMAL
RETURN
GLOBAL
I32 %lx != %lx
SI32 %ld != %ld
F32 %f != %f
I64 %lx:%lx != %lx:%lx
SI64 %ld:%ld != %ld:%ld
F64 %f != %f
Bad second argument
Fatal Error: Can not initiate the Heap
Usage: %s input_file output_file
Usage: %s segment_size input_file [-trace]
Conversion from text file %s to binary %s completed
segment_size = 0x%x = %d
Cannot allocate memory to hold segment (size = 0x%x)
Input file: %s corrupted
routine_name = '%s'
file_name    = '%s'
prof_dir     = '%s'
Dynamic profile created from file %s completed
The allowed processors are: %s.
Error:  Buffer overrun occurred, forced exit
Initialization of symbol handler failed. Error code %d
NTDLL module not found
RtlCaptureContext function not found in ntdll.dll
StackWalk is terminated abnormally. Error code %d
Exception is raised during stack walking
Signal %s is raised
Signal %s is raised at 0x%p
SIGSEGV
SIGILL
SIGBUS
SIGFPE
unknown
No error
You must link with libunwind to use traceback functionality
Intel(R) Pentium(R) M and compatible Intel processors
Intel(R) processors with Swing New Instructions support
Intel(R) processors with MOVBE instructions support
Fatal Error: This program was not built to run in your system.
Boundary Run-Time Check Failure for variable '%s'
Boundary Run-Time Check Failure
Conversion Run-Time Check Failure
 and
LANG
GENERIC_IA32
CMOV
FXSAVE
SSE2
SSE3
SSSE3
SSE4_1
SSE4_2
MOVBE
POPCNT
PCLMULQDQ
F16C
RDRND
LZCNT
AVX2
AVX512DQ
PTWRITE
KNCNI
AVX512F
RDSEED
AVX512IFMA52
AVX512ER
AVX512PF
AVX512CD
AVX512BW
AVX512VL
AVX512VBMI
AVX512_4FMAPS
AVX512_4VNNIW
AVX512_VPOPCNTDQ
AVX512_BITALG
AVX512_VBMI2
GFNI
VAES
VPCLMULQDQ
AVX512_VNNI
CLWB
RDPID
SHSTK
WBNOINVD
PCONFIG
hw.optional.avx512f
hw.optional.avx512cd
hw.optional.avx512dq
hw.optional.avx512bw
hw.optional.avx512vl
hw.optional.avx512ifma
hw.optional.avx512vbmi

Hi,

    When compiling the following program without the -g parameter, the run result is -1. After the -g parameter is added, the run result is reported as a Segment Fault. Perhaps intelc has some optimizations by default. Is this a correct behavior for intel c complier?

TestCase:

#include<stdio.h>

#include<string.h>

int has_8bit(int i)

{

    return strcmp(i, "none");

}

int main(void){

    int NISLParameter0 = -4569;

    int NISLParameter1 = has_8bit(NISLParameter0);

    printf("%d",NISLParameter1);

    return 0;

}

The OS is:

Linux version 4.15.0-65-generic

Compiler Version:

icc (ICC) 19.0.4.243 20190416

Hi there,

I am compiling the code below with ICC using the following command line: 

icc -w -par-threshold0 -no-vec -fno-inline -parallel -qopt-report-phase=all -qopt-report=5

 1 #include <stdio.h>
  2 int a[100];
  3
  4 int main(int argc, char *argv[])
  5 {
  6   int len=argc;
  7   int i,x=10;
  8
  9   for (i=0;i<len;i++)
 10   {
 11     a[x] = i;
 12     x=i;
 13   }
 14
 15   for (i = 0; i < len; i++)
 16     printf("%d ", a[i]);
 17   printf("x=%d",x);
 18   return 0;
 19 }

The code is a modification of the following program in AutoParBench:

https://github.com/LLNL/dataracebench/blob/master/micro-benchmarks/DRB016-outputdep-orig-yes.c

The loop pattern in the code has two pair of dependencies:  

1. loop carried output dependence

 x = .. : 

2. loop carried true dependence due to: 

.. = x; // a[x]

 x = ..; 

Below I am showing you the report produced by ICC. It seems that ICC tried to parallelize the loop at lines 9-13. 

Intel(R) Advisor can now assist with vectorization and show optimization
  report messages with your source code.
See "https://software.intel.com/en-us/intel-advisor-xe" for details.

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.0.4.243 Build 20190416

Compiler options: -par-threshold0 -no-vec -fno-inline -parallel -qopt-report-phase=all -qopt-report=5 -o test.out

    Report from: Interprocedural optimizations [ipo]

  WHOLE PROGRAM (SAFE) [EITHER METHOD]: false
  WHOLE PROGRAM (SEEN) [TABLE METHOD]: true
  WHOLE PROGRAM (READ) [OBJECT READER METHOD]: false

INLINING OPTION VALUES:
  -inline-factor: 100
  -inline-min-size: 30
  -inline-max-size: 230
  -inline-max-total-size: 2000
  -inline-max-per-routine: 10000
  -inline-max-per-compile: 500000

In the inlining report below:
   "sz" refers to the "size" of the routine. The smaller a routine's size,
      the more likely it is to be inlined.
   "isz" refers to the "inlined size" of the routine. This is the amount
      the calling routine will grow if the called routine is inlined into it.
      The compiler generally limits the amount a routine can grow by having
      routines inlined into it.

Begin optimization report for: main(int, char **)

    Report from: Interprocedural optimizations [ipo]

INLINE REPORT: (main(int, char **)) [1/1=100.0%] modified_clean_DRB016-outputdep-orig-yes.c(5,1)
  -> EXTERN: (16,5) printf(const char *__restrict__, ...)
  -> EXTERN: (17,3) printf(const char *__restrict__, ...)


    Report from: Loop nest, Vector & Auto-parallelization optimizations [loop, vec, par]


LOOP BEGIN at modified_clean_DRB016-outputdep-orig-yes.c(9,3)
   remark #17109: LOOP WAS AUTO-PARALLELIZED
   remark #17101: parallel loop shared={ .2 } private={ } firstprivate={ argc } lastprivate={ } firstlastprivate={ i } reduction={ }
   remark #15540: loop was not vectorized: auto-vectorization is disabled with -no-vec flag
   remark #25439: unrolled with remainder by 2  
   remark #25456: Number of Array Refs Scalar Replaced In Loop: 1
   remark #25015: Estimate of max trip count of loop=100
LOOP END

LOOP BEGIN at modified_clean_DRB016-outputdep-orig-yes.c(9,3)
<Remainder>
   remark #25456: Number of Array Refs Scalar Replaced In Loop: 1
   remark #25015: Estimate of max trip count of loop=100
LOOP END

LOOP BEGIN at modified_clean_DRB016-outputdep-orig-yes.c(15,3)
   remark #17104: loop was not parallelized: existence of parallel dependence
   remark #15382: vectorization support: call to function printf(const char *__restrict__, ...) cannot be vectorized   [ modified_clean_DRB016-outputdep-orig-yes.c(16,5) ]
   remark #15344: loop was not vectorized: vector dependence prevents vectorization
   remark #25015: Estimate of max trip count of loop=100
LOOP END

LOOP BEGIN at modified_clean_DRB016-outputdep-orig-yes.c(9,3)
   remark #15540: loop was not vectorized: auto-vectorization is disabled with -no-vec flag
   remark #25439: unrolled with remainder by 2  
   remark #25456: Number of Array Refs Scalar Replaced In Loop: 1
   remark #25015: Estimate of max trip count of loop=100
LOOP END

LOOP BEGIN at modified_clean_DRB016-outputdep-orig-yes.c(9,3)
<Remainder>
   remark #25456: Number of Array Refs Scalar Replaced In Loop: 1
   remark #25015: Estimate of max trip count of loop=100
LOOP END

    Report from: Code generation optimizations [cg]

modified_clean_DRB016-outputdep-orig-yes.c(5,1):remark #34051: REGISTER ALLOCATION : [main] modified_clean_DRB016-outputdep-orig-yes.c:5

    Hardware registers
        Reserved     :    2[ rsp rip]
        Available    :   39[ rax rdx rcx rbx rbp rsi rdi r8-r15 mm0-mm7 zmm0-zmm15]
        Callee-save  :    6[ rbx rbp r12-r15]
        Assigned     :   14[ rax rdx rcx rbx rsi rdi r8-r15]
        
    Routine temporaries
        Total         :     125
            Global    :      33
            Local     :      92
        Regenerable   :      46
        Spilled       :       1
        
    Routine stack
        Variables     :      32 bytes*
            Reads     :       6 [0.00e+00 ~ 0.0%]
            Writes    :       9 [0.00e+00 ~ 0.0%]
        Spills        :      48 bytes*
            Reads     :      11 [5.00e+00 ~ 0.6%]
            Writes    :      11 [0.00e+00 ~ 0.0%]
    
    Notes
    
        *Non-overlapping variables and spills may share stack space,
         so the total stack size might be less than this.
    

===========================================================================

However, intel inspector reports a data race in the loop parallelized by ICC. The contents of “log/realtime_mode.log”, generated by intel inspector, follows below.

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
 <message severity="verbose">Analysis started...</message>
 <nop/>
 <message severity="info">Collection started. To stop the collection, either press CTRL-C or enter from another console window: inspxe-cl -r /home/gleison/Desktop/Fernando_modifed_example/r005ti3 -command stop.</message>
 <nop/>
 <message severity="verbose">Result file: /home/gleison/Desktop/Fernando_modifed_example/r005ti3/r005ti3.inspxe </message>
 <nop/>
 <message severity="verbose">Found target process /home/gleison/Desktop/Fernando_modifed_example/test.out (PID = 20895). Analysis started... </message>
 <nop/>
 <message severity="verbose">Loaded module: /home/gleison/Desktop/Fernando_modifed_example/test.out. </message>
 <nop/>
 <message severity="verbose">Loaded module: /lib64/ld-linux-x86-64.so.2. </message>
 <nop/>
 <message severity="verbose">Loaded module: [vdso]. </message>
 <nop/>
 <message severity="verbose">Loaded module: /lib/x86_64-linux-gnu/libm.so.6. </message>
 <nop/>
 <message severity="verbose">Loaded module: /usr/lib/x86_64-linux-gnu/libiomp5.so. </message>
 <nop/>
 <message severity="verbose">Loaded module: /lib/x86_64-linux-gnu/libgcc_s.so.1. </message>
 <nop/>
 <message severity="verbose">Loaded module: /lib/x86_64-linux-gnu/libpthread.so.0. </message>
 <nop/>
 <message severity="verbose">Loaded module: /lib/x86_64-linux-gnu/libc.so.6. </message>
 <nop/>
 <message severity="verbose">Loaded module: /lib/x86_64-linux-gnu/libdl.so.2. </message>
 <nop/>
 <message severity="verbose">Loaded module: /opt/intel/inspector_2019.4.0.597413/lib64/runtime/libittnotify.so. </message>
 <nop/>
 <message severity="warning">One or more threads in the application accessed the stack of another thread. This may indicate one or more bugs in your application. Setting the Inspector to detect data races on stack accesses and running another analysis may help you locate these and other bugs.</message>
 <nop/>
 <message severity="verbose">Unloaded module: /home/gleison/Desktop/Fernando_modifed_example/test.out. </message>
 <nop/>
 <message severity="verbose">Unloaded module: /lib64/ld-linux-x86-64.so.2. </message>
 <nop/>
 <message severity="verbose">Unloaded module: [vdso]. </message>
 <nop/>
 <message severity="verbose">Unloaded module: /lib/x86_64-linux-gnu/libm.so.6. </message>
 <nop/>
 <message severity="verbose">Unloaded module: /usr/lib/x86_64-linux-gnu/libiomp5.so. </message>
 <nop/>
 <message severity="verbose">Unloaded module: /lib/x86_64-linux-gnu/libgcc_s.so.1. </message>
 <nop/>
 <message severity="verbose">Unloaded module: /lib/x86_64-linux-gnu/libpthread.so.0. </message>
 <nop/>
 <message severity="verbose">Unloaded module: /lib/x86_64-linux-gnu/libc.so.6. </message>
 <nop/>
 <message severity="verbose">Unloaded module: /lib/x86_64-linux-gnu/libdl.so.2. </message>
 <nop/>
 <message severity="verbose">Unloaded module: /opt/intel/inspector_2019.4.0.597413/lib64/runtime/libittnotify.so. </message>
 <nop/>
 <message severity="verbose">Process /home/gleison/Desktop/Fernando_modifed_example/test.out (PID = 20895) has terminated. </message>
 <nop/>
 <message severity="verbose">Application exit code: 0 </message>
 <nop/>
 <message severity="verbose">Result file: /home/gleison/Desktop/Fernando_modifed_example/r005ti3/r005ti3.inspxe </message>
 <nop/>
 <message severity="verbose">Analysis completed</message>
 <nop/>
 <message severity="info">  </message>
 <nop/>
 <message severity="info">1 new problem(s) found </message>
 <nop/>
 <message severity="info">    1 Data race problem(s) detected </message>
 <nop/>
</feedback>

The loop has a race condition on a[10], which, if run in parallel, can receive either integers 10 (first iteration) or 11 (tenth iteration).

Regards,

Gleison

It should return a vector of integers.  The GCC documentation is pretty clear:

Vector comparison is supported with standard comparison operators: ==, !=, <, <=, >, >=. Comparison operands can be vector expressions of integer-type or real-type. Comparison between integer-type vectors and real-type vectors are not supported. The result of the comparison is a vector of the same width and number of elements as the comparison operands with a signed integral element type.

Note the last sentence.

GCC and clang both return the expected result, but ICC has other ideas and I end up with 1 << 31 instead of -1 for true.

Luckily the workaround is pretty straightforward: an explicit cast to the correct type.

Using Ubuntu 19.10 or 18.04 LTS, when using the latest version of the Intel C++ Compiler issued in Parallel Studio XE 2020 (version 19.1.0.166 / 20191121), attempts to build UCX with the -ipo flag result in failure when compiling & linking sockaddr (sa); this appears to be an issue with Intel's Compiler rather than UCX because the 2018 and 2019 editions of Parallel Studio XE (versions 18.0.6.286 / 20190605 and 19.0.5.281 / 20190815, respectively) are able to compile and link it just fine. Using GCC and G++ with LTO enabled is also able to compile and link it without issue. Also attached are the entire config and build logs.

These are the symbols that are not found. Attempting to explicitly link with -lstdc++, using different C++ and GNU++ standards, etc., fail to fix the problem:

ipo: error #11021: unresolved _ZNSt14_Function_base12_M_max_alignE
        Referenced in /tmp/ipo_icpcYJnRpy.o
ipo: error #11021: unresolved _ZNSt14_Function_base11_M_max_sizeE
        Referenced in /tmp/ipo_icpcYJnRpy.o

These are the demangled symbols:

std::_Function_base::_M_max_align
std::_Function_base::_M_max_size

An extremely easily reproduceible example that will fail to build is given below:

1. git clone --recurse-submodules https://github.com/openucx/ucx.git&& cd ucx
2. ./autogen.sh
3. ./configure CC=icc CXX=icpc LD=xild AR=xiar CFLAGS="-ipo"
4. make -j$(nproc)

This is the open bug report on the UCX project (where it was stated to likely be a regression on Intel's part), detailing the same information covered here:

https://github.com/openucx/ucx/issues/4624

With the Microsoft compiler, compiling in C++ standard compliance mode of 2017 or later, I can use SIMD data types for example in std::vector without custom allocators. When trying to use Intel compiler from Visual Studio this does not seem to work. (I am new to using the Intel compiler, so I may just be missing some option, but I think I have tried the standard version settings etc)

I have attached example code at the bottom of this message. The memory allocations of course vary, and often produce aligned results, even if not set really set up correctly. The define (commented out) on the first line seems to be the one controlling the behavior in Microsoft header files, if it is used, then the code works also with Intel compilers. As the defined symbol is in"compiler namespace", I guess defining it as a user is not a clean solution.

There are some compatibility issues between Visual Studio 2019 and Intel compiler, so I have done my testing with Visual Studio 2017.

 Eero

//#define __cpp_aligned_new 1
#include <stdio.h>
#include <xmmintrin.h>
#include <vector>

struct Test_S{
  __m128 v;
  float b;
};

int main(){
  fprintf(stderr,"Alignment requirement = %d\n",alignof(Test_S));
#ifdef __cpp_aligned_new
  fprintf(stderr,"__cpp_aligned_new defined\n");
#else
  fprintf(stderr,"__cpp_aligned_new not defined\n");
#endif
  std::vector<Test_S> a;
  a.push_back(Test_S());
  fprintf(stderr,"addr=%p\n",&(a[0].v));
  std::vector<Test_S> b;
  b.push_back(Test_S());
  fprintf(stderr,"addr=%p\n",&(b[0].v));
  std::vector<Test_S> c;
  c.push_back(Test_S());
  fprintf(stderr,"addr=%p\n",&(c[0].v));
}

OS- Linux login1 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Compiler - intel parallel studio 19.5 with GCC 8.3.0

CUDA - 10.1

Application - Gromacs -2020 -  ftp://ftp.gromacs.org/pub/gromacs/gromacs-2020.tar.gz

Error- 

icpc: error #10106: Fatal error in /home/opt_ohpc_pub/intel/compilers_and_libraries_2019.5.281/linux/bin/intel64/mcpcom, terminated by floating point exception
compilation aborted for /home/samir/gromacs_2020/gromacs-2020/src/gromacs/pulling/pullutil.cpp (code 1)

Hi all,

I'm trying to compile R 3.4.2 from the source code following this guide:

https://software.intel.com/en-us/articles/build-r-301-with-intel-c-compiler-and-intel-mkl-on-linux

However, I got the following error when building (see below). It builds using gcc without problems.  Do you have an idea of what could be happening?

Best,

Marko

icc -I../../src/extra  -I. -I../../src/include -I../../src/include  -I/usr/local/include -I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -g -O2 -std=c99  -c arithmetic.c -o arithmetic.o
arithmetic.c(59): warning #274: declaration is not visible outside of function
  int matherr(struct exception *exc)
                     ^

arithmetic.c(61): error: pointer to incomplete class type is not allowed
      switch (exc->type) {
              ^

arithmetic.c(62): error: identifier "DOMAIN" is undefined
      case DOMAIN:
           ^

arithmetic.c(63): error: identifier "SING" is undefined
      case SING:
           ^

arithmetic.c(66): error: identifier "OVERFLOW" is undefined
      case OVERFLOW:
           ^

arithmetic.c(69): error: identifier "UNDERFLOW" is undefined
      case UNDERFLOW:
           ^

arithmetic.c(70): error: pointer to incomplete class type is not allowed
  	exc->retval = 0.0;
  	^

compilation aborted for arithmetic.c (code 2)
../../Makeconf:119: recipe for target 'arithmetic.o' failed

Hello,

I'm not sure why, but when I use Intels Optimized Headers(specifically valarray) the compiler will point out about 66 or so syntax errors. I'm unsure why this is happening.

I'm on Visual Studio 2019.4.1(enterprise) and Intel C++ Compiler version 19.1

Thanks

I hope this is the correct forum.  I just download the 30 day trial of parallel studio xe 2020 cluster edition (online) for linux to test out the intel c/c++ compiler.

When I run the install.sh I get an error saying

CPU is not supported.

Where can I find out what CPUs are supported?  

Also, is parallel studio the only way for me to get a copy of the compiler for testing?

Thanks, Ted

uname -a shows 

Linux vlbuild1 2.6.18-164.11.1.el5 #1 SMP Wed Jan 6 13:26:04 EST 2010 x86_64 x86_64 x86_64 GNU/Linux

and /proc/cpuinfo shows

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : QEMU Virtual CPU version (cpu64-rhel6)
stepping        : 3
cpu MHz         : 2899.998
cache size      : 4096 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 4
wp              : yes
flags           : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm pni cx16 lahf_lm
bogomips        : 5799.99
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:
 

As of year 2020 AD what is the best C++ version for the latest Intel CPU?

I am using 32 bit Microsoft Windows.

I chose, months ago, to learn C++11 and I am learning it via CODE::BLOCKS 17.12 . It seemed at the time that C++11 was the most widely compatible version and the most stable version in relation to common computer hardware. I am now checking if that is currently applicable to the latest and greatest Intel CPUs;

Whatever the latest and greatest Intel CPU that is available on the open market in the United States of America.

What is the latest version of C++ that will work very well with that CPU?

I am *not* asking about Microsoft Visual Studio for this.

I am *not* asking about ".net" versions of C++ for this.

Just straight C++ on the latest and greatest Intel CPU.

And, what is that Intel CPU? I have heard that there is to be a super multi-core Intel CPU out now. Maybe?

Thank you.

Visual Studio 14.9.19
Intel Parallel Studio XE 2020
Latest Windows 10

The following piece of code (VS project attached) fails to link with an error

1>ipo_1894819obj3.obj : : error LNK2019: unresolved external symbol wmemcmp referenced in function main

when built it in C++17 mode.

#include "stdafx.h"
#include <string>
#include <wchar.h>

int main()
{ 
	std::wstring a = L"Hallo";
	std::wstring b = L"Dulla";
	printf("%d\n", int(a == b));  // comment out this line and it will link fine
	printf("%d\n", wmemcmp(a.data(), b.data(), 5));
	return 0;
}

When I comment out the marked line, it links fine.

When I switch C++ standard to C++14 it builds fine, too.

As the line with the explicit call to "wmemcmp" does not cause any problems I have the impression that the wmemcmp used for the wstring comparison uses an erroneous function signature in C++17-mode only.

Regards, Frank

I'm currently evaluating the possibility to move from C++11 to C++17. I currently use VS 2017 and Intel Compiler 19.0.0 (Initial Release), and I got two questions:

⚫ Q1: Does IC 19.0.0 supports C++17 with VS 15.7 or older versions?

I checked the Visual Studio 2017 support article [1] and it says the following regarding VS 2017, IC 19.0.0 and C++17:

Microsoft Visual Studio 2017 version | Supported Intel Compiler Version
-------------------------------------|----------------------------------------------
15.8                                 | 19.0 but without the additional C++17 support
15.7                                 | 19.0
15.6, 15.5, 15.4                     | 19.0 Initial Release

[1]: https://software.intel.com/en-us/articles/intel-compilers-integration-su...

There is no note on C++17 support with VS 15.4 to 15.7, but there is an explicit note on the lack of support with 15.8, This gives me the impression that IC 19.0 would support C++17 on these older VS versions. I tried searching the FAQs, Release Notes and documentation as well as this forum, but I could not find any piece of information to confirm if C++17 is supported or not with those older VS 2017 minor versions.

Does anyone here knows if IC 19.0.0 supports compiling code in C++17 mode when used with VS 2017 minor versions 15.7 or older?

⚫ Q2: How can I tell compilervars.bat which VS 2017 toolset (minor version) it should use?

My VS 2017 install (15.9.19) has multiple VC toolsets (found in the VC\Tools\MSVC directory):

VC Toolset | `_MSC_VER` | VS 2017 version
-----------|------------|----------------
   14.13   |    1913    |      15.6
   14.14   |    1914    |      15.7
   14.16   |    1916    |      15.9

When calling compilervars.bat to set up the development environment, I couldn't find a way to tell it which VS 2017 toolset it should use. By compiling a simple program which outputs the _MSC_VER, it seems to be getting the latest one (VC 14.16, VS 15.9):

// version.cpp
#include <iostream>
int main() {
    std::cout << _MSC_VER << '\n';
}

> "C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\bin\compilervars.bat" intel64 vs2017
> icl.exe version.cpp
> version.exe
1916

Assuming that ICC 19.0.0 would support C++17 mode with VS 2017 15.7 or older, I would need to find a way to make compilervars.bat use another toolset version (e.g.: VC 14.13, VS 15.6). 

Is there any way to tell compilervars.bat which VS 2017 toolset (minor version) it should use among the ones installed?

Hello,

I've found that some codes compiled by the Intel compiler are significantly slower than those by GCC.
Here is a sample code.

https://github.com/kaityo256/compiler_test

This is a Monte Carlo simulation code of the Potts model which is one of the fundamental models in statistical physics.

Here is a benchmark result.

* Compile Options

g++ -O3 -march=native -Wall -Wextra -std=c++11  main.cpp -o gcc.out
icpc -O3 -xHOST -Wall -Wextra -std=c++11  main.cpp -o icpc.out

* Environment

CPU: Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz
OS: CentOS Linux release 7.6.1810 (Core)
GCC: g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
icpc: icpc (ICC) 19.0.4.243 20190416

$ ./gcc.out
Magnetization : 0.891599
Elapsed : 305 [ms]

$ ./icpc.out
Magnetization : 0.891599
Elapsed : 880 [ms]

The two executables give the identical result, but the executable produced by Intel compiler is significantly slower than that by GCC.

I want to figure out what is happening here and write an article (maybe in Japanese). But I am afraid that the detailed analysis of optimization can be regarded as "reverse engineering" which is inhibited in EULA, since the investigation may reveal the limitations of optimization capabilities of the Intel compiler.

I am going to compare assembly codes produced by GCC and the Intel compiler, but I will not decompile the Intel compiler.

Does the above attempt violate EULA?

Thanks in advance.

Less of a bug report and more of a request to implement the ; the "-static-pie" flag is already available in most newer versions of GCC and Clang, but it is an unrecognized flag by icc/icpc, and -static -pie is not the same as -static-pie (because -static and -static-pie are mutually exclusive in GCC).

The implementation is fairly simple, with the largest change being that when linking to startfiles, it just needs to link to rcrt1.o for -static-pie and to grcrt1.o for -static-pie with PGO, instead of linking to Scrt1.o (PIE) or crt1.o(static lib). When linking to the end files, it would use crtbeginS.o instead of crtbeginT.o (as is usually used for static libs.)

Some relevant info/files:

https://github.com/gcc-mirror/gcc/blob/master/gcc/config/gnu-user.h 

I'm getting a ton of invalid warnings from ICC about an __assume with side effects.  It turns out the "problem" is that I'm using a statement expr (which has no side effects).  Here is a reduced test case:

#include <stdint.h>

void foo(int *bar) {
  __assume((
	    ((uintptr_t) bar)
	    % 16) == 0);

  __assume((
	    (__extension__ ({ (uintptr_t) bar; }))
	    % 16) == 0);
}

Which triggers:

aa.c(8): warning #2261: __assume expression with side effects discarded
    __assume((
             ^

I've already tweaked my code to get rid of the statement expr, so no need to think of work-arounds on my behalf.  I just wanted to report the issue.

I am trying to compile the simulation software LAMMPS using CMake, and run into some trouble:
 

-- Could NOT find MPI_CXX (missing: MPI_CXX_LIB_NAMES) (found version "3.1")
CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find MPI (missing: MPI_CXX_FOUND) (found version "3.1")
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.16/Modules/FindMPI.cmake:1688 (find_package_handle_standard_args)
  CMakeLists.txt:180 (find_package)

I do have the latest intel parallel studio

$ icc -V
Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.166 Build 20191121
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

I'm on Archlinux, and the version of CMake I'm using is:

$ cmake --version
cmake version 3.16.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).

My compilation options are:

-DCMAKE_C_COMPILER=mpiicc
-DCMAKE_C_FLAGS=-xHost -O2 -fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high
-DCMAKE_CXX_COMPILER=mpiicpc
-DCMAKE_CXX_FLAGS=-fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high -qno-offload -fno-alias -ansi-alias -O2 -std=c++11 -DLMP_INTEL_USELRT -DLMP_USE_MKL_RNG -I${MKLROOT}/include
-DCMAKE_Fortran_COMPILER=mpiifort

Am I doing something wrong?

Apologies if the issue was already reported but have a look at the following code snippet

#include <variant>

std::variant<int, char*> foo()
{
    return 0xD;
}

This should compile by choosing the converting constructor overload of the variant whose definition is

template< class T >
constexpr variant(T&& t) noexcept(...);

but it does not compile as can be seen here.

Compiler flags used: -std=c++17 -O3 -Wall -Werror

Compiler version: v19.0.1