Bug in AArch64 optimizer when compiling BGRABitmap with trunk compiler
## Summary
I have discovered that compiling a simple program that uses BGRA bitmap will crash with the trunk AArch64 compiler and /O2 optimization on Darwin. This issue was introduced to trunk in commit c1d8e32eaedd102759c3b5132228aaf493026b8d.
## System Information
<!-- The more information are provided the easier it is to replicate the bug -->
- **Operating system:** macOS / Darwin
- **Processor architecture:** AARCH64
- **Compiler version:** trunk
## Steps to reproduce
1. Download the attached project and build on macOS AArch64 with **trunk** compiler
2. Note that the program will crash upon execution when compiled with /O2
## Example Project
<!-- If possible, please create an example project that exhibits the problematic
behavior, and link to it here in the bug report. -->
[test.zip](/uploads/e81d4825c186590f5d3945ddc4631a27/test.zip)
Here is the sample code (the attached file above includes all dependencies):
```pascal
program project1;
uses
{$IFDEF UNIX}
cthreads,
{$ENDIF}
Classes, SysUtils, bgrabitmap, bgrasvg;
var
LBgraSvg: TBGRASVG;
LBgraBitmap: TBGRABitmap;
begin
Writeln('I was compiled with ', {$I %FPCVERSION%});
WriteLn('Program started');
LBgraSvg := TBGRASVG.Create;
try
WriteLn('Loading bitmap');
LBgraSvg.LoadFromFile('bgrabitmap.svg');
LBgraBitmap := TBGRABitmap.Create(64, 64);
try
Writeln('Stretch draw');
LBgraSvg.StretchDraw(LBgraBitmap.Canvas2D, 0, 0, 64, 64);
LBgraBitmap.SaveToFile('output.bmp');
Writeln('Saved output');
finally
LBgraBitmap.Free;
end;
finally
LBgraSvg.Free;
end;
WriteLn('Program ended');
end.
```
## What is the current bug behavior?
When using the 3.2.3 compiler with either /O1 or /O2, the program works correctly.
When using the 3.3.1 compiler with /O1, the program works correctly, but with /O2 the program crashes.
## What is the expected (correct) behavior?
The program must not crash due to a bug in the optimizer.
## Relevant logs and/or screenshots
Here is a screen shot of the attached program compiled with 3.2.3 and 3.3.1. As you can see in 3.3.1 when /O2 incorrect code is generated and causes the program to crash.
issue