Re: New VSI blog post

On 7/29/2024 7:44 PM, Arne Vajhøj wrote:

For those that have not seen it:
 https://vmssoftware.com/resources/blog/2024-07-26-rtl8/
 (Darya is listed as author, John Reagan is quoted in it)
 Content is a rather unusual mix of:
* some business/admin stuff
     - 8.4-2L1 going out of standard support in December
       so time to update to 8.4-2L3
     - a warning about known issues in C RTL 8 and a suggestion
       to wait for C RTL 9
* some programming notes about problems related to:
     - use of uninitialized variables
     - mismatch between 32 and 64 bit
 Arne
 

Yeah, we've been trying to balance changes to the CRTL that:
1) Increases our POSIX and open-source compatibility
2) Doesn't break legacy code that relies on existing behavior
3) Doesn't add any new CRTL feature logicals
We are planning additional CRTL work that will enable using
clang in "C-mode" to get C11 (and perhaps some of C18) support.  Also, newer C++ standards support in LIBCXX expects some of those C11 features as well.  The dependencies can be twisty.
And in lieu of an actual porting guide, I've been asked about "what things are catching people porting code from Itanium to x86".  Other than bugs in the compilers and OS, the most common issue I've seen is a mismatch of 32/64 bit variables.  I've seen 20 or so instance of code that is doing a 64-bit write into a 32-bit variable.  On Alpha and Itanium, GEM would allocate 32-bit variables into their own quadword on the stack.  Back in the old Alpha days, quadword granularity was very important.  It became less important on later Alphas and Itanium but still had limited benefit.  For x86, there is no reason for it and LLVM will just allocate 32-bit variables on the stack right next to each other.  The overwrite on Alpha/Itanium would just touch that extra alignment hole.  On x86, the overwrite clobbers the adjacent variable. It mostly has been in BLISS and C code.