This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, i386]: Fix PR82725, ICE in change_address_1, at emit-rtl.c
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Sun, 29 Oct 2017 09:55:56 -0700
- Subject: Re: [PATCH, i386]: Fix PR82725, ICE in change_address_1, at emit-rtl.c
- Authentication-results: sourceware.org; auth=none
- References: <CAFULd4YM54ZQ=Vxbwq8wZQDhfZAiFg+8WhO-Gb8A1svEBRm7AQ@mail.gmail.com>
On Sun, Oct 29, 2017 at 12:38 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> Hello!
>
> split_double_mode tries to split TImode address:
>
> (insn 10 2 11 2 (set (reg/i:TI 0 ax)
> (mem/u/c:TI (const:DI (unspec:DI [
> (symbol_ref:DI ("_ZZ7tempDirvE5cache") [flags 0x2a])
> ] UNSPEC_NTPOFF)) [1 cache+0 S16 A64 AS1]))
> to:
>
> (const:DI (unspec:DI [
> (symbol_ref:DI ("_ZZ7tempDirvE5cache") [flags 0x2a])
> ] UNSPEC_NTPOFF))
>
> and
>
> (const:DI (plus:DI (unspec:DI [
> (symbol_ref:DI ("_ZZ7tempDirvE5cache") [flags 0x2a])
> ] UNSPEC_NTPOFF)
> (const_int 8 [0x8])))
>
> but the later RTX is not recognized as a valid address.
>
> Attached patch allows offsetted UNSPEC_DTPOFF/UNSPEC_NTPOFF
> relocations in legitimate_pic_address_disp_p. In fact, these are
> already allowed in x86_64_immediate_operand, with the immediate
> limited to SImode values.
>
> 2017-10-29 Uros Bizjak <ubizjak@gmail.com>
>
> PR target/82725
> * config/i386/i386.c (legitimate_pic_address_disp_p): Allow
> UNSPEC_DTPOFF and UNSPEC_NTPOFF with SImode immediate offset.
>
> testsuite/ChangeLog:
>
> 2017-10-29 Uros Bizjak <ubizjak@gmail.com>
>
> PR target/82725
> * g++.dg/pr82725.C: New test.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>
> Jakub, HJ, do you have any comments on the patch?
>
> Uros.
2 questions:
1. Why isn't legitimate_pic_address_disp_p a static function?
2. Should we add a legitimate_address_disp_p function to
handle both PIC and non-PIC displacement which is also
used by x86_64_immediate_operand?
--
H.J.