Help! Compiler bug

[R.D. Silverman]

Here is a code snippet:

void prepare_bounds(v1, v2, sign)
int v1[2], v2[2], sign;

{   /* start of prepare_bounds */

double m_over_a1, n_over_b1, b0_over_b1, a0_over_a1;
double a0, a1, b0, b1, one_over_a1, one_over_b1;
double l1and4, l2and3, l1and3, determ, inv_determ;
double stime;
double temp;


temp = get_time();
if (TIME_STATS) stime = get_time();
printf("1");
a0 = (double)v1[0];
a1 = (double)v2[0];
b0 = (double)v1[1];
b1 = (double)v2[1];
printf("2");

I am trying to produce a release (i.e. non-debug) executable for my siever
using Visual Studio 2010.

As written exactly above the code runs just fine.

If I delete the "printf("1");" statement, the code core dumps before
hitting printf("2");

If I delete the calls to get_time(), the code runs fine.

This seems to be the same compiler bug that I saw with VS 2008.
Apparently, the code is doing a register mis-allocation involving the call
to get_time. Adding the printf("1") statement seems to make the problem
go bye-bye.....

This is a total mystery.

Comments would be GREATLY appreciated.

[R.D. Silverman]

Originally Posted by R.D. Silverman

Here is a code snippet:

void prepare_bounds(v1, v2, sign)
int v1[2], v2[2], sign;

{   /* start of prepare_bounds */

double m_over_a1, n_over_b1, b0_over_b1, a0_over_a1;
double a0, a1, b0, b1, one_over_a1, one_over_b1;
double l1and4, l2and3, l1and3, determ, inv_determ;
double stime;
double temp;


temp = get_time();
if (TIME_STATS) stime = get_time();
printf("1");
a0 = (double)v1[0];
a1 = (double)v2[0];
b0 = (double)v1[1];
b1 = (double)v2[1];
printf("2");

I am trying to produce a release (i.e. non-debug) executable for my siever
using Visual Studio 2010.

As written exactly above the code runs just fine.

If I delete the "printf("1");" statement, the code core dumps before
hitting printf("2");

If I delete the calls to get_time(), the code runs fine.

This seems to be the same compiler bug that I saw with VS 2008.
Apparently, the code is doing a register mis-allocation involving the call
to get_time. Adding the printf("1") statement seems to make the problem
go bye-bye.....

This is a total mystery.

Comments would be GREATLY appreciated.

I forgot to mention. If I produce a debug version, even without the
printf statements, the code runs fine. It also runs fine without the
printf's when compiled with Visual C++ 5.0 and Visual C++ 6.0

WTF is going on here????

It is only when I produce a RELEASE version under Vs2010 that the code
barfs.

[R.D. Silverman]

Originally Posted by R.D. Silverman

I forgot to mention. If I produce a debug version, even without the
printf statements, the code runs fine. It also runs fine without the
printf's when compiled with Visual C++ 5.0 and Visual C++ 6.0

WTF is going on here????

It is only when I produce a RELEASE version under Vs2010 that the code
barfs.

One final piece of information. get_time() is called in MANY places throughout
the code. It only barfs within this little piece of code.

[alpertron]

Are you compiling in 32-bit mode? Notice that there are some differences in 64 bits so if you for example cast pointers which are 64 bits long to integer (32 bits) and then you try to use them again as pointers, it will fail.

It is possible that before entering that function the heap and/or the stack were corrupted, so the function get_time() just triggers the error that was already present.

[Robert Holmes]

That's a weird problem.

I assume this is being compiled in 32-bit mode. Instead of printf("1"), try putting an inline asm block that does nothing, like

__asm { nop }

The compiler should be forced to separate the function before and after the assembly block, and that might work around the bug.

[paulunderwood]

void prepare_bounds(v1, v2, sign)
int v1[2], v2[2], sign;

Originally Posted by R.D. Silverman

WTF is going on here????

http://msdn.microsoft.com/en-us/library/efx873ys.aspx

Looks like you function variable declarations/definitions are old school

[R.D. Silverman]

Originally Posted by alpertron

Are you compiling in 32-bit mode? Notice that there are some differences in 64 bits so if you for example cast pointers which are 64 bits long to integer (32 bits) and then you try to use them again as pointers, it will fail.

There are no 64 bit pointers in the code.

It is possible that before entering that function the heap and/or the stack were corrupted, so the function get_time() just triggers the error that was already present.

This does not explain why adding a printf fixes the problem.

This is a register misallocation. Adding the printf causes the compiler to use
its registers differently.

[R.D. Silverman]

Originally Posted by paulunderwood

void prepare_bounds(v1, v2, sign)
int v1[2], v2[2], sign;

http://msdn.microsoft.com/en-us/library/efx873ys.aspx

Looks like you function variable declarations/definitions are old school

Irrelevant.

[alpertron]

Originally Posted by R.D. Silverman

There are no 64 bit pointers in the code.

This does not explain why adding a printf fixes the problem.

This is a register misallocation. Adding the printf causes the compiler to use
its registers differently.

Maybe it is a problem on the optimization stage. I suggest you to change the project in order to add debugging information in the RELEASE version, and then run your program until the function is reached. Then run it step by step in the disassembler window. You can see in this way whether the function was compiled correctly or not.

[R.D. Silverman]

Originally Posted by alpertron

Maybe it is a problem on the optimization stage. I suggest you to change the project in order to add debugging information in the RELEASE version, and then run your program until the function is reached. Then run it step by step in the disassembler window. You can see in this way whether the function was compiled correctly or not.

Instead, I am just going to kick out the assembler code and look at it.

[R.D. Silverman]

Originally Posted by R.D. Silverman

Here is a code snippet:

void prepare_bounds(v1, v2, sign)
int v1[2], v2[2], sign;

{   /* start of prepare_bounds */

double m_over_a1, n_over_b1, b0_over_b1, a0_over_a1;
double a0, a1, b0, b1, one_over_a1, one_over_b1;
double l1and4, l2and3, l1and3, determ, inv_determ;
double stime;
double temp;


temp = get_time();
if (TIME_STATS) stime = get_time();
printf("1");
a0 = (double)v1[0];
a1 = (double)v2[0];
b0 = (double)v1[1];
b1 = (double)v2[1];
printf("2");

I am trying to produce a release (i.e. non-debug) executable for my siever
using Visual Studio 2010.

As written exactly above the code runs just fine.

If I delete the "printf("1");" statement, the code core dumps before
hitting printf("2");

If I delete the calls to get_time(), the code runs fine.

This seems to be the same compiler bug that I saw with VS 2008.
Apparently, the code is doing a register mis-allocation involving the call
to get_time. Adding the printf("1") statement seems to make the problem
go bye-bye.....

This is a total mystery.

Comments would be GREATLY appreciated.

More weirdness. If I replace printf("1") with do_nothing("1") where
do_nothing is just a dummy routine the code STILL fails.

How can the addition of a printf of a static string cure a core dump
caused by a read access failure?