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



On 7 Jan 2005, at 16.24, Alexander Malmberg wrote:


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).

Please file a PR with a test case.


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.

We do not want to depend on the particulars of C grok...() functionality, because the C++ flavor is completely different. Furthermore, the rules for decaying ObjC method parameters _should_ be implemented in objc-act.c, since we want to keep the same rules for ObjC++.


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).

Note that this will have to work in Objective-C++ as well as Objective-C. The whole grok... machinery is very different for C and C++, which is precisely why objc-act.c has been weaned off of it.

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]'.)

It is (and should be, per the powers that be that I spoke to) '[4i]' for Apple's needs. If you want to diverge this for the GNU runtime, I'd have no objection, though I fail to see why you'd want less accurate information in your encoding when more details are available. :-)


--Zem


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