[Bug target/63304] New: Aarch64 pc-relative load offset out of range

[Bug target/63304] New: Aarch64 pc-relative load offset out of range

[venkataramanan.kumar at amd dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

            Bug ID: 63304
           Summary: Aarch64 pc-relative load offset out of range
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: venkataramanan.kumar at amd dot com

Constant literal table is kept at large offset, resulting in pc-relative load
offset out of range.

aarch64-none-linux-gnu-gcc x.c 
/tmp/ccrOQLEb.s: Assembler messages:
/tmp/ccrOQLEb.s:10: Error: pc-relative load offset out of range

[Bug target/63304] Aarch64 pc-relative load offset out of range

[venkataramanan.kumar at amd dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #1 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
Created attachment 33515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33515&action=edit
Attached test case

[Bug target/63304] Aarch64 pc-relative load offset out of range

[venkataramanan.kumar at amd dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #2 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
Marcus, can you please assign it to me if it is confirmed.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |aarch64
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-19
     Ever confirmed|0                           |1

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

>From .expand:
(insn 5 4 6 (set (reg:DF 75)
        (mem/u/c:DF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0  S8 A64]))
/home/pinskia/Downloads/x.c:7 -1
     (nil))

Note next time please use macros to create your testcase, it is ok sometimes to
use non preprocessed source

[Bug target/63304] Aarch64 pc-relative load offset out of range

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #4 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
I see this as a theoretical problem that's unlikely to ever manifest itself
with real code (functions generating .5 million instructions would take
insanely long to compile in real life).

Unless you can show some *real* code that exhibits this problem I propose we
don't try to fix this; it's just a limit on the compiler.

We have bigger problems to worry about.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[venkataramanan.kumar at amd dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #5 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
We got inspired by this bug.
https://bugs.linaro.org/show_bug.cgi?id=400 
It happens at -O0 now.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5
             Status|RESOLVED                    |NEW
         Resolution|WONTFIX                     |---
           Assignee|unassigned at gcc dot gnu.org      |venkataramanan.kumar at amd dot co
                   |                            |m
           Severity|normal                      |minor

--- Comment #6 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
OK.  But I still wouldn't loose much sleep over it.  It wouldn't surprise me
that if you turn the optimizer on it then blows up by using too much memory...

[Bug target/63304] Aarch64 pc-relative load offset out of range

[venkataramanan.kumar at amd dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

Venkataramanan <venkataramanan.kumar at amd dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |doko at ubuntu dot com
         Resolution|---                         |WONTFIX

--- Comment #7 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
Ok I am closing this as wont fix now. Checked with Mitthias who reported the
problem to us and he is fine building it with -O2.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
         Resolution|WONTFIX                     |---

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This code is still valid and really should be fixed; maybe not today or for GCC
5 or GCC 6 but it is still a bug.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Actually this is much worse than what is mentioned here.  Having the constant
pool be part of the .text section really does not work if the alignment of the
constants are smaller than 4 byte aligned.  The assembler rejects the debugging
info as the end label of the text section is not 4 byte aligned.
I am working on fixing this bug and the bug dealing with the constant pool in
the text section (which is wrong and is not shared between translational units
really).

[Bug target/63304] Aarch64 pc-relative load offset out of range

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |assemble-failure
           Severity|minor                       |normal

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
More point is with LTO you can get this even with optimization turned on.  If
the text section is big enough.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[david.abdurachmanov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

David Abdurachmanov <david.abdurachmanov at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.abdurachmanov at gmail dot c
                   |                            |om

--- Comment #11 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
I believe, I hit this issue with OpenLoops package on AArch64, while it works
fine on x86_64.

It shows up on 3 of Fortran files:
scons: *** [process_obj/pplljjj/loop_pplljjj_eexddxggg_1_qp.os] Error 1
scons: *** [process_obj/pplljjj/loop_pplljjj_eexuuxggg_1_qp.os] Error 1
scons: *** [process_obj/pplljjj/loop_pplljjj_eexbbxggg_1_qp.os] Error 1

I get "Error: pc-relative load offset out of range" 864 times.

Tested with GCC 4.9.1 and binutils 2.24.

I also looked into f9edeb70961d404caac5a849b0783c53228ddf62 / 213078, with it
applied on top it gets worse, i.e. more files are affected. From 864 it
increases to 1392 errors.

This particular library (pplljjj) is 158MB on x86_64. Most of it (153MB)
belongs to .text section.

The code must be compiled with -O0 otherwise machines have hard time handling
it:

gfortran: internal compiler error: Killed (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

@Andrew,
I am happy to test your patches if necessary.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[david.abdurachmanov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #12 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
I decided to re-enable -Os for OpenLoops. Then use powerful hardware with
32-physical-cores (x86_64) and 0.5TB of RAM to see if I could get lucky. Fired
up QEMU user mode with Fedora for AArch64 chroot for compiling.

It did resolve some of failures, but not everything. I have seen processes
going as far as 25+GB of RSS and taking hours to finish. This is the reason
package is compiled with -O0.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[david.abdurachmanov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #13 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
Created attachment 34416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34416&action=edit
31-lines, minimal testcase

I am adding 31-lines minimal testcase. Should be good enough for GCC testsuite.

$ gcc -O0 -c pr63304-testcase.c
/tmp/ccKdBqsL.s: Assembler messages:
/tmp/ccKdBqsL.s:58: Error: pc-relative load offset out of range
/tmp/ccKdBqsL.s:62: Error: pc-relative load offset out of range

Yesterday I looked into RTL output and assembly of some failures for OpenLoops.
The function was 400+K lines in assembly. On x86_64 it was something 180+K
lines of assembly and ~1.3MB for function body size.

I can confirm that offset is above 1MB mark and it was trying to load
__float128/long double to q1 from constant pool for passing to `addtf3`.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|pinskia at gcc dot gnu.org         |unassigned at gcc dot gnu.org

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Not working on this any time soon.  But someone from ARM really should look
into fixing this as it blocks standard C/C++ code from HPC and distros.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[wdijkstr at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

Wilco <wdijkstr at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wdijkstr at arm dot com

--- Comment #17 from Wilco <wdijkstr at arm dot com> ---
Well there seem to be 2 ways to address this:

* If a function is huge, emit literals as const data. This enables the use of
anchors and sharing of literals across all functions in a compilation unit.

* Reserve a register in the adr/ldr literal patterns and add a 2-instruction
sequence using adrp when out of range. Ideally the register should only be
reserved if a function is huge.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |ramana at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |ramana at gcc dot gnu.org

--- Comment #18 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
I'm taking a look into this.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #19 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Ramana Radhakrishnan from comment #18)
> I'm taking a look into this.

RFC here - https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02258.html

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #20 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Ramana Radhakrishnan from comment #19)
> (In reply to Ramana Radhakrishnan from comment #18)
> > I'm taking a look into this.
> 
> RFC here - https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02258.html

David - can you see if this works for you ?

regards
Ramana

[Bug target/63304] Aarch64 pc-relative load offset out of range

[david.abdurachmanov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #21 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
I am on vacations now, but I already marked this on my TODO list. Once I find a
free time slot I will give it a spin. I will try to report in a few days.

BTW, I will also show up at GNU Tools Cauldron 2015.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #22 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to David Abdurachmanov from comment #21)
> I am on vacations now, but I already marked this on my TODO list. Once I
> find a free time slot I will give it a spin. I will try to report in a few
> days.
> 
> BTW, I will also show up at GNU Tools Cauldron 2015.

I must also add that this patch is a pre-requisite for the appropriate
iterators to be available.

https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02074.html

and this may need some rebasing after Alan's latest patches to handle fp16.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[david.abdurachmanov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #23 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
GCC trunk
  r226676
  or 15af172f2a0ea281969e3105da9f9bb100097c7d from
git://gcc.gnu.org/git/gcc.git
  Date:   Thu Aug 6 14:26:18 2015 +0000)

Rebased and applied:

  https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02074.html
  https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02258.html

binutils trunk
  f0ce0d3a331129309a46a6a9ac85fce35acae72b from
git://sourceware.org/git/binutils-gdb.git
  Date:   Thu Jul 23 16:01:01 2015 +0100)

Rebases and applied:
  https://sourceware.org/ml/binutils/2015-07/msg00137.html

$ gcc -dumpversion
6.0.0
$ ld --version
GNU ld (GNU Binutils) 2.25.51.20150806

I __successfully__ compiled OpenLoops 1.1.1 and MCFM 6.3 packages.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #24 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Author: ramana
Date: Fri Sep 11 09:44:26 2015
New Revision: 227679

URL: https://gcc.gnu.org/viewcvs?rev=227679&root=gcc&view=rev
Log:
Remove separate movtf pattern - Use an iterator for all FP modes.

movtf is unnecessary as a separate expander. Move this to be with
the standard scalar floating point expanders.

Achieved by adding a new iterator and then using the same.

Tested cross aarch64-none-elf and no regressions.

Rebased version from https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00767.html


2015-09-10  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

        PR target/63304
        * config/aarch64/aarch.md (mov<mode>:GPF_F16): Use GPF_TF_F16.
        (movtf): Delete.
        * config/aarch64/iterators.md (GPF_TF_F16): New.
        (GPF_F16): Delete.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/aarch64/aarch64.md
    trunk/gcc/config/aarch64/iterators.md

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #25 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Author: ramana
Date: Mon Sep 14 13:16:59 2015
New Revision: 227748

URL: https://gcc.gnu.org/viewcvs?rev=227748&root=gcc&view=rev
Log:
[AArch64] Handle literal pools for functions > 1 MiB in size.


This patch fixes the issue in PR63304 where we have
functions that are > 1MiB. The idea is to use adrp / ldr or adrp / add
instructions to address the literal pools under the use of a command line
option. I would like to turn this on by default on trunk but keep this
disabled by default for the release branches in order to get some
serious testing for this feature while it bakes on trunk.

As a follow-up I would like to try and see if estimate_num_insns or
something else can give us a heuristic to turn this on for "large" functions.
After all the number of incidences of this are quite low in real life,
so may be we should look to restrict this use as much as possible on the
grounds that this code generation implies an extra integer register for
addressing for every floating point and vector constant and I don't think
that's great in code that already may have high register pressure.

Tested on aarch64-none-elf with no regressions. A previous
version was bootstrapped and regression tested.

Applied to trunk.

regards
Ramana

2015-09-14  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

        PR target/63304
        * config/aarch64/aarch64.c (aarch64_expand_mov_immediate): Handle
        nopcrelative_literal_loads.
        (aarch64_classify_address): Likewise.
        (aarch64_constant_pool_reload_icode): Define.
        (aarch64_secondary_reload): Handle secondary reloads for
        literal pools.
        (aarch64_override_options): Handle nopcrelative_literal_loads.
        (aarch64_classify_symbol): Handle nopcrelative_literal_loads.
        * config/aarch64/aarch64.md
(aarch64_reload_movcp<GPF_TF:mode><P:mode>):
        Define.
        (aarch64_reload_movcp<VALL:mode><P:mode>): Likewise.
        * config/aarch64/aarch64.opt (mpc-relative-literal-loads): New option.
        * config/aarch64/predicates.md (aarch64_constant_pool_symref): New
        predicate.
        * doc/invoke.texi (mpc-relative-literal-loads): Document.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/aarch64/aarch64.c
    trunk/gcc/config/aarch64/aarch64.md
    trunk/gcc/config/aarch64/aarch64.opt
    trunk/gcc/config/aarch64/iterators.md
    trunk/gcc/config/aarch64/predicates.md
    trunk/gcc/doc/invoke.texi

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #26 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Author: ramana
Date: Fri Oct  9 10:58:06 2015
New Revision: 228644

URL: https://gcc.gnu.org/viewcvs?rev=228644&root=gcc&view=rev
Log:
[AArch64] Handle literal pools for functions > 1 MiB in size.


This patch fixes the issue in PR63304 where we have
functions that are > 1MiB. The idea is to use adrp / ldr or adrp / add
instructions to address the literal pools under the use of a command line
option. I would like to turn this on by default on trunk but keep this
disabled by default for the release branches in order to get some
serious testing for this feature while it bakes on trunk.

As a follow-up I would like to try and see if estimate_num_insns or
something else can give us a heuristic to turn this on for "large" functions.
After all the number of incidences of this are quite low in real life,
so may be we should look to restrict this use as much as possible on the
grounds that this code generation implies an extra integer register for
addressing for every floating point and vector constant and I don't think
that's great in code that already may have high register pressure.

Tested on aarch64-none-elf with no regressions. A previous
version was bootstrapped and regression tested.

Applied to trunk.

regards
Ramana

2015-09-14  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

        PR target/63304
        * config/aarch64/aarch64.c (aarch64_expand_mov_immediate): Handle
        nopcrelative_literal_loads.
        (aarch64_classify_address): Likewise.
        (aarch64_constant_pool_reload_icode): Define.
        (aarch64_secondary_reload): Handle secondary reloads for
        literal pools.
        (aarch64_override_options): Handle nopcrelative_literal_loads.
        (aarch64_classify_symbol): Handle nopcrelative_literal_loads.
        * config/aarch64/aarch64.md
(aarch64_reload_movcp<GPF_TF:mode><P:mode>):
        Define.
        (aarch64_reload_movcp<VALL:mode><P:mode>): Likewise.
        * config/aarch64/aarch64.opt (mpc-relative-literal-loads): New option.
        * config/aarch64/predicates.md (aarch64_constant_pool_symref): New
        predicate.
        * doc/invoke.texi (mpc-relative-literal-loads): Document.


Added:
    trunk/gcc/testsuite/gcc.target/arm/pr67366.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimple-fold.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/lib/target-supports.exp

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #27 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Ramana Radhakrishnan from comment #26)
> Author: ramana
> Date: Fri Oct  9 10:58:06 2015
> New Revision: 228644
> 
> URL: https://gcc.gnu.org/viewcvs?rev=228644&root=gcc&view=rev
> Log:
> [AArch64] Handle literal pools for functions > 1 MiB in size.
>     
> 
> This patch fixes the issue in PR63304 where we have
> functions that are > 1MiB. The idea is to use adrp / ldr or adrp / add
> instructions to address the literal pools under the use of a command line
> option. I would like to turn this on by default on trunk but keep this
> disabled by default for the release branches in order to get some
> serious testing for this feature while it bakes on trunk.
> 
> As a follow-up I would like to try and see if estimate_num_insns or
> something else can give us a heuristic to turn this on for "large" functions.
> After all the number of incidences of this are quite low in real life,
> so may be we should look to restrict this use as much as possible on the
> grounds that this code generation implies an extra integer register for
> addressing for every floating point and vector constant and I don't think
> that's great in code that already may have high register pressure.
> 
> Tested on aarch64-none-elf with no regressions. A previous
> version was bootstrapped and regression tested.
> 
> Applied to trunk.
> 
> regards
> Ramana
> 
> 2015-09-14  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>
> 
>     	PR target/63304
>     	* config/aarch64/aarch64.c (aarch64_expand_mov_immediate): Handle
>     	nopcrelative_literal_loads.
>     	(aarch64_classify_address): Likewise.
>     	(aarch64_constant_pool_reload_icode): Define.
>     	(aarch64_secondary_reload): Handle secondary reloads for
>     	literal pools.
>     	(aarch64_override_options): Handle nopcrelative_literal_loads.
>     	(aarch64_classify_symbol): Handle nopcrelative_literal_loads.
>     	* config/aarch64/aarch64.md (aarch64_reload_movcp<GPF_TF:mode><P:mode>):
>     	Define.
>     	(aarch64_reload_movcp<VALL:mode><P:mode>): Likewise.
>     	* config/aarch64/aarch64.opt (mpc-relative-literal-loads): New option.
>     	* config/aarch64/predicates.md (aarch64_constant_pool_symref): New
>     	predicate.
>     	* doc/invoke.texi (mpc-relative-literal-loads): Document.
> 
> 
> Added:
>     trunk/gcc/testsuite/gcc.target/arm/pr67366.c
> Modified:
>     trunk/gcc/ChangeLog
>     trunk/gcc/gimple-fold.c
>     trunk/gcc/testsuite/ChangeLog
>     trunk/gcc/testsuite/lib/target-supports.exp

This commit really was for PR67366.. Copied wrong text into the commit message.
>From gcc-bugs-return-499087-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 09 11:07:28 2015
Return-Path: <gcc-bugs-return-499087-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 62021 invoked by alias); 9 Oct 2015 11:07:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 61957 invoked by uid 48); 9 Oct 2015 11:07:23 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number
Date: Fri, 09 Oct 2015 11:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67192-4-FTy1kTJth8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67192-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67192-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-10/txt/msg00642.txt.bz2
Content-length: 370

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg192

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
The "simpler" progression seems to be to remove code like

  if (CAN_HAVE_LOCATION_P (t) && code != LABEL_EXPR)
    {
      if (!EXPR_HAS_LOCATION (t))
        SET_EXPR_LOCATION (t, input_location);
    }

esp. code using input_location "delayed".

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #28 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Author: ramana
Revision: 228644
Modified property: svn:log

Modified: svn:log at Fri Oct  9 11:08:05 2015
------------------------------------------------------------------------------
--- svn:log (original)
+++ svn:log Fri Oct  9 11:08:05 2015
@@ -1,45 +1,43 @@
-[AArch64] Handle literal pools for functions > 1 MiB in size.
-    
+[PATCH PR target/67366 2/2] [gimple-fold.c] Support movmisalign optabs in
gimple-fold.c

-This patch fixes the issue in PR63304 where we have
-functions that are > 1MiB. The idea is to use adrp / ldr or adrp / add
-instructions to address the literal pools under the use of a command line
-option. I would like to turn this on by default on trunk but keep this
-disabled by default for the release branches in order to get some
-serious testing for this feature while it bakes on trunk.
+This patch by Richard allows for movmisalign optabs to be supported
+in gimple-fold.c. This caused a bit of pain in the testsuite with
strlenopt-8.c
+in conjunction with the ARM support for movmisalign_optabs as the test
+was coded up to do different things depending on whether the target
+supported misaligned access or not. However now with unaligned access
+being allowed for different levels of the architecture in the arm backend,
+the concept of the helper function non_strict_align mapping identically
+to the definition of STRICT_ALIGNMENT disappears.

-As a follow-up I would like to try and see if estimate_num_insns or
-something else can give us a heuristic to turn this on for "large" functions.
-After all the number of incidences of this are quite low in real life,
-so may be we should look to restrict this use as much as possible on the
-grounds that this code generation implies an extra integer register for
-addressing for every floating point and vector constant and I don't think
-that's great in code that already may have high register pressure.
+Adjusted thusly for ARM. The testsuite/lib changes were tested with an
+arm-none-eabi multilib that included architecture variants that did not
+support unaligned access and architecture variants that did.

-Tested on aarch64-none-elf with no regressions. A previous
-version was bootstrapped and regression tested.
+The testing matrix for this patch was:

-Applied to trunk.
+1. x86_64 bootstrap and regression test - no regressions.
+2. armhf bootstrap and regression test - no regressions.
+3. arm-none-eabi cross build and regression test for

-regards
-Ramana
+{-marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp}
+{-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard}
+{-marm/-mcpu=arm7tdmi/-mfloat-abi=soft}
+{-mthumb/-mcpu=arm7tdmi/-mfloat-abi=soft}

-2015-09-14  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>
+with no regressions.

-       PR target/63304
-       * config/aarch64/aarch64.c (aarch64_expand_mov_immediate): Handle
-       nopcrelative_literal_loads.
-       (aarch64_classify_address): Likewise.
-       (aarch64_constant_pool_reload_icode): Define.
-       (aarch64_secondary_reload): Handle secondary reloads for
-       literal pools.
-       (aarch64_override_options): Handle nopcrelative_literal_loads.
-       (aarch64_classify_symbol): Handle nopcrelative_literal_loads.
-       * config/aarch64/aarch64.md
(aarch64_reload_movcp<GPF_TF:mode><P:mode>):
-       Define.
-       (aarch64_reload_movcp<VALL:mode><P:mode>): Likewise.
-       * config/aarch64/aarch64.opt (mpc-relative-literal-loads): New option.
-       * config/aarch64/predicates.md (aarch64_constant_pool_symref): New
-       predicate.
-       * doc/invoke.texi (mpc-relative-literal-loads): Document.
+Ok to apply ?

+2015-10-09  Richard Biener  <rguenth@suse.de>
+
+       PR target/67366
+       * gimple-fold.c (optabs-query.h): Include
+       (gimple_fold_builtin_memory_op): Allow unaligned stores
+       when movmisalign_optabs are available.
+
+2015-10-09  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>
+
+       PR target/67366
+       * lib/target-supports.exp (check_effective_target_non_strict_align):
+       Adjust for arm*-*-*.
+       * gcc.target/arm/pr67366.c: New test.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #29 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Author: ramana
Date: Thu Oct 22 04:26:50 2015
New Revision: 229160

URL: https://gcc.gnu.org/viewcvs?rev=229160&root=gcc&view=rev
Log:
[Patch AArch64 63304] Fix issue with global state.


Jiong pointed out privately that there was a thinko
in the way in which the global state was being
set and reset. I don't like adding such
global state but ....


2015-10-22  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

        PR target/63304
        * config/aarch64/aarch64.c (aarch64_nopcrelative_literal_loads): New.
        (aarch64_expand_mov_immediate): Use aarch64_nopcrelative_literal_loads.
        (aarch64_classify_address): Likewise.
        (aarch64_secondary_reload): Likewise.
        (aarch64_override_options_after_change_1): Adjust.
        * config/aarch64/aarch64.md
(aarch64_reload_movcp<GPF_TF:mode><P:mode>):
        Use aarch64_nopcrelative_literal_loads.
        (aarch64_reload_movcp<VALL:mode><P:mode>): Likewise.
        * config/aarch64/aarch64-protos.h (aarch64_nopcrelative_literal_loads): 
        Declare

2015-10-22  Jiong Wang  <jiong.wang@arm.com>
            Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

        PR target/63304
        * gcc.target/aarch64/pr63304_1.c: New test.

Added:
    trunk/gcc/testsuite/gcc.target/aarch64/pr63304_1.c
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/testsuite/ChangeLog