Problems with Release build after upgrade of VS2019

jung kreidler

Hi all, This code in the first loop worked up to now:

unsigned char szin\[200\] = { 0 };
unsigned char szarr\[50\] = { "blah1blah2blah3blah4" };
unsigned char\* pchar;

pchar = &szarr\[0\];
for (int i = KEYSIZE / 2; i < KEYSIZE; i++)// Transfer random bytes to second half of in
  szin\[i\] = \*(pchar++);  // This worked up to now. After update nothing is copied

pchar = &szarr\[2\];
int jj = 0;
for (int i = KEYSIZE / 2; i < KEYSIZE; i++)// Transfer random bytes to second half of in
{
  szin\[i\] = pchar\[jj\]; // This is my current workaround
  jj++;
}

Obviously MS changed something in the compiler, which breaks the release build. Debug still works. Any glue? Regards, Franz

Lost User

The only way to find out is by debugging the code. Add some print/log statements to the first loop to display the index values, and the array addresses as the code runs. It's not very likely that the compiler is broken. Also, you are using hard coded numbers for your array sizes, but a define value (KEYSIZE) for the loop. This is dangerous as changing one without the other can lead to difficult to find bugs. Use KEYSIZE for all so it is consistent.

jung kreidler

Just sample code to show the problem, so no problem with array sizes. The code works ok when compiling in VS2013 and it worked up to VS2019 16.5.1. I made a console sample using the code and compiled it with VS2013 and VS2019. The output is different when printing the arrays. In case I switch off optimization it works ok, too.

// ConsoleApplication2.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#define KEYSIZE 35
int _tmain(int argc, _TCHAR* argv[])
{
unsigned char szin[2 * KEYSIZE] = {"--------------------------------------------------------------------"};
unsigned char szin2[2 * KEYSIZE] = {"--------------------------------------------------------------------"};
unsigned char szarr[2 * KEYSIZE] = {"blah1blah2blah3blah4blah5blah6blah7blah8blah9blah10blah11"};
unsigned char* pchar;

pchar = &szarr[1];
for(int i = KEYSIZE / 2; i < KEYSIZE; i++)// Transfer random bytes to second half of in
szin[i] = *(pchar++); // This worked up to now. After update it is broken
printf("Hello\r\n");
printf("%s\r\n", szin);
pchar = &szarr[2];
int jj = 0;
for(int i = KEYSIZE / 2; i < KEYSIZE; i++)// Transfer random bytes to second half of in
{
szin2[i] = pchar[jj]; // This is my current workaround
jj++;
}
printf("%s\r\n", szin2);
return szin[jj + 3] * szin2[jj];
}

VS2013 prints: Hello -----------------lah1blah2blah3blah--------------------------------- -----------------lah1blah2blah3blah--------------------------------- This seems to be ok. VS2019 prints: Hello -----------------h4blah5blah6blah7b--------------------------------- -----------------lah1blah2blah3blah--------------------------------- Line after hello is not what to be expected. Printing indexes does not help as the code is strongly optimized by the compiler. Already adding the printf did change the assembler code produced. IMHO the compiler has a problem. ...and Debug version in VS2019 is also OK.

Lost User

Time to report it to Microsoft.

Lost User

I have no idea if this will affect anything but try the following change:

// change this line:
pchar = &szarr[1];

// to
pchar = szarr;

and see what happens.

jung kreidler

Same, but one element earlier. When looking to the assembly code the loop is not visible. Instead AX and XMM0 are loaded, but both from the wrong index. As the target address is szin[KEYSIZE/2], which is szin[17] the pointer to element 0 gets added by 17. This is also done for the source pointer pchar, which is wrong. 002D10F2 66 8B 45 8E mov ax,word ptr [ebp-72h] 002D10F6 0F 10 85 7E FF FF FF movups xmm0,xmmword ptr [ebp-82h] 72 and 82 are 17 bytes to less. They should be: mov ax,word ptr [ebp-83h] movups xmm0,xmmword ptr [ebp-93h]

jung kreidler

Yep, done so.

Lost User

Will be interested to know what their reply is, and why more people have not hit this.

Lost User

You may be pleased to know that I have installed VS 2019 and reproduced the problem exactly as you describe it.

Victor Nijegorodov

So it seems to be a bug in a VS2019 compiler?

Lost User

It certainly appears to be. Let's see what Microsoft have to say.

Victor Nijegorodov

Where have you reported this bug?

jung kreidler

Problem after Update 16.5.2 - Developer Community[^] Status is: Under investigation, but it's one problem of > 1k... @Richard MacCutchan: Thanks for testing. So, I'm not alone :-D

jung kreidler

Seems to be fixed with 16.5.4

Lost User

Wow, that was fast. Nice to know that Microsoft took your report seriously.

jung kreidler

IMHO they found it without my post, as the forum still shows 'under investigation'. However, glad that it's fixed now. ...but some suspiciousness remains.