Quantcast
Channel: Intel® Software - Intel® C++ Compiler
Viewing all 1175 articles
Browse latest View live
↧

xilib: : error #10036: unable to run 'lib'

December 6, 2016, 4:44 pm
$
0
0

I've tried to build project in VS2013 on Win8.1 machine. Intel compiler installed here:

C:\Program Files (x86)\Intel\System Studio 2015 for Windows.4.027\

I have following related diagnostic output:

1>xilib: : error #10036: unable to run 'lib'
1>xilib: : error spawn_errno_default: spawn('C:\PROGRA~2\Intel\SYSTEM~1.027\bin\ia32\xilink.exe') failed, errno=0
1>  The command exited with code -1. (TaskId:23)

I can easily spawn xilink.exe from the command line using specified path. This issue doesn't exist if I built x64 version of my project.

How can I resolve this issue?

Zone: 

Thread Topic: 

Question
↧
Search

icc 17.0.1 miscompiles valid C code at -Os and above on x86_64-linux-gnu

December 7, 2016, 4:45 pm
$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O1 small.c; ./a.out
$
$ icc -Os small.c; ./a.out
0
$
$ cat small.c
int printf (const char *, ...);

long a[2], b, c;

int main ()
{
  long d = 3620225796;
  for (; c < 1; c++)
    d = 0;
  if (~d && d)
    printf ("%ld\n", b);
  a[d] = 1;
  return 0;
}
$

 

↧
↧

icc 17.0.1 miscompiles valid C code at -Os (only) on x86_64-linux-gnu

December 8, 2016, 11:03 am
$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O1 small.c; ./a.out; echo $?
1
$
$ icc -Os small.c; ./a.out; echo $?
48
$
$ cat small.c
struct S
{
  int f;
} a;

int b, c;

void foo ()
{
  for (; b < 5; b++)
    {
      struct S d[1] = { { 1 } };
      a = d[0];
    }
}

int main ()
{
  foo ();
  for (c = 0; c;)
    ;
  return a.f;
}
$

 

↧

Unable to uninstall Intel Cluster Studio XE 2013 SP1 Update 1

December 8, 2016, 10:39 pm
$
0
0

Hi,

I have completed my 30 day trial period and now I want to uninstall from my machine. But it is throwing an error and not allowing me to uninstall, I have attached the error snapshot. Could you help to uninstall this version.

 

Thanks,

Pradeep 

AttachmentSize
Downloadimage/pngError.png88.55 KB
↧

license cost

December 9, 2016, 1:09 am
$
0
0

Hi,

Could you tell me the license cost for Intel Composer XE 2013 SP1. 

thanks,

Pradeep

↧
↧

icc 17.0.1 miscompiles valid C code at all optimization levels (including -O0) on x86_64-linux-gnu

December 9, 2016, 8:16 am
$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ gcc -O0 small.c; ./a.out
$ clang -O0 small.c; ./a.out
$
$ icc -O0 small.c
$ timeout -s 9 10 ./a.out
Killed
$
$ cat small.c
int main ()
{
  goto L1;
  if (0) {
  L2:
    ;
  }
  else {
  L1:
    goto L2;
  }
  return 0;
}
$

 

↧

icc 17.0.1 miscompiles valid C code at -O2 (only) on x86_64-linux-gnu

December 9, 2016, 8:55 pm
$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -Os small.c; ./a.out
$ icc -O3 small.c; ./a.out
$
$ icc -O2 small.c
$ ./a.out
Segmentation fault (core dumped)
$
$ cat small.c
int a, *b, c, d;

int fn1 ()
{
  int e = 0;
  for (; e < 4; e++)
    if (d && *b)
      break;
  if (e & a)
    while (1)
      ;
  return c;
}

int main ()
{
  fn1 ();
  return 0;
}
$

 

↧

icc 17.0.1 crashes on valid C++ code on x86_64-linux-gnu (Segmentation violation signal raised)

December 9, 2016, 11:51 pm
$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ g++ -c small.cpp
$ clang++ -c small.cpp
$
$ icc -c small.cpp": internal error: ** The compiler has encountered an unexpected problem.
** Segmentation violation signal raised. **
Access violation or stack overflow. Please contact Intel Support for assistance.

compilation aborted for small.cpp (code 4)
$
$ cat small.cpp
struct S
{
  S () {}
  S (const S &) {}
};

S foo ()
{
  return ({ S (); });
}
$

 

↧
Search

Window x64 17.0.1 compiler, Visual Studio 2015, and std::list checked iterators issue

December 10, 2016, 1:22 pm
$
0
0

I have encountered a number of mysterious crashes on Windows x64 using 17.0.1 in _DEBUG mode only. In _DEBUG mode on Windows, various STL functions are validated using what are called "checked iterators"

 

Here is my sample test program. To reproduce, create a Visual C++ 2015 console project, and run in x64|Debug mode.

#include "stdafx.h"
#include <list>
#include <iostream>
using namespace std;
int main()
{
	std::list<int> a;
	a.clear();
	for(auto & i : a){// we have an iterator loop here, this forces creation of some sticky iterator data structures in the list
		cout << i << endl;// some dummy code
	}
	a.clear();// Intel Compiler and Visual Studio 2015 compiler behave differently on second clear()
    return 0;
}
/// THE FOLLOWING IS PART OF <list>, list::clear() calls _Orphan_ptr(nullptr) in _DEBUG mode
 #if _ITERATOR_DEBUG_LEVEL == 2
	void _Orphan_ptr(_Nodeptr _Ptr)
		{	// orphan iterators with specified node pointers
		_Lockit _Lock(_LOCK_DEBUG);
		const_iterator **_Pnext = (const_iterator **)this->_Getpfirst();
		if (_Pnext != 0)
			while (*_Pnext != 0)
				{	// test an iterator
				if ((*_Pnext)->_Ptr == this->_Myhead()
					|| (_Ptr != nullptr_t{} && (*_Pnext)->_Ptr != _Ptr))
					_Pnext = (const_iterator **)(*_Pnext)->_Getpnext();
				else
					{	// orphan the iterator
					(*_Pnext)->_Clrcont();
					*_Pnext = *(const_iterator **)(*_Pnext)->_Getpnext();
					}
				}
		}
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */

when I step into the function list::_Orphan_ptr  I see different behavior between Visual Studio 2015 native compiled and Intel 17.0.1 compiled in _DEBUG mode, that is with _ITERATOR_DEBUG_LEVEL=2, 

In simple language, if the list is empty, the while() loop should NEVER be entered. 

Visual Studio 2015 -> _Pnext!=0, *_PNext=0 , while loop is skipped ( as expected)

Intel Compiler 17.0.1 -> _Pnext!=0, *_PNext=<some random number>, while loop is entered, often causing an access violation.

This may be a bug in the checked iterator code of MS STL or it may be a bug in the Intel Compiler - I am not sure 100% at the moment.

Zone: 

↧
↧

[windows] math.h warnings when using cl from Intel Env (cmd)

December 10, 2016, 8:15 am
$
0
0

I have the following installation:

- Windows 10

- Visual Studio 2015 (community edition)

- Intel 17.0 Update 1 (parallel studio xe composer edition for fortran and C++)

There are reasons to use  VS/cl with ParallelStudio/ifort. Here is a simple code that compiles cleanly with cl with "Visual Studio 2015 x64 Native Tools Command Prompt" - but gives warnings with "Compiler 17.0 Update 1 for Intel 64 Visual Studio 2015 environment"

######  VS CMD ################################

C:\cygwin64\home\balay\junk>type mathtest.c
#include <math.h>
int main() {
  return 0;
}

C:\cygwin64\home\balay\junk>cl mathtest.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

mathtest.c
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:mathtest.exe
mathtest.obj

C:\cygwin64\home\balay\junk>

######## Intel CMD #####################################################

c:\cygwin64\home\balay\junk>icl mathtest.c
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.143 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

mathtest.c
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:mathtest.exe
mathtest.obj

c:\cygwin64\home\balay\junk>cl mathtest.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

mathtest.c
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.1.143\windows\compiler\include\math.h(1577): warning C4005: 'HUGE_VALF': macro redefinition
C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\../ucrt/math.h(80): note: see previous definition of 'HUGE_VALF'
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.1.143\windows\compiler\include\math.h(1579): warning C4005: 'HUGE_VALL': macro redefinition
C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\../ucrt/math.h(81): note: see previous definition of 'HUGE_VALL'
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.1.143\windows\compiler\include\math.h(1581): warning C4005: 'HUGE_VAL': macro redefinition
C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\../ucrt/math.h(79): note: see previous definition of 'HUGE_VAL'
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:mathtest.exe
mathtest.obj

c:\cygwin64\home\balay\junk>

Perhaps a bug in Intel include files?

↧

icc (ICC) 17.0.1 20161005 miscompiles C++11 code (related to move constructor ?)

December 12, 2016, 5:32 am
$
0
0

Given test.cpp

#include <string>
#include <cassert>

class CPLString : public std::string
{
public:
    CPLString( const std::string &oStr ) : std::string( oStr ) {}
};

int main()
{
    CPLString osTest("test");
    CPLString osTest2( 0 ? std::string() + osTest : osTest );
    assert( !osTest.empty() );
}

$ icc -g -Wall -Wextra -std=c++11 test.cpp -o test && ./test
test: test.cpp:14: int main(): Assertion `!osTest.empty()' failed.

Whereas without -std=c++11 it doesn't assert.

On Ubuntu 16.04 64 bit. The same compiled with gcc 5.4 or clang 3.8 in C++11 doesn't assert.

↧

Intel Premier Support Legacy Status Update

December 12, 2016, 6:32 pm
↧

How to switch to IA-32 compiler in VS2015?

December 13, 2016, 11:09 am
$
0
0

I have recently installed Intel Parallel Studio XE 2017 on Windows 7 64-bit that had Microsoft Visual Studio Professional 2015 (Version 14.0.23107.0 D14REL). It works fine, and I can build Win32 build configuration from legacy projects migrated from Visual Studio 2013. However, despite me using the /Qm32 compiler option, the code appears to be 64-bit. (the size of .exe is about 2 times larger than previous builds) I would like to be able to build 32-bit executables for compatibility with legacy projects.

I checked the build log generated by the compiler, and it confirmed that the compiler binary being used is 64-bit:

1>ClCompile:
         C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.1.143\windows\bin\intel64\icl.exe /c /Qm32 ...

How can I use the IA-32 version of the compiler? I mean the one in bin\ia32\icl.exe. I have tried several things like running VS2015 from the 32-bit command shell installed by the Intel Parallel Studio, or setting TARGET_ARCH or C_TARGET_ARCH environment variables to "ia32".

Also, in Visual Studio menu Tools/Options/Intel Compiler and Tools/C++, I changed the Intel C++ Compiler 17.0 Platform toolset to "Intel (R) C++ Compiler 17.0.1.143 [IA-32]". But the entry in the build log still shows the IDE using the 64-bit compiler.

Also, how can I tell from the shell whether the exec is 32- or 64-bit? Is there an analog of file or ldd utilities on Windows?

Zone: 

Thread Topic: 

Bug Report
↧
↧

Compiler fails with: internal error: assertion failed at: "shared/cfe/edgcpfe/scope_stk.c"

December 14, 2016, 3:11 pm
$
0
0

Using beast library and example from https://github.com/vinniefalco/Beast/tree/master.

Using ICC: 17.0.1 20161005

When compiling the example, compiler fails with "internal error":

In file included from /home/vasko/xxx/ext/beast/include/beast/core/handler_concepts.hpp(11),

                 from /home/vasko/xxx/ext/beast/include/beast/core/async_completion.hpp(11),
                 from /home/vasko/xxx/ext/beast/include/beast/http/parse.hpp(12),
                 from /home/vasko/xxx/ext/beast/include/beast/http.hpp(17),
                 from /home/vasko/xxx/yyy/request_handler.hpp(6),
                 from /home/vasko/xxx/yyy/server.hpp(1),
                 from /home/vasko/xxx/yyy/main.cpp(1):
/home/vasko/xxx/ext/beast/include/beast/core/detail/is_call_possible.hpp(41): internal error: assertion failed at: "shared/cfe/edgcpfe/scope_stk.c", line 11203

      : decltype(is_call_possible_test<R>(
                 ^

 

Any clue?

Vasko

 

Thread Topic: 

Bug Report
↧

Compiler 17.0.1 Windows "Emit Optimization Diagnostics to File=No" broken?

December 14, 2016, 3:34 pm
$
0
0

It was really nice in Visual Studio 2013/Intel Compiler 15.0 that Windows "Emit Optimization Diagnostics to File=No" would send data to the "Compiler Optimization Report" Window of Visual Studio

Now it appears with Visual Studio 2015/Intel Compiler 17 that even if "Emit Optimization Diagnostics to File=No" a .optrpt file is created  - and nothing goes to the Visual Studio window no matter what the setting is.

This seems a broken feature to me.

↧
Search

Unexpected ICC sloweness while starting

December 15, 2016, 3:45 am
$
0
0

Dear all,
we're having a very strange issue in one of our clusters: while running "icc -v", for example the binary gets stuck for several seconds while waiting for something and then the strace output shows a timeout.

By searching for the HEX dump surrounding that wait/timeout step we discovered that the issue can be solved by enabling IPv6:
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6
(https://github.com/hiboma/hiboma/blob/master/centos7-nss_myhostname-bloc... - no, I do not read Japanese).

Any suggestion on how to permanently disable this check since we don't use IPv6 at all?
Any idea why the issue has cropped up just now after many months of use?

Regards.

↧

mcpcom generated command line too large for mcpcom

December 15, 2016, 6:27 pm
$
0
0

Hi,

while examining various Intel optimizations, I ran:

icc -march=native -E -v - </dev/null 2>&1 | grep mcpcom

The output was:

/opt/intel/compilers_and_libraries_2017.0.098/linux/bin/intel64/mcpcom    --target_efi2 -_g -mP3OPT_inline_alloca -D__ICC=1700 -D__INTEL_COMPILER=1700 -D__INTEL_COMPILER_UPDATE=0 -D__PTRDIFF_TYPE__=long "-D__SIZE_TYPE__=unsigned long" -D__WCHAR_TYPE__=int "-D__WINT_TYPE__=unsigned int""-D__INTMAX_TYPE__=long int""-D__UINTMAX_TYPE__=long unsigned int" -D__LONG_MAX__=9223372036854775807L -D__QMSPP_ -D__OPTIMIZE__ -D__NO_MATH_INLINES<!--break--> -D__NO_STRING_INLINES -D__GNUC_GNU_INLINE__ -D__GNUC__=4 -D__GNUC_MINOR__=9 -D__GNUC_PATCHLEVEL__=0 -D__LP64__ -D_LP64 -D__GXX_ABI_VERSION=1002 "-D__USER_LABEL_PREFIX__= " -D__REGISTER_PREFIX__= -D__INTEL_RTTI__ -D__unix__ -D__unix -D__linux__ -D__linux -D__gnu_linux__ -B -Dunix -Dlinux "-_Asystem(unix)" -D__ELF__ -D__x86_64 -D__x86_64__ -D__amd64 -D__amd64__ "-_Acpu(x86_64)""-_Amachine(x86_64)" -D__INTEL_COMPILER:_BUILD_DATE=20160721 -D__INTEL_OFFLOAD -D__pentium4 -D__pentium4__ -D__tune_pentium4__ -D__SSE2__ -D__SSE2_MATH__ -D__SSE3__ -D__SSSE3__ -D__SSE4_1__ -D__SSE4_2__ -D__SSE__ -D__SSE_MATH__ -D__MMX__ -D__AVX__ -D__AVX_I__ -D__AVX2__ -D__FMA__ -_k -_8 -_l --has_new_stdarg_support -_a -_b -E --gnu_version=40900 -_W5 --gcc-extern-inline --multibyte_chars -mGLOB_diag_suppress_sys --array_section --simd --simd_func --offload_mode=1 --offload_target_names=gfx,GFX,mic,MIC --offload_unique_string=icc0055607795stbXXx -mP1OPT_print_version=FALSE -mGLOB_em64t=TRUE -mP1OPT_version=17.0-intel64 -mGLOB_long_size_64 -mGLOB_routine_pointer_size_64 -

However, if I try and actually *use* that, this is the result (with an "hello.c -o hello" appended to it):

Command-line error: too many arguments on command line

`wc -w` lets me know we've got 93 words. I receive the same error with Intel Compiler 17.0 and Intel 16.0 on mac OS 10.12.1 <!--break-->and OS X 10.11.6 (though mac OS + Intel 16 has 98 command-line words).

 

Jay.

 

 

Thread Topic: 

Bug Report
↧
↧

icpc fails to alert on an obvious compilation error in a call to std::copy

December 16, 2016, 9:12 am
$
0
0

The following simple code shows a strange behavior compiled by icpc:

#include <algorithm>
#include <complex>
#include <vector>

struct Float {
    float _f;
};

struct Float2 {
    float _f1;
    float _f2;
};

// using objType = float;               // Uncommenting this line will cause compilation to fail in line 22 (call to std::copy () in A::copyVect ())
// using objType = Float;               // Same for this line
// using objType = Float2;              // And for thils line too
using objType = std::complex<float>;    // For this line compilation succeeds though it should fail as well

class A {
public:
    void copyVect (std::vector<objType> &vectSrc) const {
        std::copy (vectSrc.begin (), vectSrc.end (), _vect.begin ());
    }

public:
    std::vector<objType> _vect;
};

int main()
{
    return 0;
}

Compilation was done using the command:

icpc-4.8 -std=c++11 stdcopy.cpp -o stdcopy

 

AttachmentSize
Downloadtext/x-c++srcstdcopy.cpp710 bytes

Thread Topic: 

Bug Report
↧

Xcode 8.2 Support

December 17, 2016, 2:43 pm
$
0
0

Hi, I installed Intel C++ Compiler (and GDB, nothing more) using Parallel Studio XE 2017 Update 1 on a macOS 10.12.2 with Xcode 8.2.

When asked about environment, I selected the option "Both command line and Xcode integration environment".

The installation completed successfully, but when I go to the target's compiler option in Xcode, there's no intel compiler (only default Apple llvm). If I manually enter the /opt/intel/bin/icc it accept, but it mark as "Unsupported compiler" and compilation fails with error: Unable to determine concrete GCC compiler for file [...]/main.cpp

↧

VS Profiler Instrumentation of dlls compiled with Intel Compiler 16.0

December 21, 2016, 9:16 am
$
0
0

Hi all,

we are experiencing some problems when trying to profile a dll with the Visual Studio Profiler in instrumentation mode. Our setup is such that we compile VS 2015 or 2010 solutions with the Intel Compiler 16.0 Update 4 and base toolset v100 (from VS 2010).  

We use the profiler to start the application that uses our dll, which then causes one of two errors: either our application throws an exception "EXCEPTION_ACCESS_VIOLATION" and crashes, or an error "Error VSP1033: The file 'my.dll' does not contain a recognized executable image." appears and the profiling does not even start.

I tried profiling the most simple dll in our context, and surprisingly it worked. As soon as I introduce some STL code (for example allocate some std::vector) the exception appears again. 

We had this problem on both, Windows 7 and Windows 10 PCs.

We're trying to make the VS Profiler work since we just recently migrated our compiler and we like to preserve some comparability with older profiling results.
 

Any hints on how to solve this or why this might not work are well appreciated.

Thank you!

↧
Viewing all 1175 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>