Threads, as they sit today in most languages are a pain to get right no matter what.

wonderful…

Yes I did.

>>I’m tempted to write a code snippet and see what some standard compilers do in this scenario - have you already done this?

I tested it only with Intel C++ Compiler and it crashes so I submitted an issue with Intel Premier Support to get some clarification and so far I haven’t got anything except the confirmation that they have reproduced it.

Let me save you some effort, here is the code snippet I used:

#include

#define ALIGN __declspec(align(16))

void zealot(void)
{
ALIGN volatile float wkr[4096]; // 16384 bytes
ALIGN volatile float wki[4096]; // 16384 bytes
ALIGN volatile float ak0[4096]; // 16384 bytes
ALIGN volatile float ak1[4096]; // 16384 bytes

__asm {
xor eax, eax
mov edx, 16384
lea esi, wkr // reference wkr
lea edi, ak0 // reference ak0
mov dword ptr [1024 + edi + edx], eax // ak1[256] = 0
}
}

int main(void)
{
zealot();
printf(”I am not a zealot!\n”);
return 0;
}

Arrays wki and ak1 get optimized away because there is no explicit reference in the inline assembler block.

In my opinion the original C/C++ standard is too vague on the volatile keyword definition. They do say that the compiler should not optimize if it is not sure that the variable cannot be changed from the outside but in this case “outside” really should mean “outside of the compiler generated code”, not “outside of the function”.

Have you observed a compiler optimizing away such a variable and resulting in a crash? I’m tempted to write a code snippet and see what some standard compilers do in this scenario - have you already done this?

It is clear that in such case optimizing the variable away would lead to a program crash because of a stack overflow.

I just checked C++ Standard draft and it is pretty unclear on that. I believe that there should be a way to tell the compiler “do not optimize away unreferenced local variables”.

What do you think?