Last Comment Bug 510190 - treehydra_generated.c fails to compile with latest gcc 4.5 trunk
: treehydra_generated.c fails to compile with latest gcc 4.5 trunk
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Rewriting and Analysis (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: ---
Assigned To: (dormant account)
:
: Michael Layzell [:mystor] [:mrl]
Mentors:
Depends on:
Blocks: 484865 527205
  Show dependency treegraph
 
Reported: 2009-08-13 06:11 PDT by Arpad Borsos [:Swatinem]
Modified: 2010-04-29 11:26 PDT (History)
0 users
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
workaround (3.05 KB, patch)
2009-11-25 14:25 PST, (dormant account)
benjamin: review+
Details | Diff | Splinter Review

Description Arpad Borsos [:Swatinem] 2009-08-13 06:11:23 PDT
treehydra_generated.c: In function 'lazy_lang_decl_min':
treehydra_generated.c:1205: error: 'struct lang_decl_min' has no member named 'u'

I will hopefully find time soon to look into this failure.
Comment 1 Arpad Borsos [:Swatinem] 2009-11-06 05:39:47 PST
cp/cp-tree.h contains this struct:

struct GTY(()) lang_decl_min {
  struct lang_decl_base base;
[…]
  union lang_decl_u2 {
[…]
  } GTY ((desc ("%0.u.base.u2sel"))) u2;
};

which is then converted by convert_tree.js callUnion and getUnionResolver to 
convert_lang_decl_u2_union (this, (*topmost).u.base.u2sel, &topmost->u2, obj_u2);

where getUnionResolver uses the "desc" provided in the gcc header, which is clearly wrong as it points to a non existing member thus causing the build failure.

I believe this is clearly a bug in the gcc header and needs to be fixed in gcc rather than dehydra, right?
Comment 2 (dormant account) 2009-11-09 11:55:15 PST
(In reply to comment #1)

> I believe this is clearly a bug in the gcc header and needs to be fixed in gcc
> rather than dehydra, right?

yes. I'm surprised this doesn't make gcc angry during compilation.
Comment 3 (dormant account) 2009-11-18 14:42:30 PST
This is not a bug in gcc. This is a bug in my understanding of the GTY "spec" :(

I assumed %0 meant outermost struct in stuff like struct outermost { struct nested{}}. But it seems what it actually means is that %0 is outermost struct for structs declared by value.

This basically means that I have to "inline" more aggressively :(
Comment 4 (dormant account) 2009-11-25 14:25:16 PST
Created attachment 414567 [details] [diff] [review]
workaround

There are two solutions here. One is to figure out exactly how gengtype nests structs and do the same thing. I don't feel that it is a good idea to generate bloated binding functions, nor do I feel like rewriting the whole of convert_type.js paradigm to be that way.

Alternative is to traverse the struct member graph and figure out exactly which structs need to be "inlined" for %0 to work. That's what this patch does.
In fact, using this approach results in more sensible code and better utilization of dehydra features(instead of ad-hoc ways of doing this as I do currently). Unfortunately I broke Treehydra for 4.3 when I utilized this for all of the gty %tags, so I wont be revisiting that until I no longer have to support multiple compilers.
Comment 5 Benjamin Smedberg [:bsmedberg] 2009-11-30 10:06:46 PST
Comment on attachment 414567 [details] [diff] [review]
workaround

spelling nit s/nexted/nested/

Note You need to log in before you can comment on or make changes to this bug.