[Bug target/66258] New: compiling a stdarg function with arch +nofp generates an ICE

[Bug target/66258] New: compiling a stdarg function with arch +nofp generates an ICE

[wilson at gcc dot gnu.org]

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

            Bug ID: 66258
           Summary: compiling a stdarg function with arch +nofp generates
                    an ICE
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wilson at gcc dot gnu.org
  Target Milestone: ---

palantir:2187$ more tmp.c
#include <stdarg.h>

int
sub (int num, ...)
{
  va_list ap;
  int j;

  va_start (ap, num);
  j = va_arg (ap, int);
  va_end (ap);

  return j;
}
palantir:2188$ ./xgcc -B./ -O -S tmp.c -mcpu=cortex-a53+nofp
tmp.c: In function ‘sub’:
tmp.c:14:1: error: unrecognizable insn:
 }
 ^
(insn 86 9 87 2 (set (reg:DI 0 x0 [101])
        (truncate:DI (reg:TI 32 v0))) tmp.c:5 -1
     (nil))
tmp.c:14:1: internal compiler error: in extract_insn, at recog.c:2329
0xa32b9a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        ../../gcc-svn/gcc/rtl-error.c:110
0xa32bc9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ../../gcc-svn/gcc/rtl-error.c:118
0xa078e7 extract_insn(rtx_insn*)
        ../../gcc-svn/gcc/recog.c:2329
0xa07964 extract_insn_cached(rtx_insn*)
        ../../gcc-svn/gcc/recog.c:2220
0x79df7d cleanup_subreg_operands(rtx_insn*)
        ../../gcc-svn/gcc/final.c:3140
0xa05277 split_insn
        ../../gcc-svn/gcc/recog.c:2943
0xa09cc7 split_all_insns()
        ../../gcc-svn/gcc/recog.c:2997
0xa09d52 rest_of_handle_split_after_reload
        ../../gcc-svn/gcc/recog.c:3938
0xa09d52 execute
        ../../gcc-svn/gcc/recog.c:3967
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
palantir:2189$ 

The problem is that all of the FP move patterns in the aarch64.md file use
TARGET_FLOAT, which checks both -mgeneral-regs-only and architecture fp
support.  However, the stdarg code is only checking TARGET_GENERAL_REGS_ONLY. 
It needs to use TARGET_FLOAT instead.  There is the same problem in the
secondary reloads code and in the function value regno code.

Patch to be submitted shortly.
>From gcc-bugs-return-487128-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 23 02:22:48 2015
Return-Path: <gcc-bugs-return-487128-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 100946 invoked by alias); 23 May 2015 02:22: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 100908 invoked by uid 48); 23 May 2015 02:22:44 -0000
From: "asmwarrior at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/56926] Crash (without ICE) while compiling Boost.Math
Date: Sat, 23 May 2015 02:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: asmwarrior at gmail dot com
X-Bugzilla-Status: WAITING
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56926-4-MxH4Yt3Vqu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56926-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56926-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-05/txt/msg01968.txt.bz2
Content-length: 2287

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

--- Comment #14 from asmwarrior <asmwarrior at gmail dot com> ---
The bug can be seen when "-E" and "-fpch-preprocess" is used together to
generate a preprocessed file.
If I have a small pch file named "spch.h" and "spch.h.gch"(note the spch.h.gch
size is about 47M), and if I have a test.cpp like below:
------
#include "spch.h"

int main()
{
        int a;
        int b;
        int c;
        a++;
        b++;
}
------

Then, run the command:
g++.exe -v -E -Wall -fexceptions  -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0  -Winvalid-pch -include spch.h test.cpp
-fpch-preprocess -o xxx.ii -ftime-report

I will get a xxx.ii containing such contents:
------
# 1 "test.cpp"
# 1 "D:\\mingw-builds\\test-51//"
# 1 "<built-in>"
# 1 "<command-line>"
#pragma GCC pch_preprocess "./spch.h.gch"
# 1 "test.cpp"
# 1 "spch.h" 1
# 2 "test.cpp" 2

int main()
{
 int a;
 int b;
 int c;
 a++;
 b++;
}
------

You see, the line "#pragma GCC pch_preprocess "./spch.h.gch"" is generated
correctly, which means G++ load the pch file correctly. (That's what the
-fpch-preprocess option used for, see:
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html)

But if I use a big pch file "pch.h.gch", and run the similar command line like
above, I don't see any .ii file generated, which means G++ crashed before log
out the line "#pragma GCC pch_preprocess ...".

By reading the source code, I see that in gcc-4.9.2\gcc\c-family\c-ppoutput.c,
there is a function:

/* Load in the PCH file NAME, open on FD.  It was originally searched for
   by ORIG_NAME.  Also, print out a #include command so that the PCH
   file can be loaded when the preprocessed output is compiled.  */

static void
cb_read_pch (cpp_reader *pfile, const char *name,
             int fd, const char *orig_name ATTRIBUTE_UNUSED)
{
  c_common_read_pch (pfile, name, fd, orig_name);

  fprintf (print.outf, "#pragma GCC pch_preprocess \"%s\"\n", name);
  print.src_line++;
}

So, the bug happens before the fprintf() function, maybe inside the
c_common_read_pch function call.

I would like to see anyone can supply a debug version of 32bit cc1plus.exe, so
that I can hunt the bug further under GDB, because building the whole gcc tool
chain is too difficult for me.

[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed, happens with grub.

[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE

[wilson at gcc dot gnu.org]

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

--- Comment #2 from Jim Wilson <wilson at gcc dot gnu.org> ---
Author: wilson
Date: Wed Jun  3 00:46:19 2015
New Revision: 224054

URL: https://gcc.gnu.org/viewcvs?rev=224054&root=gcc&view=rev
Log:
gcc/
        PR target/66258
        * config/aarch64/aarch64.c (aarch64_function_value_regno_p): Change
        !TARGET_GENERAL_REGS_ONLY to TARGET_FLOAT.
        (aarch64_secondary_reload): Likewise
        (aarch64_expand_builtin_va_start): Change TARGET_GENERAL_REGS_ONLY
        to !TARGET_FLOAT.
        (aarch64_gimplify_va_arg_expr, aarch64_setup_incoming_varargs):
        Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/aarch64/aarch64.c

[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE

[wilson at gcc dot gnu.org]

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

--- Comment #3 from Jim Wilson <wilson at gcc dot gnu.org> ---
The patch doesn't completely fix grub, because grub is trying to compile FP
code with +nofp, which can't work without a soft-float ABI, which we don't
have.  So grub gets an error instead of an ICE with the patch.  However,
apparently the Aarch64 UEFI spec requires FP, so grub can be changed to stop
using +nofp.

[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE

[wilson at gcc dot gnu.org]

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

Jim Wilson <wilson at gcc dot gnu.org> changed:

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

--- Comment #4 from Jim Wilson <wilson at gcc dot gnu.org> ---
Patch approved and checked in on mainline.

[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Do you plan to backport this to gcc-5-branch?

[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> Do you plan to backport this to gcc-5-branch?

As I mentioned this is really needed to compile grub so if it is not back
ported, you can't compile a full Linux distro using gcc 5 at all.

[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE

[jim.wilson at linaro dot org]

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

--- Comment #7 from jim.wilson at linaro dot org ---
On Sat, Jun 6, 2015 at 2:02 AM, pinskia at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
>> Do you plan to backport this to gcc-5-branch?

I didn't realize it was broken on the gcc-5 release branch.  I only
checked mainline.  I can check the gcc-5 release branch and backport,
but I'm a little out of touch, and not sure what approval I need for
the backport.  If I can't backport to the FSF gcc-5 release branch for
some reason, I can backport to the linaro gcc-5 branch instead.

I've also discovered that I got a little bad info on grub.  The person
who tried -mgeneral-regs-only accidentally compiled linux user space
with that option, which is why the build with it failed.  Grub itself
apparently doesn't use FP.  So with correct makefiles, changing grub
to use -mgeneral-regs-only instead of +nofp does solve the problem.
Since the linux kernel already uses -mgeneral-regs-only, and this
option is (presumably) not broken in gcc-5, I believe that grub will
be changed to use -mgeneral-regs-only to match the kernel, in which
case a build will work with gcc-5.  There is still the problem that
grub versions before the change was made (this week? last week?) will
still fail with gcc-5 unless the patch is backported, or users make
local mods to grub to use -mgeneral-regs-only instead of +nofp.

Jim

[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE

[wilson at gcc dot gnu.org]

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

--- Comment #9 from Jim Wilson <wilson at gcc dot gnu.org> ---
Author: wilson
Date: Tue Jun 16 20:11:41 2015
New Revision: 224538

URL: https://gcc.gnu.org/viewcvs?rev=224538&root=gcc&view=rev
Log:
gcc/
        Backport from mainline
        2015-06-02  Jim Wilson  <jim.wilson@linaro.org>

        PR target/66258
        * config/aarch64/aarch64.c (aarch64_function_value_regno_p): Change
        !TARGET_GENERAL_REGS_ONLY to TARGET_FLOAT.
        (aarch64_secondary_reload): Likewise
        (aarch64_expand_builtin_va_start): Change TARGET_GENERAL_REGS_ONLY
        to !TARGET_FLOAT.
        (aarch64_gimplify_va_arg_expr, aarch64_setup_incoming_varargs):
        Likewise.

Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/config/aarch64/aarch64.c