Problems with Release build after upgrade of VS2019
-
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. UseKEYSIZEfor all so it is consistent.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.
-
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.
-
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.
-
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.
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]
-
Yep, done so.
-
Yep, done so.
-
Yep, done so.
-
You may be pleased to know that I have installed VS 2019 and reproduced the problem exactly as you describe it.
So it seems to be a bug in a VS2019 compiler?
-
So it seems to be a bug in a VS2019 compiler?
-
Yep, done so.
Where have you reported this bug?
-
Where have you reported this bug?
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
-
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
Seems to be fixed with 16.5.4
-
Seems to be fixed with 16.5.4
-
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.