mersenneforum.org Help! Compiler bug
 Register FAQ Search Today's Posts Mark Forums Read

 2010-10-01, 00:36 #1 R.D. Silverman     Nov 2003 22×5×373 Posts Help! Compiler bug Here is a code snippet: Code: 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.
2010-10-01, 00:39   #2
R.D. Silverman

Nov 2003

22·5·373 Posts

Quote:
 Originally Posted by R.D. Silverman Here is a code snippet: Code: 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.

2010-10-01, 00:54   #3
R.D. Silverman

Nov 2003

22·5·373 Posts

Quote:
 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.

 2010-10-01, 01:32 #4 alpertron     Aug 2002 Buenos Aires, Argentina 22×3×5×23 Posts 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.
 2010-10-01, 01:34 #5 Robert Holmes     Oct 2007 2×53 Posts 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 Code: __asm { nop } The compiler should be forced to separate the function before and after the assembly block, and that might work around the bug. Last fiddled with by Robert Holmes on 2010-10-01 at 01:35
2010-10-01, 01:44   #6
paulunderwood

Sep 2002
Database er0rr

17·227 Posts

Code:
void prepare_bounds(v1, v2, sign)
int v1[2], v2[2], sign;
Quote:
 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

Last fiddled with by paulunderwood on 2010-10-01 at 01:49

2010-10-01, 02:44   #7
R.D. Silverman

Nov 2003

22×5×373 Posts

Quote:
 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.

Quote:
 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.

2010-10-01, 02:45   #8
R.D. Silverman

Nov 2003

22·5·373 Posts

Quote:
 Originally Posted by paulunderwood Code: 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.

2010-10-01, 11:35   #9
alpertron

Aug 2002
Buenos Aires, Argentina

22·3·5·23 Posts

Quote:
 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.

2010-10-01, 11:45   #10
R.D. Silverman

Nov 2003

22·5·373 Posts

Quote:
 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.

2010-10-01, 23:22   #11
R.D. Silverman

Nov 2003

22×5×373 Posts

Quote:
 Originally Posted by R.D. Silverman Here is a code snippet: Code: 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?

 Similar Threads Thread Thread Starter Forum Replies Last Post Explorer09 Software 1 2017-01-23 02:50 Dubslow Programming 2 2016-02-27 06:55 ixfd64 Software 7 2011-02-25 20:05 geoff Programming 3 2007-09-26 03:09 tha Hardware 17 2005-10-12 08:10

All times are UTC. The time now is 16:26.

Mon Oct 18 16:26:23 UTC 2021 up 87 days, 10:55, 0 users, load averages: 2.09, 1.57, 1.45