ShadowM: Please give this build a shot:
http://valera-ext.ny...CompilerDll.ndl
There were several problems here.
1) There was a longstanding bug in the compiler (also in the PRC builds) where, in the event that a global variable was assigned to during global variable initialization but never written to afterwards, it would be promoted into a 'constant expression' even if the assignment included a function call. The 'constant expression' was then inlined every time the global was referenced. This behavior was erroneous as replicating the function call changes program behavior and can in some cases lead to stack mismanagement (which was the original issue ShadowM reported). This issue only occurred if optimizations were enabled.
2) There was a seperate longstanding and very subtle bug in the compiler (also in the PRC builds) where assigments to global variables during global variable initialization would use an incorrect stack offset in the event where the global variable initialization expression referenced another global variable, and the initialization expression was of the optimized form (enabled if optimizations are turned on) and not the 'traditional' form used by the BioWare compiler. The issue occurred because the compiler was not correctly taking into account that, while traditional initialization results in storage space for the variable being reserved at the start of the initialization expression, optimized initialization results in storage space for the variable being reserved at the end of the initialization expression. As a result, references to globals during optimized global initialization would read the wrong global. This bug was hidden by the fact that, due to the global constant expression optimization issue, most of the global references that would be impacted were being inlined out of #globals.
3) There was an additional separate longstanding bug in the compiler (also in the PRC builds) where assignments of a variable to itself during initialization would not work correctly if a constant or global was involved. This was also partially hidden (in some cases) by the global constant expression optimization bug.
I've made the following code generation changes to fix these problems:
- The compiler scans the initialization expressions of all globals to determine whether a function call, action service handler call, or internal compiler intrinsic call is present before permitting promotion of the global to a constant expression. This fixes the issue with globals that involved function calls causing the function call to be improperly replicated to each call site if optimizations were enabled.
- When processing a global variable initializer, the compiler now correctly takes into account whether storage space for the global variable on the execution stack is logically allocated at the start of the expression or at the end of the expression. This fixes the problem with global initializers that referenced other global variables working improperly if optimizations were enabled (and the global wasn't treated as a constant expression).
- When processing a variable initializer expression where the variable being initialized is referenced within the expression itself, the initializer expression is forced to the traditional, non-optimized form so that stack space for the variable is available throughout the expression. This allows operators that operate on the variable to work correctly even if optimizations were turned on.
Additionally, the compiler previously did not allow default initialization for some esoteric corner cases such as "struct mystruc global1 = global1;" that the BioWare compiler permits (though not particularly usefully); these are now allowed.
Modifié par SkywingvL, 26 juin 2011 - 04:38 .
