Path: utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!TURING.UNM.EDU!mike
From: mike@TURING.UNM.EDU (Michael I. Bushnell)
Newsgroups: gnu.gcc.bug
Subject: Followup on the ASM operands problem
Message-ID: <8811122132.AA00425@turing.unm.edu>
Date: 12 Nov 88 21:32:26 GMT
Sender: daemon@tut.cis.ohio-state.edu
Reply-To: mike@turing.unm.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 64



More on the asm problem.  I have tracked the error down.  

In stmt.c exactly three different kinds of RTL for asm statements can
be generated (expand_asm_operands):

If there is one output and no clobbers, we output 
   (set OUTPUT (asm_operands INSN OUTPUTCONSTRAINT 0
			     ARGVEC CONSTRAINTS))

If there are no outputs and no inputs, we output
   (asm_operands INSN "" 0 ARGVEC CONSTRAINTS)

Otherwise we assume there are multiple outputs and possible clobbers.  
We output
   (parallel [
	(set OUTPUT0 (asm_operands INSN OUTPUTCONSTRAINT0 0
				   ARGVEC CONTSTRAINTS))
	(set OUTPUT1 (asm_operands INSN OUTPUTCONSTRAINT1 1
				   ARGVEC CONTSTRAINTS))
	.
	.
	(clobber (...))
	(clobber (...))
	.
	.
	])

If there are no outputs and there are clobbers, then we end up using
the last case, and outputting:

   (parallel [
	(clobber (...))
	(clobber (...))
	.
	.
	])

We end up with no asm_operands rtx's because there was one in the
parallel for each output operand, and we have no output operands.


I added code to produce 
   (parallel [
	(asm_operands INSN "" 0 ARGVEC CONSTRAINTS)
	(clobber (...))
	(clobber (...))
	.
	.
	])
for this case, and ran into *many* problems.  It seems virtually all
of the remaining code that deals with asm_operands rtx's has the
failing that it assumes that one of the first three patterns is
actually present.  I managed to find a few of these places, but I'm
not up to scanning the whole compiler to find them all.

For now, I will stick in a dummy output operand when I need clobbers.  

But it would be real nice to do this right.

So, RMS...how 'bout it?

		--Mike Bushnell