[Bug target/64348] New: Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC

[Bug target/64348] New: Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC

[amker at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6855 bytes --]

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

            Bug ID: 64348
           Summary: Case scal-to-vec1.c failed on arm-linux-gnueabi with
                    -fPIC
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: amker at gcc dot gnu.org

Case scal-to-vec1.c failed because of ICE on arm-linux-gnueabi with -fPIC.  The
compilation command line is:
./arm-none-linux-gnueabi-gcc scal-to-vec1.c -fno-diagnostics-show-caret
-fdiagnostics-color=never -O3 -S -fPIC -o ./scal-to-vec1.S -mcpu=cortex-a8/a9
-marm

Thumb mode is fine, processors like cortex-a7/a15 are fine.  The ICE info is
like below:
/home/binche01/work/oban-work/src/gcc/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c:
In function ‘main’:
/home/binche01/work/oban-work/src/gcc/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c:86:1:
internal compiler error: in split_reg, at lra-constraints.c:4879
0xbad893 split_reg
    /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:4879
0xbade33 split_if_necessary
    /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:4983
0xbafb13 inherit_in_ebb
    /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:5478
0xbb04fc lra_inheritance()
    /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:5639
0xb9914b lra(_IO_FILE*)
    /home/binche01/work/oban-work/src/gcc/gcc/lra.c:2303
0xb48738 do_reload
    /home/binche01/work/oban-work/src/gcc/gcc/ira.c:5402
0xb48b0e execute
    /home/binche01/work/oban-work/src/gcc/gcc/ira.c:5573

Gcc is configured as below:
--target=arm-none-linux-gnueabi
 --prefix=...
 --with-sysroot=...
 --disable-libssp
 --disable-libmudflap
 --enable-checking=yes
 --enable-languages=c,c++
 --with-gmp=...
 --with-mpfr=...
 --with-mpc=...
 --with-isl=...
 --with-cloog=...
 --disable-libgomp
 --with-arch=armv7-a

It is from thread https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01448.html

File this PR for tracking.
>From gcc-bugs-return-471057-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Dec 18 09:26:48 2014
Return-Path: <gcc-bugs-return-471057-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12668 invoked by alias); 18 Dec 2014 09:26:48 -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 12644 invoked by uid 48); 18 Dec 2014 09:26:43 -0000
From: "janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
Date: Thu, 18 Dec 2014 09:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: janus at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: janus at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64244-4-VQaYotA1U1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64244-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64244-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg02064.txt.bz2
Content-length: 509

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

--- Comment #15 from janus at gcc dot gnu.org ---
(In reply to Ondřej Čertík from comment #14)
> I tested it and it seems to be working! The code compiled with
> non_overridable on.

Great. Thanks for checking.


> There are run-time segfaults and array bounds mismatches in our code,
> that don't happen with ifort, so I will be slowly isolating those and
> reporting them.

That would be very helpful (please use separate PRs for those).
>From gcc-bugs-return-471058-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Dec 18 09:31:48 2014
Return-Path: <gcc-bugs-return-471058-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15221 invoked by alias); 18 Dec 2014 09:31:48 -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 15164 invoked by uid 48); 18 Dec 2014 09:31:45 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/64344] [5 Regression] [UBSAN] ICE with -fsanitize=float-cast-overflow [ICE in -fsanitize=float-cast-overflow]
Date: Thu, 18 Dec 2014 09:31:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-64344-4-I0wnvf2CGd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64344-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64344-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: 2014-12/txt/msg02065.txt.bz2
Content-length: 527

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id4297&actioníit
gcc5-pr64344.patch

Untested fix, but this is getting way too ugly.  Furthermore, e.g.
void
bar (void)
{
  static const int a = 0.5;
  static const int b = 1e234;
}
still fails with C.  Wonder what was the reason to instrument it so early,
supposedly to not miss conversions optimized away during folding, right?

[Bug target/64348] [5 Regression] Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ra
                 CC|                            |vmakarov at gcc dot gnu.org
   Target Milestone|---                         |5.0
            Summary|Case scal-to-vec1.c failed  |[5 Regression] Case
                   |on arm-linux-gnueabi with   |scal-to-vec1.c failed on
                   |-fPIC                       |arm-linux-gnueabi with
                   |                            |-fPIC

[Bug target/64348] [5 Regression] Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC

[amker at gcc dot gnu.org]

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

--- Comment #1 from amker at gcc dot gnu.org ---
IRA made below decision:

;; a299(r989,l0) conflicts: a57(r1696,l0) a177(r130,l0) a221(r131,l0)
a63(r1714,l0) a178(r822,l0) a224(r823,l0) a69(r1713,l0) a180(r815,l0)
a227(r816,l0) a75(r1712,l0) a182(r808,l0) a230(r809,l0) a81(r1711,l0)
a184(r801,l0) a233(r802,l0) a87(r1710,l0) a186(r794,l0) a236(r795,l0)
a93(r1709,l0) a188(r787,l0) a239(r788,l0) a100(r1708,l0) a190(r128,l0)
a191(r780,l0) a247(r781,l0) a284(r126,l0) a175(r125,l0) a14(r1706,l0)
a138(r141,l0) a139(r742,l0) a141(r737,l0) a143(r732,l0) a145(r727,l0)
a147(r722,l0) a149(r717,l0) a151(r139,l0) a152(r712,l0) a105(r1695,l0)
a291(r992,l0)
;;     total conflict hard regs: 0 1 12 14
;;     conflict hard regs: 0 1 12 14

Spilling a100r1708 for a299r989
Assigning 2 to a299r989

With ira dump like below:
  430: [sfp:SI-0x30]=r989:TI#0
  432: [r1706:SI+0x4]=r989:TI#4
  434: [r1706:SI+0x8]=r989:TI#8
  436: [r1706:SI+0xc]=r989:TI#12
  441: r0:DI=call [`__aeabi_idivmod'] argc:0
      REG_UNUSED r0:SI
      REG_CALL_DECL `__aeabi_idivmod'
      REG_EH_REGION 0xffffffff80000000
  437: r1007:SI=sign_extend(r989:TI#0)
      REG_DEAD r989:TI

lra needs to split r989 between 436 and 437 with call_save_p holds.  Since r989
is a register in TImode, the save/restore requires more than 2 instructions,
code in split_reg has:
  if (NEXT_INSN (save) != NULL_RTX)
    {
      lra_assert (! call_save_p);
      if (lra_dump_file != NULL)
    {
      fprintf
        (lra_dump_file,
         "      Rejecting split %d->%d resulting in > 2 %s save insns:\n",
         original_regno, REGNO (new_reg), call_save_p ? "call" : "");
      dump_rtl_slim (lra_dump_file, save, NULL, -1, 0);
      fprintf (lra_dump_file,
           "    ))))))))))))))))))))))))))))))))))))))))))))))))\n");
    }
      return false;
    }
  restore = emit_spill_move (false, new_reg, original_reg);
  if (NEXT_INSN (restore) != NULL_RTX)
    {
      lra_assert (! call_save_p);
      if (lra_dump_file != NULL)
    {
      fprintf (lra_dump_file,
           "    Rejecting split %d->%d "
           "resulting in > 2 %s restore insns:\n",
           original_regno, REGNO (new_reg), call_save_p ? "call" : "");
      dump_rtl_slim (lra_dump_file, restore, NULL, -1, 0);
      fprintf (lra_dump_file,
           "    ))))))))))))))))))))))))))))))))))))))))))))))))\n");
    }
      return false;
    }

It assumes that number of save/restore instructions for call_save_p registers
isn't larger than 2, which apparently no true in this case for r989:TI.

This can be fixed by splitting call_save_p register even it results in more
instruction, but I am not sure if it should be fixed before this code.

Also, we don't need to save/resotre all 16 bytes of r989 here, because only 4
bytes of them is live across the call.  Maybe lra can be improved for this
case, but that's another optimization issue.

[Bug target/64348] [5 Regression] Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Jan  9 06:19:32 2015
New Revision: 219375

URL: https://gcc.gnu.org/viewcvs?rev=219375&root=gcc&view=rev
Log:
2015-01-09  Kito Cheng  <kito@0xlab.org>

    PR rtl-optimization/64348
    * lra-constraints.c (split_reg): Fix caller-save store/restore
    instruction generation.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-constraints.c

[Bug target/64348] [5 Regression] Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed(?)

[Bug target/64348] [5 Regression] Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> Fixed(?)

Yes, thanks!
I forgot to close it.