This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: PR objc/18971
- From: Alexander Malmberg <alexander at malmberg dot org>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 08 Jan 2005 01:24:06 +0100
- Subject: Re: PATCH: PR objc/18971
- References: <26C415B8-55F6-11D9-AADC-00039390FFE2@apple.com>
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
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.
+ (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
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