This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: PR objc/18971


First, sorry for not responding to this earlier. RL has been keeping me busy (and is still keeping me busy, but Andrew Pinski is bugging me about this; hence a quick reply :).

Ziemowit Laski wrote:
This was noticed by Alex, and it turned out that ObjC method parameters were not being properly decayed from arrays to pointers. This patch hopefully fixes this, along with ObjC pretty-printing of array types.

After we discussed this, I looked at fixing the bug this way, and came to the conclusion that it's wrong. While it does seem to fix the immediate problem of decaying arrays to pointers, it doesn't fix the real problem here, namely:


Method arguments are arguments and need to grok:d as arguments, just like function arguments.

In other words, the decl_context when passed to grokdeclarator needs to be PARM. It used to be PARM, but this was broken by changing it to TYPENAME some time since 20040902, and your patch doesn't fix that. Using TYPENAME doesn't work because:

1. The differences between TYPENAME and PARM are more involved than just decaying arrays to pointers. It's trivial to construct a case with a function parameter, which should but doesn't decay to a function pointer (a regression, btw). Duplication all the PARM code from c-decl.c in the objective-c frontend to do these things there seems like a Very Bad Idea.

2. You have to grok the arguments as something, and grok:ing the argument as TYPENAME throws away information you need later. Andrew Pinski just filed PR19321 for an instance of this.

3. (Similar to 2.) Some arguments simply can't be grok:d as TYPENAME, e.g.:

-(void) foo: (int [restrict])arg;


My patch, attached to PR18971, solves all these problems (and can probably be changed to use grokparm instead of a new function, if that's desirable).


It also has the side-effect of reverting the encoding of arrays so that they're encoded as pointers, as they were in 3.3 and earlier versions.

(I.e.

+ (1) The _encodings_ for the array arguments should remain to be '[4i]' and
+ such, since this has been the case since at least gcc 3.3.

is incorrect. Testing here shows that 3.3 and 3.3.5 (Debian 1:3.3.5-5) both encode this as '^i'. 3.4 is the only version that encodes it as '[4i]'.)


As far as I'm concerned, this is definitely not wrong, and might even be a good thing (your comment about dimensionless arrays implies some problems that the '[4i]' encoding will cause for DO and forwarding, but I haven't had time to look closely at that).

It seems that if you really want to keep the encoding change, you'd need to add a new decl_context to grokdeclarator that is just like PARM except that it doesn't decay arrays to pointers.

- Alexander Malmberg


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]