sh64-elf (SH5) port
Alexandre Oliva
aoliva@redhat.com
Tue Feb 5 10:06:00 GMT 2002
On Feb 4, 2002, Mark Mitchell <mark@codesourcery.com> wrote:
> --On Monday, February 04, 2002 9:34 AM -0200 Alexandre Oliva
> <aoliva@redhat.com> wrote:
>>> Could you store that data somewhere else?
>>
>> Sure. In fact, it doesn't really have to be stored anywhere
> I'm sorry; I may have misread your original posting.
Probably just because I failed to include the relevant parts of the
1000-lines ChangeLog entry in the short version of the mega patch.
Sorry.
> If the additional field is only present in the record_layout_info,
> and not in the tree data structures, don't sweat it -- just put it
> in unconditionally, but with a comment indicating when it's used.
Phew! Great. Is the comment I've already put in enough, or should I
mention anything else?
@@ -2323,6 +2324,8 @@ typedef struct record_layout_info_s
/* The alignment of the record so far, allowing for the record to be
padded only at the end, in bits. */
unsigned int unpadded_align;
+ /* The previous field layed out. */
+ tree prev_field;
/* The static variables (i.e., class variables, as opposed to
instance variables) encountered in T. */
tree pending_statics;
>> Ideally, a field would have a direct pointer to its predecessor, so we
>> wouldn't have to make this information artificially available.
> Maybe. Although, you don't generally need that link; keeping this data out
> of the tree structure is probably worth it.
Agreed.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
More information about the Gcc-patches
mailing list