#4203 PDK14 removes a character read through a volatile-qualified lvalue

[Christopher Bazley]

1: Sample code that reproduces the problem.

char object;
char test(void)
{
  object = 42;
  return *(volatile char *)&object;
}

Save as volatile-read-pdk14.c.

2: Exact command used to run SDCC on this sample code.

sdcc -mpdk14 --c1mode -o volatile-read-pdk14.asm < volatile-read-pdk14.c

The input contains no headers or macros. Add --no-peep to compare the output
without peephole optimisation.

3: SDCC versions tested.

SDCC 4.6.4 r17064, locally built from unmodified compiler sources; the official
SDCC 4.6.4 #17038 snapshot; and SDCC 4.2.0 #13081, all on Linux.

4: Copy of the incorrect output, or a clear description of the observed versus expected behaviour.

The generated function stores 42 and returns the value already held in A:

mov a, #0x2a
mov _object+0, a
ret

I expected the return expression to read object through its volatile-qualified
lvalue. With --no-peep, the read is present:

mov a, #0x2a
mov _object+0, a
mov a, _object+0
ret

The same omission occurs in SDCC 4.2.0 #13081. PDK13 and PDK15 have not been
checked with this reduced example.

The problem is reproduced with unmodified r17064 sources, before the
Z80-family symbol-lookup candidate. It is not introduced by that candidate.

Possibly related to [bugs:#4156]. In this example, --no-peep retains the
required read; the loss can therefore be isolated to peephole optimisation.

[Christopher Bazley]

Fixed by [r17075]