This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [AArch64] Fix ICEs in aarch64_print_operand_internal (PR target/83335)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>, Christophe Lyon <christophe dot lyon at linaro dot org>, gcc-patches at gcc dot gnu dot org, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, nd <nd at arm dot com>, richard dot sandiford at linaro dot org
- Date: Tue, 12 Dec 2017 08:50:56 +0100
- Subject: Re: [AArch64] Fix ICEs in aarch64_print_operand_internal (PR target/83335)
- Authentication-results: sourceware.org; auth=none
- References: <87r2s9awha.fsf@linaro.org> <20171207093108.GA35729@arm.com> <CAKdteOZootDp6jhgROfD_9=V4i7w9-Zy__o4eLWv5d90jUTnQw@mail.gmail.com> <87r2s519yo.fsf@linaro.org> <CAKdteOZO8DH7oxhnzJuX4D7qD41-xGkj03Eh-SMHsqaN2G6y=A@mail.gmail.com> <20171211173304.GQ2353@tucnak> <87shcgqxe6.fsf@linaro.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Dec 12, 2017 at 06:21:37AM +0000, Richard Sandiford wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> > Hi!
> >
> > On Fri, Dec 08, 2017 at 08:10:08PM +0100, Christophe Lyon wrote:
> >> >> Can you check?
> >> >
> >> > I think that's a separate preexisting problem. Could you file a PR?
> >> >
> >>
> >> Sure, I filed:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83335
> >>
> >> > Personally I'd just remove the assert, but I'm guessing that wouldn't
> >> > be acceptable...
> >
> > So, I think either we can return false instead of dying on the assertion,
> > but then it will emit output_addr_const and often just silently emit it
> > without diagnosing it (first patch), or just call output_operand_lossage
> > there, which will ICE except for inline asm, where it will error.
> > It is true there is no code provided, but output_addr_const wouldn't
> > provide that either:
> > default:
> > if (targetm.asm_out.output_addr_const_extra (file, x))
> > break;
> >
> > output_operand_lossage ("invalid expression as operand");
> > in final.c.
>
> I think the testcase is valid even for ILP32, so the first sounds better
> to me.
I think it is not valid to print "X" constraint operand in any way, because
"X" operand can be anything. All we need to make sure is that we don't ICE
on it if in inline asm. The purpose of "X" is for operands that aren't
needed at all, or are needed just to denote they are read or written through
other means. If you look at the testsuite, no other test but
aarch64/asm-{2,3}.c attempts to print "X" operads.
Jakub