The rpmdiff check is not very good.  It really should look at the actual relocations and check if the link editor can resolve them to position-independent code.

The more recent build has optimized out all stack protector usage.  Before:

Relocation section [ 6] '.rela.text' for section [ 5] '.text' at offset 0xc98 contains 17 entries:
  Offset              Type            Value               Addend Name
  0x0000000000000080  AARCH64_CALL26  000000000000000000      +0 __os_urealloc
  0x000000000000014c  AARCH64_CALL26  000000000000000000      +0 __os_umalloc
  0x0000000000000174  AARCH64_CALL26  000000000000000000      +0 memcpy
  0x00000000000001b4  AARCH64_CALL26  000000000000000000      +0 __os_realloc
  0x0000000000000204  AARCH64_ADR_GOT_PAGE 000000000000000000      +0 __stack_chk_guard
  0x0000000000000210  AARCH64_LD64_GOT_LO12_NC 000000000000000000      +0 __stack_chk_guard
  0x0000000000000290  AARCH64_LD64_GOT_LO12_NC 000000000000000000      +0 __stack_chk_guard
  0x00000000000002b0  AARCH64_JUMP26  000000000000000000      +0 __db_pgfmt
  0x0000000000000314  AARCH64_LD64_GOT_LO12_NC 000000000000000000      +0 __stack_chk_guard
  0x0000000000000334  AARCH64_JUMP26  000000000000000000      +0 __db_retcopy
  0x00000000000003a8  AARCH64_LD64_GOT_LO12_NC 000000000000000000      +0 __stack_chk_guard
  0x00000000000003cc  AARCH64_JUMP26  000000000000000000      +0 __heapc_gsplit
  0x00000000000003d4  AARCH64_LD64_GOT_LO12_NC 000000000000000000      +0 __stack_chk_guard
  0x0000000000000400  AARCH64_JUMP26  000000000000000000      +0 __db_goff
  0x0000000000000404  AARCH64_LD64_GOT_LO12_NC 000000000000000000      +0 __stack_chk_guard
  0x0000000000000424  AARCH64_JUMP26  000000000000000000      +0 __db_goff
  0x0000000000000428  AARCH64_CALL26  000000000000000000      +0 __stack_chk_fail

After:

Relocation section [ 6] '.rela.text' for section [ 5] '.text' at offset 0x14f0 contains 11 entries:
  Offset              Type            Value               Addend Name
  0x0000000000000080  AARCH64_CALL26  000000000000000000      +0 __os_urealloc
  0x000000000000014c  AARCH64_CALL26  000000000000000000      +0 __os_umalloc
  0x0000000000000174  AARCH64_CALL26  000000000000000000      +0 memcpy
  0x00000000000001b4  AARCH64_CALL26  000000000000000000      +0 __os_realloc
  0x0000000000000270  AARCH64_JUMP26  000000000000000000      +0 __db_retcopy
  0x0000000000000284  AARCH64_JUMP26  000000000000000000      +0 __db_pgfmt
  0x00000000000002f0  AARCH64_JUMP26  000000000000000000      +0 __db_retcopy
  0x0000000000000344  AARCH64_JUMP26  000000000000000000      +0 __db_retcopy
  0x0000000000000364  AARCH64_JUMP26  000000000000000000      +0 __heapc_gsplit
  0x0000000000000370  AARCH64_JUMP26  000000000000000000      +0 __db_goff
  0x000000000000037c  AARCH64_JUMP26  000000000000000000      +0 __db_goff

The optimization looks correct because the functions do not contain any addressable local variables.

I do not know why it wasn't applied by GCC before.

As I recently found out:

  Debugging an aarch64 problem re -fPIC:
  https://rpmdiff.engineering.redhat.com/run/408856/7/
  Bisected it to r270414 on gcc-8-branch.  After the revision, a call to
  __stack_chk_guard is gone, and so is R_AARCH64_LD64_GOT_LO12_NC.  And
  the RPMDiff check uses eu-readelf --reloc | grep GOT to check for -fPIC.

An e2fsprogs errata is also blocked by this.

https://rpmdiff.engineering.redhat.com/run/411165/

This is not a GCC bug AFAICS so I'll close it out.

Not a GCC bug.  It would best be described as a false positive from rpmdiff due to its lame approach to detecting PIC.