Thanks for the reply. Its a bit late to sort out the code and options because of the holiday --- we're shut down for a week -- so I'll have to get more detailed code to you in the New Year.
The source code snippet is seriously cut down because its part of a C++ module -- those functions are actually a class's methods. The actual source code looks like this:-
src_enum = SrcEnumReorder[DQLimitSrcEnum];
GetHardwareDependency(src_enum, hwconfig);
if(src_enum == NO_CMD_VALUE_SRC_ENUM)
{
AxisUtil.Status.SetUserCurrentLimitsActive();
}
....but as this would be difficult to compile out of context I translated it into something simple. (The assembler's authentic apart from the name change and a reduction in clutter such as line numbers, generated code and interleave source lines.)
There is a bit of a philosophical 'conversation' about coding styles and tool sets embodied in this. In an ideal world everything would work perfectly but (IMHO) in our real world the chances of a quiet life are greatly enhanced by not pushing the envelope. In this case I think the optimizer is getting confused because it thinks that src_enum is a constant. (Its not immediately obvious to a human whether this is the case or not, either.) So for me the fix would be to restate the code so its absolutely clear -- to both human and compiler) -- what we're trying to do. We also have the fallback of just reducing the optimization level as a near term Band-Aid. A compiler fix -- if one is warranted -- would be welcome but it begs the question of provability; it might work in this case but what about similar cases (and has it broken anything?). So in our workplace we have two camps -- one would suggest that recoding to avoid the problem might be the way to go, the other says that the code is correct per the relevant standard and expects the compiler to work properly. Who's right?