Issue Details (XML | Word | Printable)

Key: PCC-404
Type: New Feature New Feature
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Anders Magnusson
Reporter: Iain Hibbert
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

regparm attribute is not supported (on i386)

Created: 28/Aug/12 09:58 PM   Updated: 07/May/14 02:51 PM
Component/s: i386 target
Affects Version/s: None
Fix Version/s: None

Environment: NetBSD/i386

 Description  « Hide
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.

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Anders Magnusson added a comment - 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.

Anders Magnusson added a comment - 01/May/14 12:18 PM
Now simple support for regparm added (for i386).

Iain Hibbert added a comment - 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

Anders Magnusson added a comment - 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.