https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040
Bug ID: 86040
Summary: [avr]: RAMPZ is not always cleared after loading
__flashN data
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lmorrison at nautel dot com
Target Milestone: ---
Created attachment 44230
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44230&action=edit
Test case demonstrating the failure to restore/clear RAMPZ
This is possibly related to bug 52461, but it appears that either not all cases
were caught, or else a regression might have re-introduced the problem.
When data is fetched from program memory through the use of the __flashN named
address spaces, the RAMPZ register is set-up with the correct high-order
address byte prior to the data fetch. Most of the time, after the fetch is
complete, RAMPZ is cleared back to zero. However, it appears that at least some
of the time, RAMPZ is not cleared after use.
It's important that RAMPZ must be cleared after use, because some supported AVR
processors (ie. XMEGA with EBI) also implicitly make use of the RAMPZ register
whenever data-space memory is accessed through the Z pointer.
I am attaching a minimal example, targeting the ATxmega128A1U, which
demonstrates both one case in which the correct behavior occurs, and another in
which the wrong behavior occurs.
Specifically, when a single-byte value is fetched (myArray[x][y].value1) RAMPZ
is not cleared. When a multi-byte value is fetched (myArray[x][y].value2) RAMPZ
is correctly cleared.
This test case has been compiled against avr-gcc 5.4.0, 8.0.1, and 8.1.0, with
optimization set to O0, O1, and Os. All cases exhibit the problem.
