Bug 47246 - [4.6 Regression] Invalid immediate offset for Thumb VFP store regression
Summary: [4.6 Regression] Invalid immediate offset for Thumb VFP store regression
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: 4.6.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
: 47245 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-01-10 16:15 UTC by Ian Bolton
Modified: 2011-02-02 17:51 UTC (History)
4 users (show)

See Also:
Host: arm-linux-gnueabi
Target: arm-linux-gnueabi
Build: arm-linux-gnueabi
Known to work:
Known to fail:
Last reconfirmed: 2011-01-15 15:50:48


Attachments
This is the preprocessed source that shows the issue (359 bytes, text/plain)
2011-01-10 16:15 UTC, Ian Bolton
Details
Demonstrates the problem instruction, on line 37 (467 bytes, text/plain)
2011-01-10 16:17 UTC, Ian Bolton
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Bolton 2011-01-10 16:15:00 UTC
Created attachment 22939 [details]
This is the preprocessed source that shows the issue

The following patch, which went into trunk as revision 168045, has made it possible for gcc to generate invalid offsets for some VFP stores:

  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01349.html

The range -1024 to +1024 is ok for 's' co-processor registers, but not for generic 'r' registers.

The attached preprocessed source can be made to show the issue by compiling as follows:

  gcc -O3 -mthumb mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16 besttry.i --save-temps

The error caused is this:

  /tmp/ccxviNhV.s: Assembler messages:
  /tmp/ccxviNhV.s:37: Error: offset out of range

I have attached the produced besttry.s.

In the short-term, I suggest that we limit the negative offset, to be able to cover the case where VFP store ends up using general registers.  I do not know how we could allow a larger negative offset for the 's' registers, when it is not known until later what type of register will get allocated.
Comment 1 Ian Bolton 2011-01-10 16:17:37 UTC
Created attachment 22940 [details]
Demonstrates the problem instruction, on line 37
Comment 2 Eric Botcazou 2011-01-12 11:59:57 UTC
More of a target problem I think.
Comment 3 Richard Earnshaw 2011-01-14 17:37:14 UTC
*** Bug 47245 has been marked as a duplicate of this bug. ***
Comment 4 Ramana Radhakrishnan 2011-01-15 15:50:48 UTC
Confirmed : For the record the command line options are :

-mcpu=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=softfp -O3 -mthumb


cheers
Ramana
Comment 5 Chung-Lin Tang 2011-01-26 03:01:49 UTC
Author: cltang
Date: Wed Jan 26 03:01:44 2011
New Revision: 169271

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169271
Log:
2011-01-26  Chung-Lin Tang  <cltang@codesourcery.com>

	PR target/47246
	* config/arm/arm.c (thumb2_legitimate_index_p): Change the
	lower bound of the allowed Thumb-2 coprocessor load/store
	index range to -256. Add explaining comment.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/arm/arm.c
Comment 6 Jakub Jelinek 2011-01-27 16:39:41 UTC
Assuming this is fixed now.
Comment 7 Ian Bolton 2011-01-27 16:51:41 UTC
(In reply to comment #6)
> Assuming this is fixed now.

Yes, I can use trunk to run the whole of Spec2K for -O3 -mthumb without errors.
Comment 8 Diego Novillo 2011-02-02 17:51:01 UTC
Author: dnovillo
Date: Wed Feb  2 17:50:47 2011
New Revision: 169605

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169605
Log:
2011-01-26  Chung-Lin Tang  <cltang@codesourcery.com>

	PR target/47246
	* config/arm/arm.c (thumb2_legitimate_index_p): Change the
	lower bound of the allowed Thumb-2 coprocessor load/store
	index range to -256. Add explaining comment.

Modified:
    branches/google/integration/gcc/ChangeLog
    branches/google/integration/gcc/config/arm/arm.c