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