giseldo/neodataset huggingface dataset:
[Patch] ARM -CriotR crash fix


<h3><details><summary>Original Reporter info from Mantis: <small>CuriousKit @CuriousKit</small></summary><small>

- **Reporter name:** J. Gareth Moreton
</small></details></h3>

## Description:

This patch fixes a build error when making the compiler under -CriotR options on arm platforms.  The fault was due to RedundantMovProcess(p,hpfar1) causing hpfar1 to become a dangling pointer while still returning False (since p wasn't changed).  To compensate and to ensure maximal compiler performance, the 2nd parameter of RedundantMovProcess is now a var parameter and if the instruction is removed, it is set to nil, hence causing hpfar1 to become nil which can be easily detected (in which case, the control flow returns to the beginning of the new 'while' loop, which previously was an 'if' statement that caused the subroutine to exit if hpfar1 couldn't be set).

## Steps to reproduce:

Apply patch and confirm correct compilation, both normally and under -CriotR conditions.

## Additional information:

Due to the construction of the while loop, the compiler is now sometimes more efficient under -O1 and -O2.  For example, in the Classes disassembly:

```
.section .text.n_classes$_$tstream_$__$$_setsize64$int64,"ax"
	.balign 4
.globl	CLASSES$_$TSTREAM_$__$$_SETSIZE64$INT64
	.type	CLASSES$_$TSTREAM_$__$$_SETSIZE64$INT64,#function
CLASSES$_$TSTREAM_$__$$_SETSIZE64$INT64:
	stmfd	r13!,{r3,r14}
	mov	r1,r0 ;  <-- Not optimal
	ldr	r1,[r1]
	ldr	r1,[r1, 124]
	blx	r1
	ldmfd	r13!,{r3,r15}
.Le38:
	.size	CLASSES$_$TSTREAM_$__$$_SETSIZE64$INT64, .Le38 - CLASSES$_$TSTREAM_$__$$_SETSIZE64$INT64
```

Under the patch:

```
.section .text.n_classes$_$tstream_$__$$_setsize64$int64,"ax"
	.balign 4
.globl	CLASSES$_$TSTREAM_$__$$_SETSIZE64$INT64
	.type	CLASSES$_$TSTREAM_$__$$_SETSIZE64$INT64,#function
CLASSES$_$TSTREAM_$__$$_SETSIZE64$INT64:
	stmfd	r13!,{r3,r14}
	ldr	r1,[r0]  ; <-- Optimised
	ldr	r1,[r1, 124]
	blx	r1
	ldmfd	r13!,{r3,r15}
.Le38:
	.size	CLASSES$_$TSTREAM_$__$$_SETSIZE64$INT64, .Le38 - CLASSES$_$TSTREAM_$__$$_SETSIZE64$INT64
```


## Mantis conversion info:

- **Mantis ID:** 38116
- **OS:** Linux (Raspberry Pi OS)
- **OS Build:** 5.4.51-v8+
- **Build:** r47529
- **Platform:** arm (32-bit)
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 47531 (#1014e530813f01757a6ee4b4b16518fe2a7206e1)

Story points: 100.0
AArch64 generates incorrect code for some immediate values


<h3><details><summary>Original Reporter info from Mantis: <small>CuriousKit @CuriousKit</small></summary><small>

- **Reporter name:** J. Gareth Moreton
</small></details></h3>

## Description:

So I've been looking at improving some of the Arm-64 code generated when assigning values to variables, and I was a bit shocked to discover that a number of said assignments produce incorrect code, usually changing the immediate value to -1.

## Steps to reproduce:

Write and run the following program:

``` pascal
program BadValue;
begin
  WriteLn($FFFFFFFBFFFFFFFF)
end.
```

Observe output to be -1, and the generated assembly language for the actual parameter to be something like "movn x2, #0x0, lsl 32" (this is meant to write something to the 33nd to 48th bits, but just writes all zeroes then inverts the entire register, producing $FFFFFFFFFFFFFFFF = -1)

## Additional information:

I have fixed the bug and made a comprehensive test, but am waiting on the test suite to finish running.  However, my fix is embedded among my general improvements to MOV commands.

This bug is present in FPC 3.0.4 and the trunk.

## Mantis conversion info:

- **Mantis ID:** 37554
- **OS:** Linux (Raspberry Pi OS)
- **OS Build:** 5.4.51-v8+
- **Build:** r46353
- **Platform:** aarch64
- **Version:** 3.0.4
- **Fixed in revision:** 46401 (#4faea3a1869969c91c3a17f891f88a24fa1219f3),46402 (#352489c397080a5acab70ec57836256de380dfb0)

Story points: 100.0
X86_64 code optimization


<h3><details><summary>Original Reporter info from Mantis: <small>avk @avk959</small></summary><small>

- **Reporter name:** avk
</small></details></h3>

## Description:

In some cases, when using optimization level 2 and above, FPC generates a completely inoperable code (seemingly starting with revision 45801). Unfortunately, I have no other example besides the one attached.

## Mantis conversion info:

- **Mantis ID:** 37527
- **OS Build:** any
- **Build:** 46337
- **Platform:** x86_64
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Monitored by:** » @CuriousKit (J. Gareth Moreton)

Story points: 100.0
"make all" crashes on i386-win32 when OPT="-CriotR" is specified.


<h3><details><summary>Original Reporter info from Mantis: <small>CuriousKit @CuriousKit</small></summary><small>

- **Reporter name:** J. Gareth Moreton
</small></details></h3>

## Description:

When attempting to make the compiler under i386-win32 with all the debugging checks enabled, an access violation is triggered during the bootstrapping cycle.

## Steps to reproduce:

call "make clean all install OS_TARGET=win32 CPU_TARGET=i386 OPT="-CriotR" under i386-win32 - observe access violation when it attempts to compile the WPO segment of the bootstrapping cycle.

## Additional information:

I'm really hoping this isn't due to one of my optimisations!

Doesn't appear to occur under x86_64-win64.

## Mantis conversion info:

- **Mantis ID:** 36660
- **OS:** Microsoft Windows
- **OS Build:** 10 Professional
- **Build:** r44105
- **Platform:** i386-win32
- **Version:** 3.3.1

Story points: 100.0
compiler: svn rev 43949 broke building i386-win32


<h3><details><summary>Original Reporter info from Mantis: <small>AntonK</small></summary><small>

- **Reporter name:** Anton Kavalenka
</small></details></h3>

## Description:

C:/fpc-3.0.0/bin/i386-win32/ppc386.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../win -FE. -FUC:/projects/fpc/rtl/units/i386-win32 -di386 -dRELEASE  -Us -Sg system.pp -Fi../win<br/>
cpummprocs.inc(1,40) Error: Identifier not found "__m128"<br/>
....<br/>
cpummprocs.inc(29,43) Error: Identifier not found "__m128"<br/>
cpummprocs.inc(29,43) Fatal: There were 50 errors compiling module, stopping<br/>
Fatal: Compilation aborted

## Mantis conversion info:

- **Mantis ID:** 36593
- **OS:** Microsoft Windows
- **OS Build:** 10 Professional
- **Build:** r43960
- **Platform:** i386
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 43967 (#81848157808ef123a1cb244b71d366abeee39aa7)
- **Monitored by:** » Cyrax (Cyrax)

Story points: 300.0
FPC does not build with -Os option


<h3><details><summary>Original Reporter info from Mantis: <small>CuriousKit @CuriousKit</small></summary><small>

- **Reporter name:** J. Gareth Moreton
</small></details></h3>

## Description:

As of revision r43880, the Free Pascal Compiler does not build under i386 and x86_64, failing at the ppc2 stage with access violations.

e.g. from i386-win32:

C:/Users/NLO-012/Documents/Programming/fpc/compiler/ppc2.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../win -FE. -FUC:/Users/NLO-012/Documents/Programming/fpc/rtl/units/i386-win32 -Os -di386 -dRELEASE  -Us -Sg system.pp -Fi../win<br/>
system.pp(132,4) Error: Compilation raised exception internally<br/>
Fatal: Compilation aborted<br/>
An unhandled exception occurred at $004879F9:<br/>
```
EAccessViolation: Access violation<br/>
  $004879F9
  $00479C8B
  $004CAB19
  $004CCB99
  $004CD024
  $00434D72
  $00413E55
```

An unhandled exception occurred at $00419A11:
```
EAccessViolation: Access violation
  $00419A11
  $00419A9A
  $0040BC61
  $77458DA2
  $77458D74
  $77444216
  $00479C8B
  $004CAB19
  $004CCB99
  $004CD024
  $00434D72
  $00413E55
```

## Steps to reproduce:

Pull a fresh copy of the SVN trunk (r43880 or r43881) and attempt to run "make clean all install OPT=-Os"

## Additional information:

Personally confirmed broken for i386-win32, x86_64-win64, i386-linux and x86_64-linux (the last two via Ubuntu).

## Mantis conversion info:

- **Mantis ID:** 36530
- **OS:** Microsoft Windows
- **OS Build:** 10 Professional
- **Build:** r43880
- **Platform:** i386 and x86_64
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 43888 (#11287f018fbf940beed20d4e1c0c09f9b872a006)

Story points: 200.0
Lazarus does not build as of r43826


<h3><details><summary>Original Reporter info from Mantis: <small>CuriousKit @CuriousKit</small></summary><small>

- **Reporter name:** J. Gareth Moreton
</small></details></h3>

## Description:

As of the most recent trunk for both FPC and Lazarus (and also earlier versions of the latter), the IDE does not build successfully, whether via using make or by building it manually.  The following errors occur (taken from x86_64-win64 with paths stripped):

compiler_compilation_options.pas(395,18) Error: (3205) Illegal qualifier<br/>
compiler_compilation_options.pas(421,18) Error: (3205) Illegal qualifier<br/>
compiler_compilation_options.pas(442) Fatal: (10026) There were 2 errors compiling module, stopping<br/>
Fatal: (1018) Compilation aborted

## Steps to reproduce:

Build the latest version of FPC from the SVN repository on either i386-win32 or x86_64-win64, then attempt to build the latest version of Lazarus, using the "FPC" variable to refer to the compiler you just built.

## Additional information:

The errors occur on the following lines:

Push(Options.ExecuteBefore.Command);

Push(Options.ExecuteAfter.Command);

The X position of the error puts the cursor at the start of "ExecuteBefore" and "ExecuteAfter" respectively.

## Mantis conversion info:

- **Mantis ID:** 36507
- **OS:** Microsoft Windows
- **OS Build:** 10 Professional
- **Build:** r43826
- **Platform:** i386 and x86_64
- **Version:** 3.3.1
- **Fixed in revision:** 62477

Story points: 100.0
Compiler fails to build


<h3><details><summary>Original Reporter info from Mantis: <small>Thaddy</small></summary><small>

- **Reporter name:** Thaddy de Koning
</small></details></h3>

## Description:

The compiler fails to build for armhf/Raspbian on r43626

Build fails in *first* cycle on pp.pas

## Steps to reproduce:

make clean all install.<br/>
Hang is on:<br/>
/usr/bin/ppcarm -Ur -Xs -O2 -n -Fuarm -Fusystems -Fu/home/asta/fpc331/rtl/units/arm-linux -Fiarm -FEarm/bin/arm-linux -FUarm/units/arm-linux -dRELEASE -CX -XXs -CpARMv7a -CfVFPv3 -OpARMv7a   -dREVINC -darm -dGDB -dBROWSERLOG -Fuarmgen pp.pas

## Additional information:

Full build settings:<br/>
sudo make clean install INSTALL_PREFIX=/usr/local PP=/usr/bin/ppcarm REVINC=force REVSTR=43626  OPT="-CX -XXs -CpARMv7a -CfVFPv3 -OpARMv7a"

bootstrap is 3.0.4 (native)

## Mantis conversion info:

- **Mantis ID:** 36391
- **OS:** Raspbian
- **OS Build:** Buster
- **Build:** 43626
- **Platform:** armhf
- **Version:** 3.3.1
- **Fixed in revision:** 43635 (#0cb85eef9bc2f4a0d1e89f148c1e2aa63207191f)

Story points: 200.0
Internal Error 200130121 when compiling x86_64-win64 as of r43457


<h3><details><summary>Original Reporter info from Mantis: <small>CuriousKit @CuriousKit</small></summary><small>

- **Reporter name:** J. Gareth Moreton
</small></details></h3>

## Description:

As of revision r43457, the compiler raises Internal Error 200130121 when you try to "make all" under x86_64-win64.

## Steps to reproduce:

On a 64-bit Windows platform, run "make distclean all install" from the FPC source directory and observe the internal error trigger at the ppc1.exe stage.

## Additional information:

Possibly caused by incorrect code generation related to new peephole optimisations that Florian implemented last night.

## Mantis conversion info:

- **Mantis ID:** 36307
- **OS:** Microsoft Windows
- **OS Build:** 10 Professional
- **Build:** r43457
- **Platform:** x86_64-win64
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 43460 (#6bed497c7c3cba3bde7cf91a4544c67e90b041a3)

Story points: 300.0
[Patch] Bug fix for jump optimisations under debug mode


<h3><details><summary>Original Reporter info from Mantis: <small>CuriousKit @CuriousKit</small></summary><small>

- **Reporter name:** J. Gareth Moreton
</small></details></h3>

## Description:

When building packages with DEBUG=1, some of the files can sometimes raise internal error 2018062911 under x86_64-linux.  This was due to the presence of a "tai_tempalloc" entry that the code wasn't expecting in OptPass2Jcc.

Now, for both OptPass2Jcc and SkipLabelFast, if any entries are found that belong to the SkipInstr set (which includes tai_tempalloc), the stripping code will move to the next entry and leave it alone.  The internal error is still raised though if it isn't a label or align and doesn't belong to the set (i.e. is an instruction or something else that affects program flow in some way).

## Steps to reproduce:

Apply patch, then run the following command from an x86_64 Linux terminal (specifying directories and prefixes if needs be):

"make distclean all install DEBUG=1 NOGDB=1 NOGDBMI=1 GDBMI=1"

Confirm that Internal Error 2018062911 is no longer raised when packages are compiled.

## Additional information:

Additionally, SkipLabelFast now has a check that will not remove alignment fields if debug info is present, so such behaviour is consistent throughout the compiler.

## Mantis conversion info:

- **Mantis ID:** 36299
- **OS:** Ubuntu
- **OS Build:** 16.04
- **Build:** r43453
- **Platform:** x86_64-linux
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 43455 (#5c0a5b73c7cfade35d402e59bca06c8a6167a3f1)

Story points: 100.0
[Patch] Out-of-date copyright message


<h3><details><summary>Original Reporter info from Mantis: <small>CuriousKit @CuriousKit</small></summary><small>

- **Reporter name:** J. Gareth Moreton
</small></details></h3>

## Description:

For a while now, the copyright message upon running fpc reads "Copyright (c) 1993-2018 by Florian Klaempfl and others" - the year should now be 1993-2019, given that many updates have been made to the compiler in the first eight months of 2019.

## Steps to reproduce:

Apply patch and confirm everything builds and the year is updated when the compiler is run.

## Additional information:

I might recommend changing this field to use a macro in place of the year, much how the previous line of the copyright message uses the "$FPCDATE" macro to display the full date of the build.  Introducing a new macro that just contains the year field does not seem like a difficult extension, and it means that the copyright message does not need to be updated in future.

## Mantis conversion info:

- **Mantis ID:** 35903
- **OS:** Microsoft Windows
- **OS Build:** 10 Professional
- **Build:** r42527
- **Platform:** Cross-platform
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 42558 (#7809930b08765742aa3bb1ee307850e5a86cb0ff),44008 (#eed0e52a64ee8c8d5911cdc2ee3bcb63c72f56b3)
- **Target version:** 3.2.0

Story points: 100.0
Any use whatsoever of "label" and "goto" in a procedure marked as inline crashes the compiler.


<h3><details><summary>Original Reporter info from Mantis: <small>Akira1364</small></summary><small>

- **Reporter name:** 
</small></details></h3>

## Description:

I'm aware that inline would not be supported (AFAIK) for methods containing gotos in the first place, however, that's a different thing than hard-crashing the compiler (with no real error message).

## Steps to reproduce:

Attempt to compile the following example program:

``` pascal
program BugExample;

{$mode ObjFPC}
{$GOTO ON}

type SubRange = 1..3;

  procedure Blah(const I: SubRange); inline;
  var
    B: Boolean = True;
  label
    Top;
  begin
    Top:
      case I of
        1:
          WriteLn(2);
        2:
          if B then
          begin
            B := False;
            WriteLn('Resetting!');
            goto Top;
          end
          else
            WriteLn(4);
        3:
          WriteLn(6);
      end;
  end;

  procedure DoIt;
  begin
    Blah(1);
    Blah(2);
    Blah(3);
  end;

begin
  DoIt;
end.
```

Note that if "inline" is removed, it compiles without issues and runs as expected.

## Mantis conversion info:

- **Mantis ID:** 35820
- **OS:** Windows
- **OS Build:** 10
- **Build:** Trunk
- **Platform:** x86_64
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 43793 (#fd0012deff5ef06a302cbd81762c3bb4085d36f7)
- **Monitored by:** » Akira1364 (Akira1364), » @MageSlayer (Denis Golovan)

Story points: 100.0
SIGSEV crash due to corrupt call stack generated by the compiler in delphi mode


<h3><details><summary>Original Reporter info from Mantis: <small>gerrit</small></summary><small>

- **Reporter name:** Gerrit Moeller
</small></details></h3>

## Description:

Calling an overridden method with stdcall calling convention through an interface crashes (SIGSEV) if stdcall is not repeated in overriding method!

More Information -> See comments in submitted source code.

## Steps to reproduce:

Compile and run program source code submitted with this issue.

## Additional information:

//<br/>
// Submitted by:<br/>
//<br/>
//   Gerrit Moeller<br/>
//   gerrit.moeller@gm-software.de<br/>
//   www.gm-software.de<br/>
//

{$MODE DELPHI} // <- Without delphi mode the parser correctly issues an error if stdcall is not repeated<br/>
```               //    in overriding method (see below).```<br/>

``` pascal
program FPCIntfStdcallOverrideCrash;

type

  ISomeMethod = interface(IUnknown)
    ['{DBFB482B-76FB-4DB7-A321-1001755B1F9E}']
    function SomeMethod(const AIntArg: Integer; const AStrArg: WideString): IUnknown; stdcall;
  end;
```


```
  TBaseClassImpl = class(TInterfacedObject, ISomeMethod)
   public
    function SomeMethod(const AIntArg: Integer; const AStrArg: WideString): IUnknown; virtual; stdcall;
  end;
```


```
  TDerivedClassImpl = class(TBaseClassImpl)
  public
   //
   // In delphi mode it is not neccessary to repeat stdcall calling convention in the overriding method.
   // But the compiler then generates a call stack with another calling convention for the overriding method!
   // If you call the overriding method through an interface this crashes (SIGSEV) since it is supposed to be stdcall!
   // Repeating the calling convention in the overriding method fixes the crash.
   //
   function SomeMethod(const AIntArg: Integer; const AStrArg: WideString): IUnknown; override; // stdcall; // <- uncommenting stdcall fixes the crash
  end;
```


``` pascal
function TBaseClassImpl.SomeMethod(const AIntArg: Integer; const AStrArg: WideString): IUnknown; stdcall;
begin
  // Arguments corrupt here due to call stack mismatch!
  Result := nil; // <- SIGSEV crash here due to call stack mismatch!
end;

function TDerivedClassImpl.SomeMethod(const AIntArg: Integer; const AStrArg: WideString): IUnknown;
begin
  // Arguments corrupt here due to call stack mismatch!
 Result := inherited SomeMethod(AIntArg, AStrArg);
end;
```


``` pascal
procedure Main;
var methodIntf: ISomeMethod; unk: IUnknown;
begin
  methodIntf := TDerivedClassImpl.Create;
  unk := methodIntf.SomeMethod(100, 'Some string contents');
end;
```


``` pascal
begin
  Main;
end.
```


## Mantis conversion info:

- **Mantis ID:** 35233
- **OS:** All (i guess)
- **OS Build:** All (i guess)
- **Build:** All
- **Platform:** All (i guess)
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 41716 (#ed2ae508d090338a706418fdf740bc219b614776)

Story points: 100.0
FPC generates a word access when it should generate a byte access, occasionally causing an access violation


<h3><details><summary>Original Reporter info from Mantis: <small>440bx @440bx</small></summary><small>

- **Reporter name:** 
</small></details></h3>

## Description:

For some expressions the compiler generates code that accesses a word instead of accessing a byte.  When this occurs on the last accessible byte of a memory block, this causes an access violation.  In the following code snippet:


``` pascal
procedure DumpHex(BaseAddress : pointer; BlockSize : DWORD);
const
  HexDigits      : packed array[0..$F] of char = '0123456789ABCDEF';

var
  Buf    : packed array[0..127] of char;

  HexPtr : ^char;

  p      : pbyte;

  i      : dword;
begin
  ZeroMemory(@Buf, sizeof(Buf));

  HexPtr := @Buf;

  if BlockSize > high(Buf) then BlockSize := high(Buf);  // only dump 1 buffer's
                                                         // worth
  i := 0;
  while I < BlockSize do
  begin
    pchar(p) := pchar(BaseAddress) + I;

    HexPtr^ := HexDigits[p^ shr 4];                      // first nibble
    inc(HexPtr);

    // this instruction causes an access violation on the last byte because
    // it tries to access a word instead of a byte.

    HexPtr^ := HexDigits[p^ and $F];                     // second nibble
    inc(HexPtr);

    writeln('I : ', i,
            ' address : ', IntToHex(ptruint(p), 0), ' dump : ', Buf);

    inc(I);
  end;

  writeln(Buf);                                          // won't get here
end;             
```

the expression:

```    HexPtr^ := HexDigits[p^ and $F];                     // second nibble```<br/>

generates a word access instead of a byte access.

The attached program reliably reproduces the problem. 

## Steps to reproduce:

attempt to access the last accessible byte of a memory block.

Compile and run the attached program.  Look at the code generated for the expression:

```    HexPtr^ := HexDigits[p^ and $F];                     // second nibble```<br/>

to see the cause of the access violation.

## Mantis conversion info:

- **Mantis ID:** 35187
- **OS:** Windows and possibly others
- **OS Build:** all
- **Platform:** 32 and 64 bit AMD64
- **Version:** 3.0.4
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 41667 (#d65737393352eabc8aff52f9c7b6545d09c578c8)
- **Monitored by:** » @engkin (engkin), » Cyrax (Cyrax)

Story points: 100.0
[Patch] Internal Error 200208181 fix


<h3><details><summary>Original Reporter info from Mantis: <small>CuriousKit @CuriousKit</small></summary><small>

- **Reporter name:** J. Gareth Moreton
</small></details></h3>

## Description:

There's a critical bug in the "tai_cpu_abstract.ppuload" constructor.  When loading in the operand count, it doesn't actually set ops, the variable that keeps track of this, which remains at zero.  As a result, the loader skips loading in the instruction's operands and moves onto the next instruction, where instead of data for the next tai object in the PPU file, there's operand data instead, and because of this, Internal Error 200208181 is raised because of a signature mismatch.

## Steps to reproduce:

Apply patch and confirm successful compilation of the compiler.

## Additional information:

Normally this bug is impossible to trigger because it seems that nodes of type asmn are not usually saved to the PPU file.  I have, however, triggered it on my own work with the compiler, and even if the code is rarely triggered, it is still a bug with a known way of triggering it (have a construct where a node of type "asmn" is saved to a PPU file, then try to load the PPU file on a subsequent compilation of your project).

## Mantis conversion info:

- **Mantis ID:** 35065
- **OS:** Microsoft Windows
- **OS Build:** 10 Professional
- **Build:** Cross-platform
- **Platform:** x86_64-win64
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 41310 (#d4e059bd41b62841560790c0051c9c437243cad5)
- **Target version:** 3.3.1

Story points: 200.0