arm64: "unsupported RELA relocation: 275" loading certain modules

Bug #1695093 reported by dann frazier
26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
gcc-5 (Ubuntu)
Fix Released
Undecided
Unassigned
Xenial
Fix Released
Undecided
Unassigned
Yakkety
Won't Fix
Undecided
Unassigned
Zesty
Won't Fix
Undecided
Unassigned
gcc-6 (Ubuntu)
Fix Released
Undecided
Unassigned
Xenial
Invalid
Undecided
Unassigned
Yakkety
Won't Fix
Undecided
Unassigned
Zesty
Won't Fix
Undecided
Unassigned
linux (Ubuntu)
Fix Released
Undecided
Unassigned
Xenial
Fix Released
Undecided
Unassigned
Yakkety
Won't Fix
Undecided
Unassigned
Zesty
Won't Fix
Undecided
Unassigned

Bug Description

[Impact]
Certain kernel modules are unloadable (libceph & scsi_debug) due to the compiler generating unsupported relocations.

This symptom is similar to LP: #1533009 but, in that case it impacted all modules, and the fix for that appears to remain in place.

[Test Case]

With the hwe-z kernel:

ubuntu@grotian:~$ sudo modprobe libceph
modprobe: ERROR: could not insert 'libceph': Exec format error
ubuntu@grotian:~$ dmesg
[66988.470307] module libceph: unsupported RELA relocation: 275

[Regression Risk]
The scope of the fix is restricted to aarch64, so regressions should only impact the arm64 port of Ubuntu. Regressions could impact when literal loads are used - which may have performance impacts or possibly cause software to fail to build/run where it previously did. This is somewhat mitigated by the fact that this has been fixed in artful gcc-5/gcc-6 and used on our buildds for some time. Only "somewhat", because gcc-7 is now the default.

Revision history for this message
In , Robert Schiele (rschiele) wrote :

Created attachment 40487
test case to reproduce the problem

To support older Cortex A53 CPUs that suffer from erratum 843419 the Linux kernel has some option not to allow certain relocations in kernel modules. To achieve that it utilizes the options -mcmodel=large -mpc-relative-literal-loads.

Unfortunately we found a case where gcc does still produce such relocations despite the options being used if optimization level is at least -O2.

The code in question is attached and the problem can be reproduced like this:

$ aarch64-linux-gnu-gcc -O2 -mcmodel=large -mpc-relative-literal-loads -c t.c
$ aarch64-linux-gnu-objdump -r t.o

t.o: file format elf64-littleaarch64

RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000000000018 R_AARCH64_CALL26 strcmp
0000000000000030 R_AARCH64_ADR_PREL_PG_HI21 .text+0x0000000000000060
0000000000000034 R_AARCH64_ADD_ABS_LO12_NC .text+0x0000000000000060
0000000000000050 R_AARCH64_ABS64 .rodata.str1.8

Obviously the attached code by itself might not be very useful but it is a stripped-down code example of a real-world kernel driver just to demonstrate the problem.

Some observations:
1. The problem did reproduce with the latest patches from Linaro and with the upstream version (without the Linaro patches) of latest gcc 6 branch.
2. The problem did also reproduce with the gcc 5 branch including the Linaro patches on that branch. I did not check the gcc 5 branch without the Linaro patches.
3. The problem disappears if the useless (not used in the code) second entry in the array gets removed from the code.
4. The problem seems to be in the code that is generated for the strcpy by the compiler.
5. The problem disappears if the string is made longer. In that case the string ends up in .rodata.str1.8 section like the other string, while in the problematic case it is stored as .xword type in .text section.

So my personal conclusion is that some code in the backend involved in this strcpy optimization does not honor the -mpc-relative-literal-loads option properly.

Revision history for this message
In , Ktkachov (ktkachov) wrote :

Confirmed on GCC 6.3.1
This doesn't appear on trunk. Trunk generates a pc-relative load.

aarch64-none-elf-objdump -r t.o

reloc.o: file format elf64-littleaarch64

RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000000000018 R_AARCH64_CALL26 strcmp
0000000000000038 R_AARCH64_ABS64 .rodata.str1.8
0000000000000040 R_AARCH64_ABS64 .rodata.str1.8+0x0000000000000008

Revision history for this message
In , Ktkachov (ktkachov) wrote :

This was fixed by a trunk patch that has been only partially backported to GCC 6.
Testing a patch to fix it.

Revision history for this message
In , Robert Schiele (rschiele) wrote :

If you point me to the specific patch that you have in mind I can in parallel already test whether besides the test case I provided it also fixes the original problem this was detected with.

Revision history for this message
In , Ktkachov (ktkachov) wrote :

(In reply to Robert Schiele from comment #3)
> If you point me to the specific patch that you have in mind I can in
> parallel already test whether besides the test case I provided it also fixes
> the original problem this was detected with.

I've posted a patch for review at:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00736.html
It should apply to a GCC 6-based tree (but not GCC 7 trunk which doesn't exhibit this bug)

Revision history for this message
In , Robert Schiele (rschiele) wrote :

Thanks! I can confirm that this also fixes the original problem for all cases we observed so far.

Revision history for this message
In , Ktkachov (ktkachov) wrote :

thanks for testing this out

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1695093

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
dann frazier (dannf) wrote : Re: arm64: unsupported RELA relocation: 275 loading libceph module

This also impacts the scsi_debug module. Test Case:

find /lib/modules/$(uname -r) -type f -name '*.ko' | while read mod; do if readelf -r $mod | grep -q 000100000113; then echo $mod; fi; done

For hwe-x, this matches scsi_debug. For hwe-y & hwe-z, it matches scsi_debug and libceph.

Changed in linux (Ubuntu Xenial):
status: New → Confirmed
Changed in linux (Ubuntu Yakkety):
status: New → Confirmed
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Changed in linux (Ubuntu Zesty):
status: New → Confirmed
summary: - arm64: unsupported RELA relocation: 275 loading libceph module
+ arm64: "unsupported RELA relocation: 275" loading certain modules
Ryan Beisner (1chb1n)
tags: added: arm64 uosci
Revision history for this message
dann frazier (dannf) wrote :

Attached is a buildlog of the kernel w/ V=1 set to see the full gcc commandline.
I confirmed that the symptoms are present w/ this build.

Revision history for this message
Steve Capper (steve-capper) wrote :

Hi,
I think the problem has already been solved here:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00736.html

This fix appeared to do the trick for gcc-6_1_0-release on my machine, I would suggest that you give it a go.

[ I verified the relocations via:
aarch64-linux-gnu-objdump -dr ./net/ceph/libceph.ko | less
Then searched for the R_AARCH64_ADR_PREL_PG_HI21 relocation. ]

Cheers,
--
Steve

Revision history for this message
dann frazier (dannf) wrote :

I attempted to port the above patch to our branch to test it, but it has conflicts with the linaro snapshot patch we apply. It appears that the conflicts are with a backport of r237607[*] applied to Linaro's gcc-6 branch. r237607 is also supposed to be the source of the patch in Comment #4 - so perhaps that backport was incomplete?

[*] https://git.linaro.org/toolchain/gcc.git/commit/?h=linaro/gcc-6-branch&id=2ace425fb0ae8502c240505448fc9befd618e279

Changed in gcc-6 (Ubuntu):
status: New → Confirmed
Changed in gcc-6 (Ubuntu Zesty):
status: New → Confirmed
Changed in gcc-6 (Ubuntu Yakkety):
status: New → Confirmed
Changed in gcc-6 (Ubuntu Xenial):
status: New → Confirmed
Revision history for this message
dann frazier (dannf) wrote :

fyi, I verified that this is also reproducible with gcc-linaro-6.3.1-2017.05

Changed in linux:
importance: Unknown → Medium
status: Unknown → In Progress
dann frazier (dannf)
Changed in gcc-6 (Ubuntu Xenial):
status: Confirmed → Invalid
dann frazier (dannf)
Changed in gcc-5 (Ubuntu Xenial):
status: New → Confirmed
Revision history for this message
dann frazier (dannf) wrote :

Here's a backport of the gcc-6 fix to gcc-5. It includes a backport of the -mpc-relative-literal-loads option rename change, since it was a dependent patch, and I'm not comfortable enough w/ gcc development to do the backport w/o it.

tags: added: patch
Revision history for this message
dann frazier (dannf) wrote :

I uploaded a package w/ the patch from Comment #7 to ppa:dannf/test. Note that the tests took a *very* long time on arm64, with lots of timeouts:
  https://launchpad.net/~dannf/+archive/ubuntu/test/+build/13073558
This was not a problem for other architectures.

I did a local arm64 build of the *current* gcc-5 in xenial-updates, and observed the same symptoms - so I don't think this is a regression in my proposed fix. That said, this wasn't a problem with the current xenial-updates build:
  https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/security/+build/11132711

So it would appear that something has regressed for xenial since that upload.

Revision history for this message
In , Wilco-z (wilco-z) wrote :

Author: wilco
Date: Mon Jul 24 18:06:37 2017
New Revision: 250478

URL: https://gcc.gnu.org/viewcvs?rev=250478&root=gcc&view=rev
Log:
Fix PR79041

As described in PR79041, -mcmodel=large -mpc-relative-literal-loads
may be used to avoid generating ADRP/ADD or ADRP/LDR. However both
trunk and GCC7 may still emit ADRP for some constant pool literals.
Fix this by adding a aarch64_pcrelative_literal_loads check.

gcc/
 PR target/79041
 * config/aarch64/aarch64.c (aarch64_classify_symbol):
 Avoid SYMBOL_SMALL_ABSOLUTE for literals with pc-relative literals
gcc/testsuite/
 * gcc.target/aarch64/pr79041-2.c: New test.

Added:
    trunk/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/aarch64/aarch64.c
    trunk/gcc/testsuite/ChangeLog

Revision history for this message
In , Wilco-z (wilco-z) wrote :

Author: wilco
Date: Tue Jul 25 12:08:59 2017
New Revision: 250514

URL: https://gcc.gnu.org/viewcvs?rev=250514&root=gcc&view=rev
Log:
Fix PR79041

As described in PR79041, -mcmodel=large -mpc-relative-literal-loads
may be used to avoid generating ADRP/ADD or ADRP/LDR. However both
trunk and GCC7 may still emit ADRP for some constant pool literals.
Fix this by adding a aarch64_pcrelative_literal_loads check.

    gcc/
 PR target/79041
 * config/aarch64/aarch64.c (aarch64_classify_symbol):
 Avoid SYMBOL_SMALL_ABSOLUTE for literals with pc-relative literals.
    gcc/testsuite/
 * gcc.target/aarch64/pr79041-2.c: New test.

Added:
    branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
Modified:
    branches/gcc-7-branch/gcc/ChangeLog
    branches/gcc-7-branch/gcc/config/aarch64/aarch64.c
    branches/gcc-7-branch/gcc/testsuite/ChangeLog

Revision history for this message
In , Wilco-z (wilco-z) wrote :

Fixed in GCC7 and trunk. GCC6 requires https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01708.html.

Revision history for this message
In , Wilco-z (wilco-z) wrote :

Author: wilco
Date: Wed Jul 26 11:55:03 2017
New Revision: 250567

URL: https://gcc.gnu.org/viewcvs?rev=250567&root=gcc&view=rev
Log:
Disable pr79041-2.c with -mabi=ilp32.

    gcc/testsuite/
 PR target/79041
 * gcc.target/aarch64/pr79041-2.c: Don't run in ILP32.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.target/aarch64/pr79041-2.c

Revision history for this message
In , Wilco-z (wilco-z) wrote :

Author: wilco
Date: Wed Jul 26 11:57:57 2017
New Revision: 250569

URL: https://gcc.gnu.org/viewcvs?rev=250569&root=gcc&view=rev
Log:
Disable pr79041-2.c with -mabi=ilp32.

    gcc/testsuite/
 PR target/79041
 * gcc.target/aarch64/pr79041-2.c: Don't run in ILP32.

Modified:
    branches/gcc-7-branch/gcc/testsuite/ChangeLog
    branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr79041-2.c

Revision history for this message
Andy Whitcroft (apw) wrote : Closing unsupported series nomination.

This bug was nominated against a series that is no longer supported, ie yakkety. The bug task representing the yakkety nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu Yakkety):
status: Confirmed → Won't Fix
Revision history for this message
dann frazier (dannf) wrote :

The timeout issue described in comment #8 is being tracked in LP: #1709727.

Changed in gcc-5 (Ubuntu):
status: New → Triaged
Changed in gcc-5 (Ubuntu Xenial):
status: Confirmed → Triaged
Changed in gcc-5 (Ubuntu Yakkety):
status: New → Won't Fix
Changed in gcc-5 (Ubuntu Zesty):
status: New → Triaged
Changed in linux (Ubuntu Zesty):
status: Confirmed → Triaged
Changed in gcc-6 (Ubuntu Yakkety):
status: Confirmed → Won't Fix
Changed in gcc-6 (Ubuntu Zesty):
status: Confirmed → Triaged
Changed in gcc-6 (Ubuntu):
status: Confirmed → Triaged
Changed in linux (Ubuntu):
status: Confirmed → Triaged
Changed in linux (Ubuntu Xenial):
status: Confirmed → Triaged
Revision history for this message
Matthias Klose (doko) wrote :

fixed in gcc-6 6.3.0-21ubuntu1 in artful

Changed in gcc-6 (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (3.3 KiB)

This bug was fixed in the package gcc-5 - 5.4.1-12ubuntu2

---------------
gcc-5 (5.4.1-12ubuntu2) artful; urgency=medium

  * Merge with Debian; remaining changes:
    - Build from upstream sources.

gcc-5 (5.4.1-12) unstable; urgency=medium

  * Update to SVN 20170820 (r251205, 5.4.1) from the gcc-5-branch.
    - Fix PR libgomp/80394, PR sanitizer/77396, PR sanitizer/80166,
      PR c++/78761, PR gcov-profile/78783, PR c++/79641, PR c/80097,
      PR c++/79512, PR c/77767, PR c/67410, PR c/72816, PR libgomp/80394,
      PR rtl-optimization/80385, PR target/80286 (x86), PR debug/80025,
      PR sanitizer/80168, PR rtl-optimization/80112, PR c++/80129,
      PR sanitizer/79944, PR target/79932 (x86), PR target/79932 (x86),
      PR rtl-optimization/79901, PR rtl-optimization/79901, PR target/79807,
      PR target/79729 (x86), PR middle-end/79396, PR target/79570,
      PR target/79494 (x86), PR target/79568 (x86), PR target/79559 (x86),
      PR tree-optimization/79411, PR middle-end/79399, PR target/79197 (PPC),
      PR ipa/77905, PR target/78796 (AArch64), PR fortran/78298,
      PR middle-end/69183, PR middle-end/78416, PR middle-end/67335,
      PR rtl-optimization/78378, PR target/78227 (x86), PR sanitizer/66343,
      PR rtl-optimization/77919, PR fortran/77665, PR middle-end/77624,
      PR target/77587, PR middle-end/77594, PR sanitizer/68260,
      PR fortran/77516, PR debug/77363, PR middle-end/77377, PR target/71910,
      PR tree-optimization/72824, PR tree-optimization/72824,
      PR sanitizer/71953, PR middle-end/79931, PR ipa/65972, PR lto/50345,
      PR gcov-profile/78783, PR gcov-profile/80413, PR ipa/80212,
      PR sanitizer/70878, PR gcov-profile/80224, PR ipa/80205, PR ipa/80104,
      PR c++/80363, PR c++/80176, PR c++/80141, PR c++/79896, PR c++/79664,
      PR c++/79512, PR c++/78341, PR c++/78949, PR c++/78649, PR c++/77739,
      PR c++/77285, PR c++/78089, PR c++/77467, PR c++/77722, PR c++/77637,
      PR c++/77375, PR c++/72868, PR fortran/78866, PR fortran/77666,
      PR fortran/77500, PR middle-end/50199, PR sanitizer/78992,
      PR sanitizer/78532, PR libstdc++/81002, PR c/81006, PR target/81894 (x86),
      PR target/81861 (x86), PR tree-optimization/81354, PR sanitizer/81604,
      PR tree-optimization/81555, PR tree-optimization/81556,
      PR tree-optimization/81162, PR target/80569 (x86), PR target/81471 (x86),
      PR target/81375 (x86), PR target/81300 (x86), PR tree-optimization/81192,
      PR target/80382 (PPC), PR target/80966 (PPC), PR rtl-optimization/73650,
      PR target/61729 (PPC), PR target/77850 (PPC), PR target/80382 (PPC),
      PR middle-end/80692, PR target/80966 (PPC), PR middle-end/80902,
      PR target/79155 (x86), PR other/80909, PR ipa/80663, PR ipa/79850,
      PR driver/31468, PR other/80589, PR gcov-profile/53915, PR driver/56469,
      PR target/80968 (SPARC), PR target/80968 (SPARC), PR c/81006,
      PR fortran/70601.
    - Fix PR sanitizer/66343. LP: #1704401.
  * Don't build the gc enabled libobjc for cross compilers. Closes: #872233.
  * Fix hangs w/ asan binaries on arm64 (Dann Frazier). LP: #1709727.
  * Linaro branch only: Fix PR target/79041, aarch64 backend em...

Read more...

Changed in gcc-5 (Ubuntu):
status: Triaged → Fix Released
dann frazier (dannf)
description: updated
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello dann, or anyone else affected,

Accepted gcc-5 into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gcc-5/5.4.0-6ubuntu1~16.04.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in gcc-5 (Ubuntu Xenial):
status: Triaged → Fix Committed
tags: added: verification-needed verification-needed-xenial
Revision history for this message
dann frazier (dannf) wrote :
Download full text (4.2 KiB)

gcc-5/xenial verified:

ubuntu@neander:~$ cat /proc/version
Linux version 4.4.0-96-generic (buildd@bos01-arm64-013) (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #119-Ubuntu SMP Tue Sep 12 15:00:28 UTC 2017
ubuntu@neander:~$ sudo dmesg -c > /dev/null
ubuntu@neander:~$ sudo modprobe scsi_debug
modprobe: ERROR: could not insert 'scsi_debug': Exec format error
ubuntu@neander:~$ dmesg
[ 65.658638] module scsi_debug: unsupported RELA relocation: 275
ubuntu@neander:~$ sudo dpkg -i linux-image-4.4.0-96-generic_4.4.0-96.119+gccsru.1_arm64.deb && sudo reboot
(Reading database ... 112555 files and directories currently installed.)
Preparing to unpack linux-image-4.4.0-96-generic_4.4.0-96.119+gccsru.1_arm64.deb ...
Done.
Unpacking linux-image-4.4.0-96-generic (4.4.0-96.119+gccsru.1) over (4.4.0-96.119) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
run-parts: executing /etc/kernel/postrm.d/zz-flash-kernel 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
Setting up linux-image-4.4.0-96-generic (4.4.0-96.119+gccsru.1) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
Not updating initrd symbolic links since we are being updated/reinstalled
(4.4.0-96.119 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled
(4.4.0-96.119 was configured last, according to dpkg)
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-96-generic
W: Possible missing firmware /lib/firmware/ast_dp501_fw.bin for module ast
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
flash-kernel: deferring update (trigger activated)
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
run-parts: executing /etc/kernel/postinst.d/zz-flash-kernel 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
flash-kernel: deferring update (trigger activated)
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
Found linux image: /boot/vmlinuz-4.4.0-93-generic
Found initrd image: /boot/initrd.img-4.4.0-93-generic
Adding boot menu entry for EFI firmware configuration
done
Processing triggers for flash-kernel (3.0~rc.4ubuntu62.2) ...
Unsupported platform on EFI system, doing nothing.
Shared connection to 10.229.65.157 closed.

@@@ REBOOT @@@

ubuntu@neander:~$ cat /proc/version
Linux version 4....

Read more...

tags: added: verification-done verification-done-xenial
removed: verification-needed verification-needed-xenial
Revision history for this message
In , Pinskia (pinskia) wrote :

This test also fails with -fpic.

Revision history for this message
In , Wilco-z (wilco-z) wrote :

(In reply to Andrew Pinski from comment #12)
> This test also fails with -fpic.

It doesn't run in the testsuite with -fpic, so is it a problem?

Revision history for this message
In , Pinskia (pinskia) wrote :

(In reply to Wilco from comment #13)
> It doesn't run in the testsuite with -fpic, so is it a problem?

I run the testsuite with RUNTESTFLAGS='--target_board=unix/\{,-fpic\}' and this testcase fails in the -fpic is selected. Note this is done as we don't have enough coverage for -fpic code in the normal testsuite run; running the testsuite this way has allowed me to file PIC related bugs in the past.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gcc-5 - 5.4.0-6ubuntu1~16.04.5

---------------
gcc-5 (5.4.0-6ubuntu1~16.04.5) xenial-proposed; urgency=medium

  * SRU
  * Fix PR target/77267 (x86), taken from the trunk. LP: #1623418.
  * Fix hangs w/ asan binaries on arm64 (Dann Frazier). LP: #1709727.
  * Linaro branch only: Fix PR target/79041, aarch64 backend emitting
    R_AARCH64_ADR_PREL_PG_HI21 relocation despite -mpc-relative-literal-loads
    option being used (Dan Frazier). LP: #1695093.

 -- Matthias Klose <email address hidden> Wed, 23 Aug 2017 11:35:00 +0200

Changed in gcc-5 (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

The verification of the Stable Release Update for gcc-5 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

dann frazier (dannf)
Changed in linux (Ubuntu Xenial):
status: Triaged → Fix Committed
Changed in linux (Ubuntu Zesty):
status: Triaged → Fix Committed
Revision history for this message
dann frazier (dannf) wrote :

I've verified that this is resolved in both linux_4.4.0-101.124 and linux-hwe_4.10.0-40.44~16.04.1.

Revision history for this message
In , Wilco-z (wilco-z) wrote :

Author: wilco
Date: Wed Jan 17 16:31:42 2018
New Revision: 256800

URL: https://gcc.gnu.org/viewcvs?rev=256800&root=gcc&view=rev
Log:
[AArch64] PR82964: Fix 128-bit immediate ICEs

This fixes PR82964 which reports ICEs for some CONST_WIDE_INT immediates.
It turns out decimal floating point CONST_DOUBLE get changed into
CONST_WIDE_INT without checking the constraint on the operand, which
results in failures. Avoid this by only allowing SF/DF/TF mode floating
point constants in aarch64_legitimate_constant_p. A similar issue can
occur with 128-bit immediates which may be emitted even when disallowed
in aarch64_legitimate_constant_p, and the constraints in movti_aarch64
don't match. Fix this with a new constraint and allowing valid immediates
in aarch64_legitimate_constant_p.

Rather than allowing all 128-bit immediates and expanding in up to 8
MOV/MOVK instructions, limit them to 4 instructions and use a literal
load for other cases. Improve a few TImode tests to use a literal and
ensure they are skipped with -fpic.

This fixes all reported failures.

    gcc/
 PR target/82964
 * config/aarch64/aarch64.md (movti_aarch64): Use Uti constraint.
 * config/aarch64/aarch64.c (aarch64_mov128_immediate): New function.
 (aarch64_legitimate_constant_p): Just support CONST_DOUBLE
 SF/DF/TF mode to avoid creating illegal CONST_WIDE_INT immediates.
 * config/aarch64/aarch64-protos.h (aarch64_mov128_immediate):
 Add declaration.
 * config/aarch64/constraints.md (aarch64_movti_operand):
 Limit immediates.
 * config/aarch64/predicates.md (Uti): Add new constraint.

    gcc/testsuite/
 PR target/79041
 PR target/82964
 * gcc.target/aarch64/pr79041-2.c: Improve test, disable with fpic.
 * gcc.target/aarch64/pr78733.c: Improve test, disable with fpic.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/aarch64/aarch64-protos.h
    trunk/gcc/config/aarch64/aarch64.c
    trunk/gcc/config/aarch64/aarch64.md
    trunk/gcc/config/aarch64/constraints.md
    trunk/gcc/config/aarch64/predicates.md
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.target/aarch64/pr78733.c
    trunk/gcc/testsuite/gcc.target/aarch64/pr79041-2.c

dann frazier (dannf)
Changed in linux (Ubuntu Zesty):
status: Fix Committed → Won't Fix
Changed in linux (Ubuntu Xenial):
status: Fix Committed → Fix Released
Changed in linux (Ubuntu):
status: Triaged → Fix Released
Changed in gcc-6 (Ubuntu Zesty):
status: Triaged → Won't Fix
Changed in gcc-5 (Ubuntu Zesty):
status: Triaged → Won't Fix
Revision history for this message
In , Marxin-m (marxin-m) wrote :

Wilco: Can the bug be marked as resolved?

Revision history for this message
In , Wilco-z (wilco-z) wrote :

(In reply to Martin Liška from comment #16)
> Wilco: Can the bug be marked as resolved?

Yes it is fixed on all active branches.

Changed in linux:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.