From: Ramana Radhakrishnan <ramana.gcc@googlemail.com>
To: Tom de Vries <Tom_deVries@mentor.com>
Cc: Marcus Shawcroft <marcus.shawcroft@gmail.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
James Greenhalgh <james.greenhalgh@arm.com>
Subject: Re: [AARCH64, PATCH] Fix ICE in aarch64_float_const_representable_p
Date: Fri, 30 May 2014 08:20:00 -0000 [thread overview]
Message-ID: <CAJA7tRavx9z+EN-vWUi5Xnvn1E41cRzf1ksGLN=nfXSEpQHRkg@mail.gmail.com> (raw)
In-Reply-To: <53883DFB.6040204@mentor.com>
On Fri, May 30, 2014 at 9:14 AM, Tom de Vries <Tom_deVries@mentor.com> wrote:
> Marcus,
>
> when building for aarch64-linux-gnu with --enable-checking=yes,rtl, I run
> into the following error:
> ...
> In file included from src/libgcc/libgcc2.c:56:0:
> src/libgcc/libgcc2.c: In function ‘__floattisf’:
> src/libgcc/libgcc2.h:200:20: internal compiler error: RTL check: expected
> code 'const_double' and not mode 'VOID', have code 'const_double' and mode
> 'VOID' in aarch64_float_const_representable_p, at
> config/aarch64/aarch64.c:8481
> #define __NDW(a,b) __ ## a ## ti ## b
> ^
> src/libgcc/libgcc2.h:293:21: note: in expansion of macro ‘__NDW’
> #define __floatdisf __NDW(float,sf)
> ^
> src/libgcc/libgcc2.c:1569:14: note: in expansion of macro ‘__floatdisf’
> #define FUNC __floatdisf
> ^
> src/libgcc/libgcc2.c:1579:1: note: in expansion of macro ‘FUNC’
> FUNC (DWtype u)
> ^
> 0xc1a278 rtl_check_failed_code_mode(rtx_def const*, rtx_code, machine_mode,
> bool, char const*, int, char const*)
> src/gcc/rtl.c:833
> 0x1062b7b aarch64_float_const_representable_p(rtx_def*)
> src/gcc/config/aarch64/aarch64.c:8481
> 0x1052ae2 aarch64_rtx_costs
> src/gcc/config/aarch64/aarch64.c:5003
> 0x1059a9c aarch64_rtx_costs_wrapper
> src/gcc/config/aarch64/aarch64.c:5804
> 0xc38f1a rtx_cost(rtx_def*, rtx_code, int, bool)
> src/gcc/rtlanal.c:3878
> 0xb159a9 avoid_expensive_constant
> src/gcc/optabs.c:1389
> 0xb15ca9 expand_binop_directly
> src/gcc/optabs.c:1441
> 0xb161e7 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
> int, optab_methods)
> src/gcc/optabs.c:1568
> 0x87f27f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
> expand_modifier)
> src/gcc/expr.c:9200
> 0x87fe4b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
> src/gcc/expr.c:9388
> 0x879534 expand_expr_real(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
> src/gcc/expr.c:7921
> 0x79a720 expand_normal
> src/gcc/expr.h:471
> 0x79cdb3 do_jump_by_parts_greater
> src/gcc/dojump.c:741
> 0x79b682 do_jump_1(tree_code, tree_node*, tree_node*, rtx_def*, rtx_def*,
> int)
> src/gcc/dojump.c:280
> 0x79a8ce jumpifnot_1(tree_code, tree_node*, tree_node*, rtx_def*, int)
> src/gcc/dojump.c:138
> 0x700de4 expand_gimple_cond
> src/gcc/cfgexpand.c:2145
> 0x70ed7f expand_gimple_basic_block
> src/gcc/cfgexpand.c:5063
> 0x71189c execute
> src/gcc/cfgexpand.c:5803
> 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.
> ...
>
> We assert here during REAL_VALUE_FROM_CONST_DOUBLE because x has VOIDmode,
> which means it has integer rather than floating point type:
> ...
> bool
> aarch64_float_const_representable_p (rtx x)
> {
> /* This represents our current view of how many bits
> make up the mantissa. */
> int point_pos = 2 * HOST_BITS_PER_WIDE_INT - 1;
> int exponent;
> unsigned HOST_WIDE_INT mantissa, mask;
> REAL_VALUE_TYPE r, m;
> bool fail;
>
> if (!CONST_DOUBLE_P (x))
> return false;
>
> REAL_VALUE_FROM_CONST_DOUBLE (r, x);
> ...
>
> Attached patch fixes the ICE by handling the case that x is VOIDmode, and
> allows me to complete the build.
>
IIUC it would be better to shift the AArch64 port to
TARGET_SUPPORTS_WIDE_INT and not worry about x being VOIDmode at all.
In this case we should not have any const_double's containing
integers.
I have a couple of patches in testing that did this but with all the
other breakages in AArch64 and ARM land in the past couple of weeks I
have been unable to submit this.
regards
Ramana
> OK for trunk if build and test succeeds?
>
> I think the call site in aarch64_rtx_costs may need a separate fix.
>
> Thanks,
> - Tom
next prev parent reply other threads:[~2014-05-30 8:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-30 8:15 Tom de Vries
2014-05-30 8:20 ` Ramana Radhakrishnan [this message]
2014-06-01 10:04 ` Tom de Vries
2014-06-02 12:29 ` Marcus Shawcroft
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJA7tRavx9z+EN-vWUi5Xnvn1E41cRzf1ksGLN=nfXSEpQHRkg@mail.gmail.com' \
--to=ramana.gcc@googlemail.com \
--cc=Tom_deVries@mentor.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=james.greenhalgh@arm.com \
--cc=marcus.shawcroft@gmail.com \
--cc=ramrad01@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).