<< Back to previous view

[PCC-404] regparm attribute is not supported (on i386) Created: 28/Aug/12  Updated: 07/May/14

Status: Resolved
Project: pcc
Component/s: i386 target
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Iain Hibbert Assignee: Anders Magnusson
Resolution: Fixed Votes: 0
Environment: NetBSD/i386


 Description   
the "regparm" attribute is not supported.. from the gcc 4.5.3 documentation:

`regparm (NUMBER)'
     On the Intel 386, the `regparm' attribute causes the compiler to
     pass arguments number one to NUMBER if they are of integral type
     in registers EAX, EDX, and ECX instead of on the stack. Functions
     that take a variable number of arguments will continue to be
     passed all of their arguments on the stack.


 Comments   
Comment by Anders Magnusson [ 30/Aug/12 05:43 PM ]
This is quite difficult to implement; I have looked at it before. It changes the behaviour of the function call stuff.
I have a light plan to do a general overhaul of the function parameter stuff, but after next release.
Comment by Anders Magnusson [ 01/May/14 12:18 PM ]
Now simple support for regparm added (for i386).
Comment by Iain Hibbert [ 06/May/14 08:44 PM ]
found couple of problems with regparm support

First, if an argument is not an integer type then a problem occurs, eg

void __attribute__ ((__regparm__ (2)))
foo(int a, int *b)
{
}

produces an "illegal combination of pointer and integer" warning for argument b. I think arguments not of integral type should just get sent on the stack, as normal.

2. when the number of actual arguments is not as many as listed in the attribute, then a compiler error occurs, eg

void __attribute__ ((__regparm__ (2)))
foo(int a)
{
}

when compiled with "pcc -c" fails with

test.c, line 3: warning: illegal combination of pointer and integer
test.c, line 3: compiler error: Cannot generate code, node 0xbb9059c4 op =
/usr/libexec/ccom terminated with status 1

this second happens when the regparm attribute was inserted by generic header code, which seems to be the rule rather than the exception (mostly, I see (3) used). I think the extra regparm should just be ignored, in this context


Comment by Anders Magnusson [ 07/May/14 02:51 PM ]
The regparm behaviour is poorly documented, but it seems as gcc puts everything it can in registers as long as it fits in the numbers.

I have fixed the bugs now. Stdcall is not 100% correct yet byt that is another issue.
Generated at Sat Dec 20 17:34:49 CET 2014 using JIRA Enterprise Edition, Version: 3.13.1-#333.