headers
Iain Hibbert | 17 Mar 2012 09:36

PCC-385: function prototypes as arguments cannot take attributes

Hi

I was looking at the above issue posted to JIRA by me, and I think that
the problem is that abstract_declarator does not cater for attributes
after a parenthesis, probably the correct fix is below

Index: cgram.y
===================================================================
RCS file: /cvsroot/pcc/cc/ccom/cgram.y,v
retrieving revision 1.341
diff -u -p -4 -r1.341 cgram.y
--- cgram.y	3 Sep 2011 07:43:43 -0000	1.341
+++ cgram.y	17 Mar 2012 08:33:04 -0000
 <at>  <at>  -453,13 +453,13  <at>  <at>  abstract_declarator:
 		|  '(' ')' { $$ = bdty(UCALL, bdty(NAME, NULL)); }
 		|  '(' ib2 parameter_type_list ')' {
 			$$ = bdty(CALL, bdty(NAME, NULL), $3);
 		}
-		|  abstract_declarator '(' ')' {
-			$$ = bdty(UCALL, $1);
+		|  abstract_declarator '(' ')' attr_var {
+			$$ = block(UCALL, $1, NULL, INT, 0, gcc_attr_parse($4));
 		}
-		|  abstract_declarator '(' ib2 parameter_type_list ')' {
-			$$ = bdty(CALL, $1, $4);
+		|  abstract_declarator '(' ib2 parameter_type_list ')' attr_var {
+			$$ = block(CALL, $1, $4, INT, 0, gcc_attr_parse($6));
 		}
 		;
(Continue reading)

Permalink | Reply |
headers
Anders Magnusson | 17 Mar 2012 16:02
Picon

Re: PCC-385: function prototypes as arguments cannot take attributes

Hi Iain,

On 03/17/2012 09:36 AM, Iain Hibbert wrote:
> Hi
>
> I was looking at the above issue posted to JIRA by me, and I think that
> the problem is that abstract_declarator does not cater for attributes
> after a parenthesis, probably the correct fix is below
>
> Index: cgram.y
> ===================================================================
> RCS file: /cvsroot/pcc/cc/ccom/cgram.y,v
> retrieving revision 1.341
> diff -u -p -4 -r1.341 cgram.y
> --- cgram.y	3 Sep 2011 07:43:43 -0000	1.341
> +++ cgram.y	17 Mar 2012 08:33:04 -0000
>  <at>  <at>  -453,13 +453,13  <at>  <at>  abstract_declarator:
>   		|  '(' ')' { $$ = bdty(UCALL, bdty(NAME, NULL)); }
>   		|  '(' ib2 parameter_type_list ')' {
>   			$$ = bdty(CALL, bdty(NAME, NULL), $3);
>   		}
> -		|  abstract_declarator '(' ')' {
> -			$$ = bdty(UCALL, $1);
> +		|  abstract_declarator '(' ')' attr_var {
> +			$$ = block(UCALL, $1, NULL, INT, 0, gcc_attr_parse($4));
>   		}
> -		|  abstract_declarator '(' ib2 parameter_type_list ')' {
> -			$$ = bdty(CALL, $1, $4);
> +		|  abstract_declarator '(' ib2 parameter_type_list ')' attr_var {
> +			$$ = block(CALL, $1, $4, INT, 0, gcc_attr_parse($6));
(Continue reading)

Permalink | Reply |
headers
Iain Hibbert | 17 Mar 2012 17:12

Re: PCC-385: function prototypes as arguments cannot take attributes

On Sat, 17 Mar 2012, Anders Magnusson wrote:

> Hi Iain,
>
> On 03/17/2012 09:36 AM, Iain Hibbert wrote:
> > ..can anybody confirm this is right?
> Yep, it is correct.  It should be checked though that the attributes
> really follows into the function where it prototypes for and not get
> tossed away somewhere.

Ok great thanks but how do I do that, I guess some debug output can show
it?

> > while here though, I wonder when the patterns without the preceding
> > abstract_declarator will match, do I need to handle attributes there also?
> Yep, otherwise declarations like
> int x(int (int) __attribute__((unused)));
> will fail :-)

I see.. but what does that even mean, is it some kind of shortcut?

iain

(will also expand the examples and put into tests)
Permalink | Reply |
headers
Anders Magnusson | 17 Mar 2012 17:26
Picon

Re: PCC-385: function prototypes as arguments cannot take attributes

On 03/17/2012 05:12 PM, Iain Hibbert wrote:
> On Sat, 17 Mar 2012, Anders Magnusson wrote:
>
>> Hi Iain,
>>
>> On 03/17/2012 09:36 AM, Iain Hibbert wrote:
>>> ..can anybody confirm this is right?
>> Yep, it is correct.  It should be checked though that the attributes
>> really follows into the function where it prototypes for and not get
>> tossed away somewhere.
> Ok great thanks but how do I do that, I guess some debug output can show
> it?
ccom -Xp will show prototype information.  I can check it otherwise.

>>> while here though, I wonder when the patterns without the preceding
>>> abstract_declarator will match, do I need to handle attributes there also?
>> Yep, otherwise declarations like
>> int x(int (int) __attribute__((unused)));
>> will fail :-)
> I see.. but what does that even mean, is it some kind of shortcut?
It's a function declaration without argument name, which in a
prototype will become a function pointer.  Example will explain:

int x(int (int) __attribute__((unused)));
int x(int a(int) __attribute__((unused))) { return a(1);}
Permalink | Reply |
headers
Iain Hibbert | 17 Mar 2012 19:54

Re: PCC-385: function prototypes as arguments cannot take attributes

On Sat, 17 Mar 2012, Anders Magnusson wrote:

> On 03/17/2012 05:12 PM, Iain Hibbert wrote:
> > On Sat, 17 Mar 2012, Anders Magnusson wrote:
> >
> > > Hi Iain,
> > >
> > > On 03/17/2012 09:36 AM, Iain Hibbert wrote:
> > > > ..can anybody confirm this is right?
> > > Yep, it is correct.  It should be checked though that the attributes
> > > really follows into the function where it prototypes for and not get
> > > tossed away somewhere.
> > Ok great thanks but how do I do that, I guess some debug output can show
> > it?
> ccom -Xp will show prototype information.  I can check it otherwise.

Hm, there is an unrelated problem there.. with a vanilla pcc (no local
changes)

% cat a.c
void foo ( __attribute__ ((__unused__)) void (*a)() );
% pcc -S -Wc,-Xp a.c
major internal compiler error: a.c, line 1
%

this is only where the parameter list was empty though (in any
configuration); adding a parameter gives

% cat a.c
void foo ( __attribute__ ((__unused__)) void (*a)(int a) );
(Continue reading)

Permalink | Reply |
headers
Iain Hibbert | 17 Mar 2012 20:13

Re: PCC-385: function prototypes as arguments cannot take attributes

On Sat, 17 Mar 2012, Iain Hibbert wrote:

> (I will investigate the attributes for my changes in a bit)

So anyway, it appears that something is not complete with my patch..

1.  void foo2 ( __a void (*)(int) );

arglist 0xbb90178c
0xbb90178c) NAME, 0, 0x0, int, 0x0, attributes;
arg 0: int
end arglist
arglist 0xbb9017e4
0xbb9017e4) NAME, 3146782408, 0x0, PTR FTN void, 0xbb901870, attributes; unused: 0 0 0,
arg 0: PTR FTN void  arg 0: int

end arglist

2.  void foo3 ( void (*)(int) __a );

arglist 0xbb901760
0xbb901760) NAME, 0, 0x0, int, 0x0, attributes;
arg 0: int
end arglist
arglist 0xbb9017d0
0xbb9017d0) NAME, 3146782472, 0x0, PTR FTN void, 0xbb901870, attributes;
arg 0: PTR FTN void  arg 0: int

end arglist
(Continue reading)

Permalink | Reply |
headers
Anders Magnusson | 17 Mar 2012 21:55
Picon

Re: PCC-385: function prototypes as arguments cannot take attributes


> (also, pcc.ludd.ltu.se seems to have gone to sleep :)
I tried to reboot it a few hours ago, but something didn't work out:

ragge-laptop:/home/ragge >date
Sat Mar 17 21:53:35 CET 2012
ragge-laptop:/home/ragge >ssh pcc.ludd.ltu.se

NO LOGINS: System going down at 17:56

I will go to the console tomorrow.

-- Ragge
Permalink | Reply |
headers
Iain Hibbert | 19 Mar 2012 20:22

Re: PCC-385: function prototypes as arguments cannot take attributes

On Sat, 17 Mar 2012, Iain Hibbert wrote:

> On Sat, 17 Mar 2012, Anders Magnusson wrote:
>
> > On 03/17/2012 05:12 PM, Iain Hibbert wrote:
> > > On Sat, 17 Mar 2012, Anders Magnusson wrote:
> > >
> > > > Hi Iain,
> > > >
> > > > On 03/17/2012 09:36 AM, Iain Hibbert wrote:
> > > > > ..can anybody confirm this is right?
> > > > Yep, it is correct.  It should be checked though that the attributes
> > > > really follows into the function where it prototypes for and not get
> > > > tossed away somewhere.
> > > Ok great thanks but how do I do that, I guess some debug output can show
> > > it?
> > ccom -Xp will show prototype information.  I can check it otherwise.
>
> Hm, there is an unrelated problem there.. with a vanilla pcc (no local
> changes)
>
> % cat a.c
> void foo ( __attribute__ ((__unused__)) void (*a)() );
> % pcc -S -Wc,-Xp a.c
> major internal compiler error: a.c, line 1
> %

I fixed that

my other fix though, while it works ok for the syntax, it doesn't seem to
(Continue reading)

Permalink | Reply |
headers
Iain Hibbert | 22 Mar 2012 20:08

Re: PCC-385: function prototypes as arguments cannot take attributes

On Mon, 19 Mar 2012, Iain Hibbert wrote:

> my other fix though, while it works ok for the syntax, it doesn't seem to
> work for the attributes..  but the prior art in this area doesn't seem
> right either, eg
>
>   void foo ( __a int[] );
>
> arglist 0xbb901720
> 0xbb901720) NAME, 3146782408, 0x0, ARY int, 0xbb9017e4, attributes; unused: 0 0 0,
> arg 0: PTR int
> end arglist
>
>   void foo ( int[] __a );
>
> arglist 0xbb90174c
> 0xbb90174c) NAME, 3146782604, 0x0, ARY int, 0xbb901850, attributes;
> arg 0: PTR int
> end arglist

I investigated this some more, and it seems that the attribute is parsed
but when passed to tymerge() the attribute gets lost.. tymerge() does not
take attributes from the NAME though, by design according to the comments,
The attributes are supposed to be on the TYPE part..

iain
Permalink | Reply |
headers
Anders Magnusson | 24 Mar 2012 09:22
Picon

Re: PCC-385: function prototypes as arguments cannot take attributes

On 03/22/2012 08:08 PM, Iain Hibbert wrote:
> On Mon, 19 Mar 2012, Iain Hibbert wrote:
>
>> my other fix though, while it works ok for the syntax, it doesn't seem to
>> work for the attributes..  but the prior art in this area doesn't seem
>> right either, eg
>>
>>    void foo ( __a int[] );
>>
>> arglist 0xbb901720
>> 0xbb901720) NAME, 3146782408, 0x0, ARY int, 0xbb9017e4, attributes; unused: 0 0 0,
>> arg 0: PTR int
>> end arglist
>>
>>    void foo ( int[] __a );
>>
>> arglist 0xbb90174c
>> 0xbb90174c) NAME, 3146782604, 0x0, ARY int, 0xbb901850, attributes;
>> arg 0: PTR int
>> end arglist
> I investigated this some more, and it seems that the attribute is parsed
> but when passed to tymerge() the attribute gets lost.. tymerge() does not
> take attributes from the NAME though, by design according to the comments,
> The attributes are supposed to be on the TYPE part..
The comments are correct, the problem is the abstract declarators.  If 
there is a variable given in the prototype it works:

void foo ( int[] __a);
arglist 0x800c0a340
0x800c0a340) NAME, 34372362992, 0x0, ARY int, 0x800c0a430, attributes;
(Continue reading)

Permalink | Reply |
headers
Anders Magnusson | 24 Mar 2012 17:55
Picon

Re: PCC-385: function prototypes as arguments cannot take attributes

On 03/22/2012 08:08 PM, Iain Hibbert wrote:
> On Mon, 19 Mar 2012, Iain Hibbert wrote:
>
>> my other fix though, while it works ok for the syntax, it doesn't seem to
>> work for the attributes..  but the prior art in this area doesn't seem
>> right either, eg
>>
>>    void foo ( __a int[] );
>>
>> arglist 0xbb901720
>> 0xbb901720) NAME, 3146782408, 0x0, ARY int, 0xbb9017e4, attributes; unused: 0 0 0,
>> arg 0: PTR int
>> end arglist
>>
>>    void foo ( int[] __a );
>>
>> arglist 0xbb90174c
>> 0xbb90174c) NAME, 3146782604, 0x0, ARY int, 0xbb901850, attributes;
>> arg 0: PTR int
>> end arglist
> I investigated this some more, and it seems that the attribute is parsed
> but when passed to tymerge() the attribute gets lost.. tymerge() does not
> take attributes from the NAME though, by design according to the comments,
> The attributes are supposed to be on the TYPE part..
Fixed now.  The attributes are moved to the other node before tymerge().

-- Ragge
Permalink | Reply |
headers
Iain Hibbert | 26 Mar 2012 10:15

Re: PCC-385: function prototypes as arguments cannot take attributes

On Sat, 24 Mar 2012, Anders Magnusson wrote:

> On 03/22/2012 08:08 PM, Iain Hibbert wrote:
> > I investigated this some more, and it seems that the attribute is parsed
> > but when passed to tymerge() the attribute gets lost.. tymerge() does not
> > take attributes from the NAME though, by design according to the comments,
> > The attributes are supposed to be on the TYPE part..
> Fixed now.  The attributes are moved to the other node before tymerge().

Ah, thanks..  I think that fixes building stuff on NetBSD again (Jörg was
adding attributes to the header files :)

iain
Permalink | Reply |

Gmane