Re: gcc vax bug in built-in ffs function/displacement indexed addressing

[Paul Koning <paulkoning%comcast.net@localhost>]

> On Jan 6, 2017, at 11:33 AM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
>>> I dug out my transcription of EL-00032-00-decStd32_Jan90.pdf.  3.3,
>>> BIT-FIELD INSTRUCTIONS, says that the base address "is obtained from
>>> an operand of address access type", but I have so far completely
>>> failed to find any clear statement of what operand size is used for
>>> bit-field operands.
>> My VAX architecture handbook says that the operand type of that operand is "$
> 
> Doh!  So does mine.
> 
>              opcode startpos.rl, size.rb, base.vb, {field.rv}, findpos.wl
> 
> I can only infer I was looking at the implicit field.rv operand.
> 
>> So yes, that looks like a wrong code bug.  Perhaps the code generator just h$
> 
> If so, it's probably worth checking the other bitfield instructions
> too.

From a quick look at the VAX stuff in gcc/config/vax, I see this in builtins.md:

(define_insn "ffssi2_internal"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=rQ")
	(ffs:SI (match_operand:SI 1 "general_operand" "nrmT")))
   (set (cc0) (match_dup 0))]
  ""
  "ffs $0,$32,%1,%0")

I believe the issue is that the check for "can we use indexing" (in vax.c) assumes that the answer is yes if the offset is a value multiplied by sizeof(operand).  In this case, I assume that the operand is a 32 bit integer.  The trouble is that FFS operates on values up to 32 bits but indexes as if it were a byte operand.

I'm not sure if constraint "Q" means what I hope it does, but if yes, the fix might be to replace the nrmT in that second match_operand by nrQT.

If that's not the answer then some more analysis will be needed, probably to include looking at the debug dumps of intermediate data that GCC will generate on request.

	paul