Re: [Patch, RFC, c*, ObjC* ] make the translation unit decl avail. via a lang hook

[Richard Guenther <richard dot guenther at gmail dot com>]

On Sat, Oct 30, 2010 at 9:20 AM, IainS <developer@sandoe-acoustics.co.uk> wrote:
>
> On 30 Oct 2010, at 00:07, Richard Guenther wrote:
>
>> On Fri, Oct 29, 2010 at 5:57 PM, IainS <developer@sandoe-acoustics.co.uk>
>> wrote:
>>>
>>> Hi Richard,
>>>
>>> On 29 Oct 2010, at 16:28, Richard Guenther wrote:
>>>
>>>> On Fri, Oct 29, 2010 at 3:44 PM, IainS
>>>> <developer@sandoe-acoustics.co.uk>
>>>> wrote:
>>>>>
>>>>> given that my current understanding is:
>>>>> (a) we should make vars file-scope by setting DECL_CONTEXT =
>>>>> translation
>>>>> unit decl
>>>>> (b) there should only be one translation unit decl per TU
>>>>> (c) at present none of the FEs export the t_u_d where other parts of
>>>>> the
>>>>> machinery can see it.
>>>>>
>>>>> would the following patch be appropriate?
>>>>> (it can be extended to fortran and java, I believe, fairly easily).
>>>>
>>>> Sounds like a hack. ?Note that frontends might end up with multiple
>>>> TUs (for example for things in fortran modules).
>>>
>>> One would assume that a built-in that wishes to push an item to the 'file
>>> scope' would still use 'current_translation_unit_decl'.
>>> (to attach the decl to the 'file scope' of the current module).
>>
>> Well, I would argue that builtins don't really have a TU unless they
>> are re-declared from a header.
>>
>>> [and I guess the name mangling must take care of different module
>>> ordering
>>> in different fortran source files?]
>>>
>>>> It's a hack because
>>>> it's a frontend hook that is only used by the frontend (which means
>>>> a single global variable does do it as well,
>>>
>>> OK, I had a global originally ?(called current_translation_unit_decl)
>>> - but that means defining it also in lto which seemed unnecessary.
>>
>> Why in LTO? ?What does LTO have to do with ObjC?
>>
>>>> like other FEs do it
>>>
>>> none of the FEs make the t_u_d available outside the file in which it's
>>> created.
>>> and, AFAICT, ?ObjC* must use the t_u_d created in c* - since they are
>>> sharing spaces.
>>
>> Well, ok.
>>
>>> If this seems reasonable
>>> I can re-do the patch as I had it originally - with a global.
>>>
>>> (or if I'm missing something fundamental, a pointer would be
>>> appreciated).
>>
>> Maybe I am missing something fundamental. ?Why's this suddenly about
>> builtins?
>
> It is about two cases.
>
> 1/ the CFString built-in (see
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01917.html)
> .. which I was persuaded to make non-language-specific (and it seems to be
> working fine, so no issue there).
>
> 2/ the ObjC* FEs that need to use the t_u_d from c* because they inherit
> scopes from c*
>
> (the two things could be done differently, I guess, but it seemed reasonable
> to try for one way).
>
> LTO only arose in the case that a single named global was used as the
> mechanism to satisfy (1).
>
> I have no immediate perception about whether there are more uses possible
> across the FEs (but it seems possible).

Hm, I suppose this doesn't "fix" anything (it'll just be NULL_TREE DECL_CONTEXT
which then doesn't get attributed to a specific language context - but builtins
aren't).  So I think we should defer this to the point when someone
does the work
to unify builtin handling across frontends.

Richard.

> Iain
>
>> Richard.
>>
>>> Iain
>>>
>>>> Richard.
>>>
>>>
>>>
>
>