Assembler messages with -O0: Error: offset out of range

[Matthias Klose]

seen with 4.7 in quantal on armhf:

$ g++ -c -g -O0 -ftemplate-depth-50 -fPIC predicates.ii -save-temps
predicates.s: Assembler messages:
predicates.s:14867: Error: offset out of range
predicates.s:17416: Error: offset out of range
predicates.s:44495: Error: offset out of range
predicates.s:45858: Error: offset out of range

[Matthias Klose (doko)]

using -O1 or -O2 works

[Matthias Klose (doko)]

binutils version is the 2.23 branch, plus a local ARMv8 patch:

From f5a0dea847f4c6377cae368ab3711a1285ae32f2 Mon Sep 17 00:00:00 2001
From: Chris Schlumberger-Socha <email address hidden>
Date: Fri, 27 Jul 2012 14:16:34 +0100
Subject: [PATCH] Added R_AARCH64_GOT_LD_PREL19 reloc implementation.

[Matthias Klose (doko)]

adding -marm lets the build succeed, -mfloat-abi=softfp not.

[Matthias Klose (doko)]

seen with trunk 20121008 too, but not with 4.7 fsf branch

[Mans Rullgard (mansr)]

This patch against trunk fixes it:

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 866385c..18d0ff4 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -13021,7 +13021,10 @@ create_fix_barrier (Mfix *fix, HOST_WIDE_INT max_address)

       new_cost = arm_barrier_cost (from);

- if (count < max_count
+ /* The pool is aligned to a 4-byte boundary. However, 16-bit Thumb
+ insns can result in count being unaligned here, so we must compare
+ the aligned offset against the limit. */
+ if (((count + 3) & ~3) < max_count
    && (!selected || new_cost <= selected_cost))
  {
    selected = from;

[Mans Rullgard (mansr)]

Ugh, LP mangles whitespace. Here's an attachment instead.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "const-pool-offset.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Matthias Klose (doko)]

the patch (applied for the Ubuntu gcc-4.7 build), fixes two of these offsets, not all four.

$ /scratch/packages/gcc/4.7/u/gcc-4.7-4.7.2/build/gcc/xgcc -B/scratch/packages/gcc/4.7/u/gcc-4.7-4.7.2/build/gcc/ -c -g -O0 -fPIC predicates.ii -save-temps
predicates.s: Assembler messages:
predicates.s:14867: Error: offset out of range
predicates.s:17416: Error: offset out of range

[Mans Rullgard (mansr)]

It seems the problem is failure to take into account that Thumb PC-relative loads round the base address down. I can't reproduce the failure, but try this patch.

[Matthias Klose (doko)]

the file builds fine with the second patch

[Mans Rullgard (mansr)]

Created attachment 28483
Test case

If the following conditions are true, a constant pool is placed too far from an LDR instruction accessing it:

- Compiling to Thumb2.
- There is no unconditional branch within 4k of the LDR instruction.
- At least one of:
  * The LDR instruction is not at a 4-byte aligned address.
  * There is an instruction boundary 4094 bytes from the value of PC
    at the LDR.

The problem here is twofold:

1. The base address of a PC-relative LDR in Thumb2 is the address of the
   instruction plus 4, rounded down to a multiple of 4. The calculation
   for the valid range fails to take this rounding into account.

2. The constant pool is (rightly) 4-byte aligned. When scanning the
   instructions for a suitable location, the possible need for padding
   is not considered.

The problem can be seen by compiling the attached preprocessed source using flags "-mthumb -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -O0 -fPIC".

[Mans Rullgard (mansr)]

Created attachment 28484
Hack patch

This hack patch validates the analysis. A proper fix probably looks different.

[Doko-v (doko-v)]

works with 4.7, fails with trunk

[Mikpe (mikpe)]

Also works with gcc-4.6.

[Mikpe (mikpe)]

The test case started failing with r189790:
http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00695.html

That patch merely enabled insn splitting at -O0, so I suspect it exposed a latent problem in the back-end, consistent with Måns' analysis.

[Doko-v (doko-v)]

this patch is now on the 4.7 branch too.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gcc-4.7 - 4.7.2-11ubuntu1

---------------
gcc-4.7 (4.7.2-11ubuntu1) raring; urgency=low

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

gcc-4.7 (4.7.2-11) experimental; urgency=low

  * Update to SVN 20121124 (r193776) from the gcc-4_7-branch.
    - Fix PR libgomp/55411, PR libstdc++/55413, PR middle-end/55142,
      PR fortran/55352.

  * Update build-indep dependencies for building the libstdc++ docs.
  * Drop the gcc-no-add-needed patch, depend on binutils 2.22 instead.
  * Pass --hash-style=gnu instead of --hash-style=both.
  * Link using --hash-style=gnu on arm64 by default.
  * Split multiarch patches into local and upstreamed parts.
  * Fix PR54974: Thumb literal pools don't handle PC rounding (Matthew
    Gretton-Dann). LP: #1049614, #1065509.
  * Rename the gccgo info to gccgo-4.7 on installation, install into gccgo-4.7.
  * Include libquadmath documentation in the gcc-4.7-doc package.
  * Don't pretend to understand .d files, no D frontend available for 4.7.
  * Fix the multiarch c++ include path for multilib'd targets. LP: #1082344.
  * Make explicit --{en,dis}able-multiarch options effecitive (Thorsten Glaser).
 -- Matthias Klose <email address hidden> Sat, 24 Nov 2012 06:09:46 +0100

[Ramana-gcc (ramana-gcc)]

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01825.html

Patch posted here.

[Matthew Gretton-Dann (matthew-gretton-dann)]

Author: mgretton
Date: Thu Nov 29 10:02:16 2012
New Revision: 193930

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193930
Log:
 PR target/54974
 * config/arm/arm.md (thumb2_pool_range, pool_range): Add comment on
 Thumb pool ranges.
 (thumb1_extendhisi2): Reduce Thumb pool range.
 (arm_movdi): Likewise.
 (thumb1_movdi_insn): Likewise.
 (thumb1_movsi_insn): Likewise.
 (pic_load_addr_unified): Likewise.
 (pic_load_addr_32bit): Likewise.
 (pic_load_addr_thumb1): Likewise.
 (thumb1_movhf): Likewise.
 (arm_movsf_soft_insn): Likewise.
 (thumb1_movsf_soft_insn): Likewise.
 (movdf_soft_insn): Likewise.
 (thumb1_movdf_soft_insn): Likewise.
 * config/arm/neon.md (*neon_mov<mode>): Likewise.
 (*neon_mov<mode>): Likwise.
 * config/arm/thumb2.md: (*thumb2_movsi_insn): Likewise.
 (*thumb2_movhi_insn): Likewise.
 (*thumb2_extendqisi_v6): Likewise.
 (*thumb2_zero_extendqisi_v6): Likewise.
 (*thumb2_zero_extendqisi2_v6): Likewise.
 * config/arm/vfp.md: (*thumb2_movsi_vfp): Likewise.
 (*movdi_vfp): Likewise.
 (*movdi_vfp_cortexa8): Likewise.
 (*thumb2_movsf_vfp): Likewise.
 (*thumb2_movdf_vfp): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/arm/arm.md
    trunk/gcc/config/arm/neon.md
    trunk/gcc/config/arm/thumb2.md
    trunk/gcc/config/arm/vfp.md

[Rguenth (rguenth)]

Fixed on the trunk I suppose.

[Ramana-gcc (ramana-gcc)]

Matt,

Are you planning on backporting this to 4.7 ?

regards
Ramana

[Michael Collison (michael-collison)]

Fixed upstream. Will not backport to 4.7. Issue does not affect linaro 4.8 or 4.9