Bug report -- initialization of arrays to pointers of arrays fails randomly

[katana_]

I found a way to initialize an array of pointers to arrays of integers (or double, shorts, etc. ) that compiles and works with
gnu c++ but not with the intel one.
The code example looks like this:

[cpp]#include 
using namespace std;

static const int *a[] = {
  (int[]) { 0 } ,
  (int[]) { 1 , 2 } ,
  (int[]) { 3 , 4 , 5 } ,
  (int[]) { 6 , 7 , 8 , 9 }
};

main()
{
  cout
  << a[0][0] << endl
  << a[1][0] << " " << a[1][1] << endl
  << a[2][0] << " " << a[2][1] << " " << a[2][2] << endl
  << a[3][0] << " " << a[3][1] << " " << a[3][2] << " " << a[3][3] << endl;
}[/cpp]

Compiling and running with g++ gives the following result:

[plain]0
1 2
3 4 5
6 7 8 9[/plain]

Compiling and running with icpc gives the following result:

[plain]0
1 1
40896 32767 -961756724
0 32767 4198878 0[/plain]

Whereas the first to numbers ar always right, the rest is changing randomly.
Interestingly the program seems to work sometimes if I use zeros instead of 6,7,8,9.

I dont't really have an explanation for it, especially the depedence of the used values is really weird.

[TimP]

$ g++ -pedantic kat.cpp
kat.cpp:5:15: warning: ISO C++ forbids compound-literals
kat.cpp:6:19: warning: ISO C++ forbids compound-literals
kat.cpp:7:23: warning: ISO C++ forbids compound-literals
kat.cpp:8:27: warning: ISO C++ forbids compound-literals
kat.cpp:11:6: warning: ISO C++ forbids declaration of `main' with no type

My current copy of Intel C++ refuses to compile it.

I was interested to see that a C99/C++ compiler has a special flag to accept gcc compound literals and other gcc extensions:
http://www.comeaucomputing.com/4.3.0/minor/linux/compat.html
So this is a gcc extension which Intel C++ doesn't support. If you're interested, you could file a report on your premier.intel.com account to ask whether this should be covered in the general gcc compatibility category.

[katana_]

Quoting - tim18

$ g++ -pedantic kat.cpp
kat.cpp:5:15: warning: ISO C++ forbids compound-literals
kat.cpp:6:19: warning: ISO C++ forbids compound-literals
kat.cpp:7:23: warning: ISO C++ forbids compound-literals
kat.cpp:8:27: warning: ISO C++ forbids compound-literals
kat.cpp:11:6: warning: ISO C++ forbids declaration of `main' with no type

My current copy of Intel C++ refuses to compile it.

I was interested to see that a C99/C++ compiler has a special flag to accept gcc compound literals and other gcc extensions:
http://www.comeaucomputing.com/4.3.0/minor/linux/compat.html
So this is a gcc extension which Intel C++ doesn't support. If you're interested, you could file a report on your premier.intel.com account to ask whether this should be covered in the general gcc compatibility category.

If I compile with

[cpp]icpc -O0 -strict-ansi -w2 -Wall prog.cpp[/cpp]

I do not get any error or warnings (I inserted and int-return type to main). So everything seems to be ok for icpc (I have version 11.1). My output is now at least constantly:

[shell]0
1 2
6296672 0 6296672
6296672 0 6296672 0
[/shell]

What Version of icpc did you use and what was the error you got?

[aazue]

Quoting - katana.

If I compile with

[cpp]icpc -O0 -strict-ansi -w2 -Wall prog.cpp[/cpp]

I do not get any error or warnings (I inserted and int-return type to main). So everything seems to be ok for icpc (I have version 11.1). My output is now at least constantly:

[shell]0
1 2
6296672 0 6296672
6296672 0 6296672 0
[/shell]

What Version of icpc did you use and what was the error you got?

Hi katana

You have same result with g++ ?

#include
using namespace std;

static const int *a[] = {
(int[]) { 0 } ,
(int[]) { 1 , 2 } ,
(int[]) { 3 , 4 , 5 } ,
(int[]) { 6 , 7 , 8 , 9 }
};

int main()
{
for( int i=0;i<=2;i++)
{
cout
<< a[0][0] << endl
<< a[1][0] << " " << a[1][1] << endl
<< a[2][0] << " " << a[2][1] << " " << a[2][2] << endl
<< a[3][0] << " " << a[3][1] << " " << a[3][2] << " " << a[3][3] << endl;
}
}


(g++ tab1.cc -o tab1)
0
1 2
3 4 5
6 7 8 9
-1840614880
-1840614880 32614
6295553 0 6295648
7 0 9 0
-1840614880
-1840614880 32614
6295553 0 6295648
0 0 0 0

Kind regards

[katana_]

Quoting - bustaf

Hi katana

You have same result with g++ ?

No, in y initial post I described what I see. g++ behaves as expected, intel gives strange output.

g++ gives at least some warnings of not being conform to some standard, which I don't really understand.

Intel does not give any warnings or errors (with everything switched on), compiles, and doesn't work.

What I would expect: Either it refuses to compile and gives an appropriate error message or it compiles and works.

[jimdempseyatthecove]

What happens when you insert

#pragma pack(1)
__declspec(align(1))
const int* a[]={
...

in front of the declaration of a?

If that doesn't work then try the pack/align to sizeof(int) (4) and sizeof(intptr_t) (4 or 8)

IOW force the alignment to do what you expect it to do.

Jim Dempsey

[TimP]

It is strange that ICL for Windows rejects your example, while icpc for linux provides no warning. Perhaps you might consider this inconsistency worthy of a bug report, if you don't want to file one asking whether consistency with g++ should be supported.

[katana_]

Quoting - jimdempseyatthecove

What happens when you insert

#pragma pack(1)
__declspec(align(1))
const int* a[]={
...

in front of the declaration of a?

If that doesn't work then try the pack/align to sizeof(int) (4) and sizeof(intptr_t) (4 or 8)

IOW force the alignment to do what you expect it to do.

Jim Dempsey

Nothing changes.

[katana_]

Quoting - tim18

It is strange that ICL for Windows rejects your example, while icpc for linux provides no warning. Perhaps you might consider this inconsistency worthy of a bug report, if you don't want to file one asking whether consistency with g++ should be supported.

Ok, you were trying it under windows? What was the error message you got.

Your are right, maybe I should file a bug report.

[JD_Patel]

Quoting - katana.

Your are right, maybe I should file a bug report.

Hi Katana,

Did you file a bug report for this issue?

Thanks...

[Judith_W_Intel]

Quoting - tim18

It is strange that ICL for Windows rejects your example, while icpc for linux provides no warning. Perhaps you might consider this inconsistency worthy of a bug report, if you don't want to file one asking whether consistency with g++ should be supported.

The code uses a C99 feature called compound literals. Since our compiler on Windows is meant to be compatible with the Microsoft compiler we don't support them in C++ on Windows (just like the Microsoft compiler). So the fact that we are inconsistent between the two platforms is intentional and not worthy of a bug report.

However the fact that we are doing something wrong in g++ mode when we representthese is definitely a bug and worthy of a bug report...

[Dale_S_Intel]

Quoting - Judith Ward (Intel)

However the fact that we are doing something wrong in g++ mode when we representthese is definitely a bug and worthy of a bug report...

I've submitted a report on this issue.

Dale

[Alexander_W_Intel]

The issue is fixed and will be available in the upcoming update of Intel Composer XE 2011.

Alex