other/5426: Documentation/Behavior differ for array ids in inline asm

other/5426: Documentation/Behavior differ for array ids in inline asm

[aliberi]

>Number:         5426
>Category:       other
>Synopsis:       Documentation/Behavior differ for array ids in inline asm
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 18 06:56:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Armand Liberi
>Release:        All that I know of.
>Organization:
>Environment:
All systems that I have access to - Linux 5.2 (old, old), LynxOS 3.1.0a (old), and CygWin (latest)
>Description:
The gcc manual says that "Output operand expressions must be lvalues; the compiler can check this."  This is not the case for array identifiers (rvalues).  As near as I can tell, they are treated as lvalues in output constraints and as rvalues in input constraints.  In the course of trying to determine what the proper syntax should be for my particular application, I wrote the attached "snippet" source file and found these apparent rules for "m" constraints:
-----------------------------------
The "m" constraint rules are (???):
  Inputs:
    For lvalues, use the supplied lvalue directly
    For rvalues, use a computed address pointing to the rvalue even if the supplied value is an array identifier.

  Outputs:
    For lvalues, use the supplied lvalue directly
    For rvalues, generate an error unless the supplied value is an array identifier.  In that case, use the supplied rvalue directly as if it were an lvalue.
-----------------------------------
The attached file illustrates that an array identifier, 'fpEnv', is treated differently than the form '&fpEnv[0]' - apparently inconsistent behavior.

I have submitted this very same issue in a more obscure form previously and was basically told that "it is a pointer thing" or something similar.  It would appear to me to be "a syntax thing" - poorly documented and incorrectly implemented.  I have also tried the gnu.gcc.help server (Subject: Repost of "Inline asm creates address of provided address instead of just using provided address") and only managed to have someone instruct me on ways of avoiding the ambiguity, not eliminating it.  So, I'm back here.  Thanks.
>How-To-Repeat:
gcc -save-temps -o fpsave fpsave.c and examine the resulting fpsave.s file.
>Fix:
Preferably, change the compiler's behavior to agree with the documentation.  That way, its behavior would not be inconsistent and the syntax more easily inferred (since the documentation is a little obscure).
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/plain; name="fpsave.c"
Content-Disposition: inline; filename="fpsave.c"

#include <stdio.h>

unsigned short fpEnv[54];
unsigned short fpSingle;
unsigned short * fpPtr;
struct {int i;}lv;

void f(unsigned short * p1,void * p2,unsigned short * p3) {
	printf("p1, 0x%08X; p1, 0x%08X; p1, 0x%08X.\n",p1,p2,p3);
}

/*
	The "m" constraint rules are (???):
	Inputs:
		For lvalues, use the supplied lvalue directly
		For rvalues, use a computed address pointing to the rvalue even if the supplied
		value is an array identifier.
	Outputs:
		For lvalues, use the supplied lvalue directly
		For rvalues, generate an error unless the supplied value is an array identifier.
		In that case, use the supplied rvalue directly as if it were an lvalue
*/

int main()
{
	f(fpEnv,&fpEnv,&fpEnv[0]);
//	rvalue cannot be used for output as manual states
//	asm ("cmpw $0,%0":"=m" (1));			//	output member 0 not directly addressable
//	rvalue can be used for input - gcc computes its address
	asm ("cmpw $0,%0"::"m" (1));			//	Generates .LCx

//	gcc knows nothing of fpEnv here so it does not matter that it is an rvalue
	asm ("cmpw $0,fpEnv");					//	Generates fpEnv
	asm ("cmpw $0,fpEnv");					//	Generates fpEnv

//	THE STRANGE CASE OF AN ARRAY IDENTIFIER

//	For some reason, gcc treats an array identifier as if it were an lvalue for output
	asm ("cmpw $0,%0":"=m" (fpEnv));		//	Generates fpEnv
//	And then, as if it were an rvalue for input
	asm ("cmpw $0,%0"::"m" (fpEnv));		//	Generates .LCx


//	rvalue cannot be used for output as manual states
//	asm ("cmpw $0,%0":"=m" (&fpEnv));		//	output member 0 not directly addressable
//	rvalue can be used for input - gcc computes its address
	asm ("cmpw $0,%0"::"m" (&fpEnv));		//	Generates .LCx

//	rvalue cannot be used for output as manual states
//	asm ("cmpw $0,%0":"=m" (&fpEnv[0]));	//	output member 0 not directly addressable
//	rvalue can be used for input - gcc computes its address
	asm ("cmpw $0,%0"::"m" (&fpEnv[0]));	//	Generates .LCx

//	lvalue used for output is OK, gcc supplies its address
	asm ("cmpw $0,%0":"=m" (fpEnv[0]));		//	Generates fpEnv
//	lvalue used for input is OK, gcc supplies its address
	asm ("cmpw $0,%0"::"m" (fpEnv[0]));		//	Generates fpEnv

//	lvalue used for output is OK, gcc supplies its address
	asm ("cmpw $0,%0":"=m" (fpEnv[1]));		//	Generates fpEnv+2
//	lvalue used for input is OK, gcc supplies its address
	asm ("cmpw $0,%0"::"m" (fpEnv[1]));		//	Generates fpEnv+2

//	lvalue used for output is OK, gcc supplies its address
	asm ("cmpw $0,%0":"=m" (fpSingle));		//	Generates fpSingle
//	lvalue used for input is OK, gcc supplies its address
	asm ("cmpw $0,%0"::"m" (fpSingle));		//	Generates fpSingle

//	rvalue cannot be used for output as manual states
//	asm ("cmpw $0,%0":"=m" (&fpSingle));	//	output member 0 not directly addressable
//	rvalue can be used for input - gcc computes its address
	asm ("cmpw $0,%0"::"m" (&fpSingle));	//	Generates .LCx

//	lvalue used for output is OK, gcc supplies its address
	asm ("cmpw $0,%0":"=m" (fpPtr));		//	Generates fpPtr
//	lvalue used for input is OK, gcc supplies its address
	asm ("cmpw $0,%0"::"m" (fpPtr));		//	Generates fpPtr

//	lvalue used for output is OK, gcc supplies its address
	asm ("cmpw $0,%0":"=m" (lv));		//	Generates lv
//	lvalue used for input is OK, gcc supplies its address
	asm ("cmpw $0,%0"::"m" (lv));		//	Generates lv
}