Community
cancel
Showing results for 
Search instead for 
Did you mean: 
katana_
Beginner
209 Views

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

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.
0 Kudos
12 Replies
TimP
Black Belt
209 Views

$ 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_
Beginner
209 Views

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
New Contributor I
209 Views

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_
Beginner
209 Views

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
Black Belt
209 Views


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
Black Belt
209 Views

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_
Beginner
209 Views


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_
Beginner
209 Views

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
Employee
209 Views

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
Employee
209 Views

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
Employee
209 Views

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

209 Views

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

Alex
Reply