优化switch语句时Visual Studio 2005 C编译器问题

Question

General Question which may be of interest to others:

I ran into a, what I believe, C++-compiler optimization (Visual Studio 2005) problem with a switch statement. What I'd want to know is if there is any way to satisfy my curiosity and find out what the compiler is trying to but failing to do. Is there any log I can spend some time (probably too much time) deciphering?

My specific problem for those curious enough to continue reading - I'd like to hear your thoughts on why I get problems in this specific case.

I've got a tiny program with about 500 lines of code containing a switch statement. Some of its cases contain some assignment of pointers.

double *ptx, *pty, *ptz;
double **ppt = new double*[3];

//some code initializing etc ptx, pty and ptz 

ppt[0]=ptx;
ppt[1]=pty; //<----- this statement causes problems
ppt[2]=ptz;

The middle statement seems to hang the compiler. The compilation never ends. OK, I didn't wait for longer than it took to walk down the hall, talk to some people, get a cup of coffee and return to my desk, but this is a tiny program which usually compiles in less than a second. Remove a single line (the one indicated in the code above) and the problem goes away, as it also does when removing the optimization (on the whole program or using #pragma on the function).

Why does this middle line cause a problem? The compilers optimizer doesn't like pty. There is no difference in the vectors ptx, pty, and ptz in the program. Everything I do to pty I do to ptx and ptz. I tried swapping their positions in ppt, but pty was still the line causing a problem.

I'm asking about this because I'm curious about what is happening. The code is rewritten and is working fine.

Edit: Almost two weeks later, I check out the closest version to the code I described above and I can't edit it back to make it crash. This is really annoying, embarrassing and irritating. I'll give it another try, but if I don't get it breaking anytime soon I guess this part of the question is obsolete and I'll remove it. Really sorry for taking your time.

Answer 1

If you need to make this code compilable without changing it too much consider using memcpy where you assign a value to ppt[1] . This should at least compile fine. However, you problem seems more like another part of the source code causes this behaviour.

What you can also try is to put this stuff:

ppt[0]=ptx;
ppt[1]=pty; //<----- this statement causes problems
ppt[2]=ptz;

in another function. This should also help compiler a bit to avoid the path it is taking to compile your code.

Answer 2

Did you try renaming pty to something else (ie pt_y)? I encountered a couple of times (ie with a variable "rect2") the problem that some names seem to be "reserved".

Answer 3

It sounds like a compiler bug. Have you tried re-ordering the lines? eg,

ppt[1]=pty; 
ppt[0]=ptx;
ppt[2]=ptz;

Also what happens if you juggle about the values that are assigned (which will introduce bugs in your code, but may indicator whether its the pointer or the array that's the issue), eg:

ppt[0] = pty;
ppt[1] = ptz;
ppt[2] = ptx;

(or similar).

Answer 4

It's probably due to your declaration of ptx, pty and ptz with them being optimised out to use the same address. Then this action is causing your compiler problems later in your code.

Try

static double *ptx;
static double *pty;
static double *ptz;