Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

problems running a 64bits program

Roger_Clavera_Gisper
691 Views
Hi all,

I compiled a program wrote in C using Intel Compiler C 11.1.069 under 32 and 64 bits with Opensuse 11.2.


It runs perfectly under 32 bits, but when it runs under 64 bits when initialize variables appears "segment violation".

The compiler has defined the next includes:
/opt/intel/Compiler/11.1/069/include
/opt/intel/Compiler/11.1/069/include/intel64
/usr/include
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/4.4/include


The program uses:
#include
#include
#include
#include
#include
#include

and the pointer that has problem is:

....
....
int **nSwitch;
....
...
nSwitch=(int **)malloc((nti+1)*sizeof(int));
for (i=0; i<=nti; i++)
{
nSwitch=(int *)malloc(6*sizeof(int));
}

....
....

for (i=1; i<=nti; i++)
{
for (j=1; j<=5; j++)
{
nSwitch=0;
}
}

....
....


I have no idea how to solve it.
0 Kudos
5 Replies
TimP
Honored Contributor III
691 Views
The excerpts you show aren't C. Compiler warnings might be more meaningful if you would change it to C. Even if you did write C, the Intel C++ forum might work better, if you have questions about icc.
0 Kudos
Roger_Clavera_Gisper
691 Views
Thanks you for your reply,

finally I found the problem. I changed the next line:

....
...
nSwitch=(int **)malloc((nti+1)*sizeof(int));

....
....


by:

....
...
nSwitch=(int **)malloc((nti+1)*sizeof(int*));

....
....


And now it works perfectly
0 Kudos
plus2plus
Beginner
691 Views
So this topic has gone for tutorial for new beginner. Thanks.
0 Kudos
mecej4
Honored Contributor III
691 Views
That the change from 'sizeof(int)' to 'sizeof(int *)' was all that was needed shows that the original program was written with the implicit assumption that integers and pointers had the same size. That assumption would be correct under (i) 16 bit MSDOS (ii) most versions of 32 bit Windows, Linux, Unix but not Linux-X64. It may be good to check what assumptions the program made regarding the sizes of 'int' and 'long'.
0 Kudos
jose-maria-gomez-ver
691 Views
If you want to avoid nightmare porting from 32 to 64 bits you shouldn't use build-in type directily. What I usually do is to create a Class with my types like this:

class Types
{
public:
#ifdef WIN32
typedef unsigned __int64 uint64_t;
typedef signed __int64 int64_t;
#else
typedef unsigned long long uint64_t;
typedef signed long long int64_t;
#endif

typedef unsigned char uint8_t;
typedef signed char int8_t;
typedef unsigned short int uint16_t;
typedef signed short int int16_t;
typedef unsigned int uint32_t;
typedef signed int int32_t;


typedef uint32_t tag_t;
typedef tag_t moduleTag_t;
typedef tag_t fieldTag_t;
typedef uint32_t lenght_t;
typedef uint8_t* buffer_t;

static void CheckTypes();
Types(void);
~Types(void);
};

And in the constructor, you can check that everything is like you belive, it not, change the class to adapt.

void Types::Types()
{
assert(1 == sizeof(uint8_t));
assert(1 == sizeof(int8_t));

assert(2 == sizeof(uint16_t));
assert(2 == sizeof(int16_t));

assert(4 == sizeof(uint32_t));
assert(4 == sizeof(int32_t));

assert(8 == sizeof(uint64_t));
assert(8 == sizeof(int64_t));
}

Of course you will need to change or add more check for you machine.

I hope this to be useful for you.
0 Kudos
Reply