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

Bug #1049614 reported by Matthias Klose on 2012-09-12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro GCC
Won't Fix
Michael Collison
In Progress
gcc-4.7 (Ubuntu)

Bug Description

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) wrote :
Matthias Klose (doko) wrote :
Matthias Klose (doko) wrote :

using -O1 or -O2 works

Matthias Klose (doko) wrote :

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) wrote :
Matthias Klose (doko) wrote :

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

Matthias Klose (doko) wrote :

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

Mans Rullgard (mansr) wrote :

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) wrote :

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

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.]

tags: added: patch
Matthias Klose (doko) wrote :

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) wrote :

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) wrote :

the file builds fine with the second patch

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".

Created attachment 28484
Hack patch

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

In , Doko-v (doko-v) wrote :

works with 4.7, fails with trunk

In , Mikpe (mikpe) wrote :

Also works with gcc-4.6.

In , Mikpe (mikpe) wrote :

The test case started failing with r189790:

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.

In , Doko-v (doko-v) wrote :

this patch is now on the 4.7 branch too.

Changed in gcc:
importance: Unknown → Medium
status: Unknown → New
Launchpad Janitor (janitor) wrote :

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

Changed in gcc-4.7 (Ubuntu):
status: New → Fix Released
Changed in gcc:
status: New → In Progress

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
 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.


Fixed on the trunk I suppose.


Are you planning on backporting this to 4.7 ?


Victor Chong (vchong) on 2013-12-24
Changed in gcc-linaro:
status: New → Confirmed

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

Changed in gcc-linaro:
assignee: nobody → Michael Collison (michael-collison)
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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