Microsoft has confirmed that they have a
7-byte-structure-passed-by-value compiler bug in the ARMV4 compiler
used with PB4.2. This happens in both debug and release code, so it
is not an optimization issue. Since I am the only one to have
reported this bug, and because it is known to not be a problem in the
version of the the compiler that will be shipped sometime in the
future with the next version of CE, they have chosen not to put any
effort into fixing it for the current version.

The issue can be reproduced very easily. The following C code snippet
will reproduce the issue by calling test1:

struct test_struct
{
char byte1;
char byte2;
char byte3;
char byte4;
char byte5;
char byte6;
char byte7;
};

void testsub1 (struct test_struct var1Copy)
{
// Assert (var1Copy.byte7 == 7);
char ch;
// Set breakpoint on following line and look at var1Copy
// Bytes 5, 6, and 7 are duplicates of bytes 1, 2, and 3
ch = var1Copy.byte7;
}

void test1(void)
{
struct test_struct var1 = {1,2,3,4,5,6,7};

// If a breakpoint is set here, and the assembly code
// is stepped through, you will see that the first
// dword is used twice, and the second dword is never
// used.
testsub1(var1);
}

I remain surprised that any known compiler bug would be considered
non-important (didn't Intel make that mistake with an "infrequently"
used opcode error in a Pentium chip?). It was also mentioned (but not
verified) that this same ARM compiler is likely used with the eVC++
4.X tools as well.

The only way to verify that this is not an issue in your code is to
search out all the structures and verify that either they are never 7
bytes long, or that they are never passed into a function by value. I
would much rather see a QFE to fix this, but I am unfortunately
resigned to search through our code and make sure no structures are
ever passed by value.

If others are bothered by this too, please speak up.

Arthur McNair
Pittsburgh, PA

Re: Confirmed ARMV4 Compiler Bug in PB4.2 by Lee

Lee
Mon Nov 10 20:48:12 CST 2003


Arthur,

Thanks for your information.
Does this bug exist for struct of other size ?
Thanks !


Arthur McNair <amcnair@vocollect.com> wrote:
> Microsoft has confirmed that they have a
> 7-byte-structure-passed-by-value compiler bug in the ARMV4 compiler
> used with PB4.2. This happens in both debug and release code, so it
> is not an optimization issue. Since I am the only one to have
> reported this bug, and because it is known to not be a problem in the
> version of the the compiler that will be shipped sometime in the
> future with the next version of CE, they have chosen not to put any
> effort into fixing it for the current version.
> The issue can be reproduced very easily. The following C code snippet
> will reproduce the issue by calling test1:
> struct test_struct
> {
> char byte1;
> char byte2;
> char byte3;
> char byte4;
> char byte5;
> char byte6;
> char byte7;
> };
> void testsub1 (struct test_struct var1Copy)
> {
> // Assert (var1Copy.byte7 == 7);
> char ch;
> // Set breakpoint on following line and look at var1Copy
> // Bytes 5, 6, and 7 are duplicates of bytes 1, 2, and 3
> ch = var1Copy.byte7;
> }
> void test1(void)
> {
> struct test_struct var1 = {1,2,3,4,5,6,7};
> // If a breakpoint is set here, and the assembly code
> // is stepped through, you will see that the first
> // dword is used twice, and the second dword is never
> // used.
> testsub1(var1);
> }
> I remain surprised that any known compiler bug would be considered
> non-important (didn't Intel make that mistake with an "infrequently"
> used opcode error in a Pentium chip?). It was also mentioned (but not
> verified) that this same ARM compiler is likely used with the eVC++
> 4.X tools as well.
> The only way to verify that this is not an issue in your code is to
> search out all the structures and verify that either they are never 7
> bytes long, or that they are never passed into a function by value. I
> would much rather see a QFE to fix this, but I am unfortunately
> resigned to search through our code and make sure no structures are
> ever passed by value.
> If others are bothered by this too, please speak up.
> Arthur McNair
> Pittsburgh, PA