Intel Software Network articles Feed

"The system cannot find the path specified" when building samples using Intel® Threading Building Blocks

Tue, 06 Sep 2011 00:00:00 -0700

Reference Number : DPD200172472

Version : 2011

Product : Intel® C++ Composer XE, Intel® Parallel Composer

Operating System : Windows*

Problem Description : In update 6, certain compiler samples that use Intel® Threading Building Blocks, for example cilk\qsort-mutex may fail when built in Microsoft Visual Studio 2010* during a post-build copy step. The output you get will look like:

1>  Description: Copy TBB DLLs
1>  The system cannot find the path specified.
1>  The system cannot find the path specified.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command "copy /y "\redist\ia32\tbb\vc_mt\tbb_debug.dll" "C:\Cilk\RC3\Cilk\qsort-mutex\Debug\"
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: copy /y "\redist\ia32\tbb\vc_mt\tbbmalloc_debug.dll" "C:\Cilk\RC3\Cilk\qsort-mutex\Debug\"
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: 
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code 1.
1>
1>Build FAILED.

Resolution Status : We are working on resolving this in a future release. In the meantime, go to the project properties for the sample in question, go to "Build Events->Post Build Event" and Edit the "Command Line" field, and replace any instance of "$(INTEL_DEF_IA32_INSTALL_DIR)" with the hardcoded path to the Intel Parallel Composer or C++ Composer XE root directory.

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Intel C++ Compiler XE 12.0.targets(206,5): error : backend signals

Wed, 15 Jun 2011 21:00:00 -0700

Reference Number : DPD200170608

Version : 12.0

Product : Intel(R) C++ Compiler XE Version 12.0

Operating System : Windows*

Problem Description : When compiling some programs in the Visual Studio* 2008 or 2010 the compiler may issue the following error:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\Intel C++ Compiler XE 12.0\Microsoft.Cpp.Win32.Intel C++ Compiler XE 12.0.targets(206,5): error : 0_12307

Resolution Status : This is a known issue that is under investigation. The issue may be resolved in a future product update. As a temporary workaround to avoid the error and be able to build the rest of the project with the Intel(R) C++ Compiler you could compile the affected file with the Microsoft* C++ Compiler in the IDE as follows:

- Right click the file name and click "Properties==>C/C++==>General[Intel C++]==>Use Visual C++ Compiler==>Yes

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

internal error: 0_1204 when openmp used with try-catch

Tue, 07 Jun 2011 08:30:00 -0700

Reference Number : Q625172

Version : 12.0 update 1 & 2

Product : Intel® C++ Compiler XE 12.0 update 1 & 2

Operating System : Windows*

Problem Description :
The below code was reduced from a big customer project, that uses Qt. The bug is in Intel compiler,
when openmp pragma/option is used, and exception-handling is used in a particular manner, though not in other cases. The workaround is to use /Od , instead of /O2. Or, do not use openmp pragma. Also, enable /EHsc since C++ exception handling mechanism is used.

Command-line for the bug:--
icl /c /Qopenmp /EHsc qterror.cpp

compile Error :-- internal error: 0_1204

Sometimes, during parallel compilation (using /MP), when such compile errors are generated, the below error message also comes in the output.
icl: error #10298: problem during post processing of parallel object compilation

Below sample code generates the error:--

#include 
using namespace std;
#include 

class myclass{};
vector					myvec;
template 
const T &mymin(const T &a, const T &b) { if (a < b) return a; return b; }
void func(const char* ch, const char* FILE, int LINE)
{
	cout << ch << " in file: " << __FILE__ << " in line: " << __LINE__ << "\n";
	return;
}
bool Do()
	{
		myclass *j=&myvec[100];
		int lines = mymin(10,100);

		if(!lines)
		{
			{
			#pragma omp parallel for //num_threads(komp_num_threads) schedule(guided)
			for (int y = 0; y <= 100; y++)
			{
			try {
			func( "Openmp error",__FILE__, __LINE__ );		
				
			}catch(std::exception e) { };
			}
		}
		}
		
		return 1;
}

Resolution Status : This bug has been resolved in Intel Composer 12.0 XE update 3 , 4

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

mathimf.h is incompatible with system math.h

Mon, 30 May 2011 08:30:00 -0700

Reference number: DPD200166165

Problem : mathimf.h problem in VS2010

Environment : VS2010 , Intel C++ compiler

Affected compilers: 12.0 u/d (1 to 4)

Sample code:

#pragma once

#include 
using std::string;

#include 

class bccb
{
bccb(void);
~bccb(void);
};


bccb::bccb(void)
{
}

bccb::~bccb(void)
{
}

Problem Description:--
When above is compiled with Intel compiler in VS2010 mode, following error:--

# error " is incompatible with system !"

With VS2008, the code compiles fine.

Solutions/workarounds:--

1. Use math.h instead of mathimf.h, and in case of a needed Intel-specific functions, their definitions can be taken from mathimf.h and inserted into application code.

2. Standard recommendation is to avoid usage of math.h and mathimf.h in the same compilation unit
by separating code that depends on math.h from the code that depends on mathimf.h into dirrerent files.
The above code though has the problem that the use is not avoided. This is an issue needed to be fixed.

3. First, try to include before any other header. This will automatically prevent futher inclusions of .
So, include . But still icl in VS2010 mode does not compile, and this will be fixed in later release. should never be mistakenly used before , as this would definitely cause problems due to below reason:--

In C language,
MS math.h deprecates usage of some c99-functions.
The issue here is that MS does not support ISO C99.
Also a number of float and long double functions are defined
through calls to corresponding double-precision functions,
giving performance or accuracy loss compared to float/long-double functions
existing in Intel math library.

In C++ language,
MS redefines a number of c99-functions so that they are inlined.

Resolution status:
This issue will be fixed in the later 12.0 release and next major release 12.1.
So, including before explicitly or inadvertently as in sample code will build fine with VS2010 in later 12.x .

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Don't optimize when using -ftrapuv for uninitialized variable detection

Wed, 22 Dec 2010 21:00:00 -0800

Reference Number : dpd200139115, dpd200138937 (documentation).

Version : 2011, (compiler version 12); compiler pro versions 10 and 11

Product : Intel(R) Composer XE; Intel(R) Compiler Pro

Operating System : Windows*, Linux*, Mac OS* X

Problem Description :
If the switch /Qftrapuv (-ftrapuv) for run-time detection of uninitialized local scalar variables is used in conjunction with optimization flags such as /O2 (-O2), it may lead to unexpected floating-point exceptions that are not related to uninitialized variables.

Explanation :
The switch /Qftrapuv (-ftrapuv) sets local, scalar variables that are not otherwise initialized to an "unusual" initial value such as 0xCCCCCCCC. When the main program is compiled with this switch, it also unmasks the "INVALID" floating-point exception. so that exceptions may be raised when the "unusual" values are used in floating-point operations. The switch also changes the default optimization level from /O2 to /Od (from -O2 to -O0). This is so that exceptions will not be raised as a result of speculated floating-point operations or other optimizations. If the new default optimization level of /Od (-O0) is explicitly overridden, optimizations such as floating-point speculation associated with masked vector operations may result in INVALID exceptions that would not otherwise have been raised.

Solution:
Either: Do not override the default /Od (-O0) optimization level when using /Qtrapuv (-ftrapuv). (Sometimes, it may be sufficient to use /Qfp-speculation:safe (-fp-speculation safe) in conjunction with -O2).
or (Fortran only): Use the switch /check:uninit (-check uninit) in preference to /Qtrapuv (-ftrapuv) for the run-time detection of uninitialized, local scalar variables. This uses a different mechanism for uninitialized variable detection that is less likely to produce unrelated floating-point exceptions.

Intel(R) Inspector XE, a component of Intel(R) Parallel Studio XE, may also be used for the detection of some instances of uninitialized variables.

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Errors linking Intel® compilers with Intel® MKL 10.x

Sun, 31 Oct 2010 08:30:00 -0700

Symptoms

When building with Intel® Math Kernel Library for Windows* version 10.0 using the xilink linker from the command line or within the Microsoft Visual Studio* IDE, the following error messages may occur:

Severe: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
Link: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 3)
Link: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 3) or(0): internal error: backend signals
xilink: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 4)
xilink: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 4)

When using the Intel® C++ Compiler for Windows*, these errors have occurred when the /Qipo compiler option is used with the xilink linker from the command line.

When using the Intel® Visual Fortran Compiler for Windows*, these errors have occurred when building within the Visual Studio IDE, which uses the xlink linker.

Solution

Intel® Math Kernel Library for Windows version 10.0 introduced new library naming conventions, with "dummy lib" references to the older Intel® MKL libraries and were given for backward compatibility. However, there is a format problem with the Intel MKL "dummy libs" files that is causing problems for the Intel xilink tool. Correct the problem by modifying link information for the command line or the Visual Studio link information to specify the new names of the 10.0 Intel MKL libraries.

The dummy or compatibility libraries have been removed from Intel® MKL 10.2 or later versions, and if you using one of the latest versions, this error will not occur.

Linking from the Command Line

When link errors occur, correct the problem by replacing references to the Intel MKL dummy libraries on the link command with explicit references to the libraries listed in the dummy libraries. See the explicit Intel MKL library references listed below.

Linking from within Microsoft Visual Studio

In the Visual Studio IDE, replace the references to the dummy libraries in Project » Configuration Properties » Linker &» Input » Additional Dependencies. See the explicit Intel MKL library references listed below.

For IA-32 Compilers

Intel MKL dummy library Replace with explicit Intel MKL library references

mkl_c_dll.lib mkl_intel_c_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib

mkl_s_dll.lib mkl_intel_s_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib

mkl_c.lib mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib

mkl_s.lib mkl_intel_s.lib mkl_intel_thread.lib mkl_core.lib

mkl_scalapack_dll.lib mkl_scalapack_core_dll.lib

mkl_scalapack.lib mkl_scalapack_core.lib

mkl_cdft_dll.lib mkl_cdft_core_dll.lib

mkl_cdft.lib mkl_cdft_core.lib

For Intel® 64 Compilers

Intel MKL dummy library Replace with explicit Intel MKL library references

mkl_dll.lib mkl_intel_lp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib

mkl_em64t.lib mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib.lib

mkl_scalapack_dll.lib mkl_scalapack_lp64_dll.lib

mkl_scalapack.lib mkl_scalapack_lp64.lib

mkl_solver.lib mkl_solver_lp64.lib

mkl_cdft_dll.lib mkl_cdft_core_dll.lib

mkl_cdft.lib mkl_cdft_core.lib

For IA-64 [Intel® Itanium®] Compilers

Intel MKL dummy library Replace with explicit Intel MKL library references

mkl_dll.lib mkl_intel_lp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib

mkl_ipf.lib mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib

mkl_scalapack_dll.lib mkl_scalapack_lp64_dll.lib

mkl_scalapack.lib mkl_scalapack_lp64.lib

mkl_solver.lib mkl_solver_lp64.lib

mkl_cdft_dll.lib mkl_cdft_core_dll.lib

mkl_cdft.lib mkl_cdft_core.lib

Using "DEFINE_GUIDSTRUCT" causes "type name is not allowed" error

Sun, 17 Oct 2010 21:00:00 -0700

Reference Number : DPD200161827

Version : 12.0

Product : Intel(R) C++ Compiler 12.0

Operating System : Windows*

Problem Description : When compiling code that uses DEFINE_GUIDSTRUCT such as the code snippet below, the compiler reports "Error: type name is not allowed" :

switch (_some_type_)   
{   
  case _some_type_foo:   
  {   
    DEFINE_GUIDSTRUCT(__SOME_GUID__STRING__, SOME_TYPE_FOO_PROPSET);   
  #define SOME_TYPE_FOO_PROPSET DEFINE_GUIDNAMED(SOME_TYPE_FOO_PROPSET)   
                _GUID_PROPSET = SOME_TYPE_FOO_PROPSET;   
  }   
  break;   
}

Example:

void f() {
	struct __declspec(uuid("00000000-0000-0000-0000-000000000000")) foo;
}

>icl /c t.cpp
Intel(R) C++ Compiler for applications running on Intel(R) 64, Version 12.0.0.063 Build 20100721
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

t.cpp
t.cpp(2): error: type name is not allowed
struct __declspec(uuid("00000000-0000-0000-0000-000000000000")) foo;
^

compilation aborted for t.cpp (code 2)

Resolution Status : This problem has been resolved in Intel(R) C++ Composer XE update 1 (package ID w_ccompxe_2011.1.127.exe) available for download at registrationcenter.intel.com.

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Value of private variable is undefined inside the simd loop

Sat, 25 Sep 2010 21:00:00 -0700

Reference Number : DPD200160772

Version : 12.0

Product : Intel® C++ Compiler 12.0 for Windows*

Operating System : All versions of Windows* Operating Systems

Problem Description : The value of an initialized simd private variable local to a function is undefined inside the simd loop within the function. In the example below, the value of private variable "x" is undefined (e.g. x = 0 ) instead of 10 if "A[i] != 0" :

void foo(int *A, int *restrict B, int n){
int i;
int x = 10;

#pragma simd private(x)
for (i=0; iif (A[i] > 0) {
x = 20;
}
B[i] = x;
}
}

void foo(int *A, int *restrict B, int n){
  int i;
  int x = 10;

#pragma simd private(x) 
  for (i=0; i 0) {
      x = 20;
    }
    B[i] = x;
  }
}

Resolution Status : This issue is under investigation and may be resolved in a future product update.

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

SIMD loop doesn't vectorize when referencing private variable outside the loop

Sat, 25 Sep 2010 21:00:00 -0700

Reference Number : DPD200160783

Version : 12.0

Product : Intel® C++ Compiler 12.0 for Windows*

Operating System : All versions of Windows* Operating Systems

Problem Description : When referencing a variable with simd "private" attribute, and local to a function outside a simd for-loop inside the function, the compiler will not vectorize the simd loop. Referencing the variable includes assigning its value to another variable or trying to print the value of the private variable. Either of the above conditions will prevent simd vectorization of the loop:

void foo(int *A, int *restrict B, int n){
  int i;
  int x = 10;

#pragma simd private(x) 
  for (i=0; i 0) {
      x = 20;
    }
    B[i] = x;
  }
#ifdef REF
   B[i] = x;
#endif
}

// simd loop vectorizes when "x" is not referenced
>icl -c -Qvec-report2 test.cpp /Qrestrict
Intel(R) C++ Compiler for applications running on Intel(R) 64, Version 12.0.0.063 Build 20100721

test.cpp
D:\NOBACKUP\quadtests\kbarticles\simPrivateBug\test.cpp(6) (col. 3): remark: SIM
D LOOP WAS VECTORIZED.

// simd loop does not vectorize when "x" is referenced outside the loop
>icl -c -Qvec-report2 test.cpp /Qrestrict /DREF
Intel(R) C++ Compiler for applications running on Intel(R) 64, Version 12.0.0.063 Build 20100721

test.cpp
test.cpp(8) (col. 7): remark: loop was not vectorized: conditional assignment to a scalar.
test.cpp(6) (col. 3): warning #13379: loop was not vectorized with "simd"

Resolution Status : This issue is under investigation and may be resolved in a future product update.

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Backend Signals error when compiling code including Intel® Cilk™ Plus headers

Wed, 01 Sep 2010 21:00:00 -0700

Reference Number : DPD200159529

Version : 2011

Product : Intel® Parallel Composer

Operating System : Windows*

Problem Description : When compiling multiple files in a Visual C++ project with the Intel(R) C++ Compiler or compiling multiple files on one command line, you may see a backend signals internal error if the files are using Intel® Cilk™ Plus header files. You can confirm this issue applies to you if you can compile any one source file without seeing the backend signals error.

Resolution Status : Our developers are working towards a fix for this issue. If a workaround is needed, please contact us via User Forum or Intel® Premier Support. This issue does not exist in the Intel® C++ Composer XE.

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]