#3127 (z80) Incorrect code generated with 32 bit operations

[dom]

This issue was found via zsdcc/z88dk, however the same code is generated for a vanilla sdcc.

For the following code (extracted from a preprocesed md5 program):

#include <stdio.h>
#include <stdint.h>

typedef uint32_t UINT4;

void func(UINT4 *buf, UINT4 *in)
{
  UINT4 a = buf[0], b = buf[1], c = buf[2], d = buf[3];

  printf("%lx %lx %lx %lx\n",a,b,c,d);

  {( a ) +=  ((( ( b ) ) & ( ( c ) )) | ((~ ( b ) ) & ( ( d ) )))  + ( in[ 0] ) + (UINT4)( 3614090360 );}

  printf("%lx %lx %lx %lx\n",a,b,c,d);

  {( d ) +=  ((( ( a ) ) & ( ( b ) )) | ((~ ( a ) ) & ( ( c ) )))  + ( in[ 1] ) + (UINT4)( 3905402710 ); }

  printf("%lx %lx %lx %lx\n",a,b,c,d);
}

int main() {
   UINT4 buf[] = {0x67452301,0xefcdab89,0x98badcfe,0x10325476};
   UINT4 in[] = {0x3ec3,0x0,0x3dc3,0x0,0x3ac3};

   func(buf, in);
}

The following is printed for sdcc 11690 and 11891:

67452301 efcdab89 98badcfe 10325476
d76afa6b efcdab89 98badcfe 10325476
d76afa6b efcdab89 98badcfe c8d2ba69

For sdcc 11311 and other compilers the following is printed:

67452301 efcdab89 98badcfe 10325476
d76ae33a efcdab89 98badcfe 10325476
d76ae33a efcdab89 98badcfe c8d2cb98

Command line is:

sdcpp -iquote"." -DZ80  -D__SDCC -isystem"/Users/dom/z88dk/lib/config//../..//include"    "repro.c" "/tmp/tmpRaLHPjMb.i2"
sdcc --constseg rodata_compiler   -mz80 --no-optsdcc-in-asm --c1mode --emit-externs  --no-c-code-in-asm   --no-peep < "/tmp/tmpPadgwZzR.i" -o "/tmp/tmpPadgwZzR.opt"

The d += line is required to show the problem, replacing in[1] with in[0] on the same line causes the output of sdcc to match other compilers.

I've not had the time to trace down the exact code generation issue, however it's clear that there's been some rework in handling temporary variables and the stack frame between 11311 and 11690. There are some other "regressions" in code generation between the two versions: later versions no longer use djnz for loops - presumably because working values are now held in bcde rather than dehl.

[Philipp Klaus Krause]

I can reproduce the issue using current SDCC on my Debian GNU/Linux testing system.
Interestingly, this is a z80-specific bug: The closely related z180 and r2ka ports generates correct code (but z180 has the bug).

[Philipp Klaus Krause]

Fixed in [r11909].