This is the mail archive of the
mailing list for the GCC project.
Re: gcc torture test pr52286.c
- From: Michael Matz <matz at suse dot de>
- To: Paul S <pshortis at dataworx dot com dot au>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 28 Aug 2017 20:01:45 +0200 (CEST)
- Subject: Re: gcc torture test pr52286.c
- Authentication-results: sourceware.org; auth=none
- References: <59A38EFD.firstname.lastname@example.org>
On Mon, 28 Aug 2017, Paul S wrote:
> I've ported gcc to a 16 bit CPU and have all torture tests passing bar one,
> The offending lines of code are
> long a, b = 0;
> asm ("" : "=r" (a) : "0" (0));
> which should cause zero to be assigned to the "a" SI sized variable.
> Inspecting the generated code revealed that zero was only being assigned to
> the lower 16 bit half of "a".
> ld r2,0
> I changed the inline asm statement to
> asm ("" : "=r" (a) : "0" (0L));
I think this really is the right fix for this testcase. The testcase was
obviously developed for sizeof(int)>2 targets. The involved constant
doesn't fit into int on those, but the #ifdef case for <=2 targets seems
to have been an afterthought. The asm would have needed the adjustment
that you had to do now.
> so it seems that the "0" constraint on the input operand is affecting
> the inferred mode of the output register operand ?
Or put another way, the required longness (two regs) of the output
constraints isn't reflected back into the input constraint, yes. For
matching constraints the promoted types of the operands need to match, but
nothing checks this :-/