[cfe-dev] The size of a pointer to function.

[John McCall]

On Feb 8, 2013, at 1:08 AM, Enea Zaffanella <zaffanella at cs.unipr.it> wrote:
> On 02/07/2013 09:30 PM, Tim Northover wrote:
>>> Hence, the question is the following: are you willing to accept a
>>> (hopefully) much less invasive patch that *only* ensures the correctness of
>>> the AST info produced by clang for these (strange and otherwise unsupported,
>>> but anyway standard compliant) targets?
>> 
>> Even the AST produced can depend rather strongly on the target.
>> Through obvious things like preprocessor magic, but also through more
>> subtle issues like overload resolution.
>> 
>> Are you imagining some kind of "target" with full driver support in
>> Clang but no attempt at CodeGen? Otherwise it's not clear how this
>> scheme could work.
>> 
>> Tim.
> 
> 
> I am not sure I have fully understood your question.
> 
> As a *library*, clang allows for your own tool to define your own specific target deriving from TargetInfo (or one of its subclasses) and set the appropriate values for its many features, among which we have the size and alignment of pointer types. What we ask for is only a separation between the two kinds of (object vs function) pointers.
> (Side note: clang already supports differently sized (object only) pointers via address spaces; to this end, TargetInfo includes a few virtual functions that can be overridden; we are already using this possibility).
> 
> For our own purposes, the thing above will be enough (in other words, we have our own "driver" that sets up the target info according to our needs). If deemed appropriate by clang developers, we can add options controlling these target values in the clang driver too.
> However, this would sound a bit contradictory: having a full-blown driver option may (wrongly) suggest that full support is provided by the whole frontend, including code generation. If this (as hinted by John) is not currently among the priorities ...

It doesn't make sense for this to be a driver option independent of the target triple.

My objection is that this abstraction has real costs, and you seem to be interested in doing it purely theoretically, simply because the standard conceives of platforms that do so.  To me, that does not seem like a good use of my time as a reviewer/maintainer.  If someone comes to us and says, look, we really do have a platform like this, and we're going to maintain an LLVM backend for it, and we'd like to have clang as a frontend?  Then that's great, and we should do it properly.  But I see no merit in complicating our implementation just so that sizeof works properly when doing static analysis on a platform that the project in general has no intention of supporting.

John.