Support for array in icpc 12.1.5

[drMikeT]

Hello,

I am trying to compile a simple C++ 0x program using the icpc 12.1.5 Intel compiler as:

icpc -std=c++0x tt.cc

where, tt.cc :

1. //array::at
2. #include
3. #include
5. intmain()
6. {
7. unsignedinti;
8. std::arraymyarray;
10. //assignsomevalues:
11. for(i=0;i<10;i++)myarray.at(i)=i+1;
13. //printcontent
14. std::cout<<"myarraycontains:";
15. for(i=0;i<10;i++)
16. std::cout<<""<
18. std::cout<<:ENDL>
20. return0;
21. }

but Iam getting:

tt.cc(3): catastrophic error: cannot open source file "array"
#include
^
Is "array" NOT supported by icpc 12.1 yet ?

thanks
michael

[JenniferJ]

should be part of the gcc. icpc uses the header files from gcc.

looks like you just need to set the correct env, it should then work. the release notes contains some info. below is copied from Release Notes:

The command takes the form:

source /bin/compilervars.sh argument

Where argument is either ia32 or intel64 as appropriate for the architecture you are building for.

[drMikeT]

Quoting Jennifer Jiang (Intel)

should be part of the gcc. icpc uses the header files from gcc.

looks like you just need to set the correct env, it should then work. the release notes contains some info. below is copied from Release Notes:

The command takes the form:

source /bin/compilervars.sh argument

Where argument is either ia32 or intel64 as appropriate for the architecture you are building for.

Thanks for the reply. On the target system which is a RHEL 5.4 (GCC 4.1.2) after I
. /g/software/intelXE/bin/compilervars.sh intel64

I still get

$ icpc -std=c++0x test.cc
test.cc(2): catastrophic error: cannot open source file "array"
#include
^

compilation aborted for test.cc (code 4)




I then checked on my Ubuntu12.04 machine (with GCC 4.6.3 headers) and I get :


$ icpc -std=c++0x tt.cc
Warning #2928: the __GXX_EXPERIMENTAL_CXX0X__ macro is disabled when using GNU version 4.6 with the c++0x option

/usr/include/c++/4.6/bits/c++0x_warning.h(32): catastrophic error: #error directive: This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
#error This file requires compiler and library support for the upcoming \
^

compilation aborted for tt.cc (code 4)

which makes me tend to think that GCC 4.1.2 may not support of c++0x at all ?

regards
Mike

[JenniferJ]

Can "g++" compile ?

$ g++ -std=c++0x tt.cc

Jennifer

[drMikeT]

Quoting Jennifer Jiang (Intel)

Can "g++" compile ?

$ g++ -std=c++0x tt.cc

Jennifer

On my RHEL 5.4 host (gnu 4.1.2) unfortunately :

$ g++ -std=gnu++98 test.cc
test.cc:2:17: error: array: No such file or directory
test.cc: In function int main():
test.cc:6: error: array was not declared in this scope
test.cc:6: error: expected primary-expression before int
test.cc:6: error: expected `;' before int
test.cc:6: error: p was not declared in this scope

where -std=gnu++98 is the most recent C++ standard it conforms to.


On My Ubuntu 12.4 (GNU 4.6.3)

$ g++ -std=gnu++0x tt.cc
$
no complaints ..

I wish I could avoid it but guess I will have to open an case with support and see what is the official party position on Intel 12.1 vs GCC 4.1.2 vs 0x

thanks for the prompt replies ....

[TimP]

Part of the answer appears to be that you must install a g++ which supports the features you want to use in icpc, since icpc relies on the headers and libraries furnished by g++.
g++ 4.1 apparently doesn't support the features you want, aside from being obsolete. Most current linux distros have at least an option to install a pre-built g++ 4.4 or newer, or you can build g++ from source. icpc 12.1 generally works with g++ up to 4.6. icpc 13.0 (full release by year end) extends to support of g++ 4.7 (and may work with 4.8).

[SergeyKostrov]

Hi Mike,

Quoting drMikeT

...I still get

$ icpc -std=c++0x test.cc
test.cc(2): catastrophic error: cannot open source file "array"
#include
^

compilation aborted for test.cc (code 4)
...
which makes me tend to think that GCC 4.1.2 may not support of c++0x at all ?

Please take a look atthe message I 'bolded'andit clearly says "cannot open source file...".

Search for 'array' source file on your systems and ifyoudon't find it at some'..\Include' folder(s)it means that C++ compilers
simply don't have it, or don't support it.

Best regards,
Sergey

[bernaske]

Hi, now i have your sample recompile with your same options under openSUSE 12.2 Beta2 64 Bit Linux with
the Intel Paraller Studio XE 2013 Beta
no problems, no error message.

[drMikeT]

Hi TimP, the environment is a cluster where upgrades to latest OS (current OS is RHEL 5.4) are frowned upon. Since the kernel + sys/other utilities were built with GCC 4.1.2 this environment cannot be removed.

I will try to see how to make Intel C/C++ use a GCC different from the system one and if there are other untoward consequences.

That was interesting exchange.

mike

[drMikeT]

Hi Sergey, thanks for the reply.


yes I've already used 'find' in the header's directory and I couldn't find it in RHEL 5.4 which is the system in question. I think the overall issue is that GCC 4.1.2 (useds to build current kernel) goes up to c++98 compliance. I will examine posibility of adding newer GCC environment.

take care
mike

[drMikeT]

Thanks for the note. The issue most likely is the obsolete headers of GCC 4.1.2 which came with the kernel and is backwards in recent C++ features.

mike

[TimP]

Certainly, you have reasons for avoiding a mixture of different distro levels across a cluster. If you build an application with a newer major version of g++ than the one which is installed across the cluster, you may want to have the g++ built against the chosen OS, and you will likely need to mount or distribute the libraries which come with g++ in a specific library path visible across the cluster as well as on the build machine.

[SergeyKostrov]

Quoting Jennifer Jiang (Intel)

should be part of the gcc...

It depends on a version and Mike already confirmed (in one of his later posts )thatGCC 4.1.2 doesn't have it.

Best regards,
Sergey