[M3devel] DECL_LANG_SPECIFIC and casts?

[Jay K]

Nevermind.
In 4.3 you have to say
struct foo GTY(())

in 4.5 you have to say struct GTY foo(());

Just on the type/field declarations.
Variables have the same syntax.

I asssume 4.2 matches 4.3 but I have to double check.

Apple, therefore iPhone, is still on 4.2.
I don't want to merge.
I'd rather keep 4.2/4.5 compatible code.

So if possible, would like to remove this stuff.
But doesn't seem possible.
Instead I'll move it to 4.2/4.5-specific files.

Unless by chance 4.2 is ok with the 4.5 form. 4.3 isn't.
Unfortunate.

  - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 26 May 2010 16:13:29 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] DECL_LANG_SPECIFIC and casts?
>
> Why would this be problematic? We need to retain it for later use, and I remember making sure that this worked. Does the collector somehow delete the target?
>
> On 26 May 2010, at 10:20, Jay K wrote:
>
>>
>> Tony, this thing where we do:
>>
>> DECL_LANG_SPECIFIC(f) = (lang_decl_t*)var; /* we will fix the offset later once we have rtl */
>> ...
>>
>> tree var = (tree)DECL_LANG_SPECIFIC(index);
>>
>>
>> Is this running afoul of the gcc garbage collector?
>> Seems likely.
>>
>> And does it matter?
>> Seems very uncertain. I know almost nothing here, but it looks like we do hold on to the thing until the end anyway,
>> assuming m3_write_globals is called near the end.
>>
>>
>> Thing is:
>> struct lang_identifier GTY(()) ...
>> union lang_tree_node GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"))) ...
>> struct lang_type GTY(()) ...
>> typedef struct lang_decl GTY(()) ...
>> struct language_function GTY(()) ...
>>
>>
>> Which are nearly unused, cause me grief.
>> They have to be different for 4.5 vs. 4.2/4.3.
>> Just the GTY needs to be moved to before the union/struct tag.
>>
>>
>> I'd like to keep the code compatible with 4.2 at least until a separate upgrade of the iPhone backend.
>> I haven't checked what Apple is up to there though. Could also make sense to merge their changes..but there's generally
>> aren't so small like ours so I'd rather not.
>>
>>
>> - Jay
>>
>