This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFA] Integrated hashtables take 2

    /* Takes up space of tree_common.  */
      PTR chain;
      PTR type;
      char code_and_flags[4];
    } ignore;

I'd rather this was something the client could configure in some way.
Anyhow, I just do:

  PTR data1;
  PTR data2;
  char data3[4];

to make it clear that cpplib doesn't use these fields in any way.

I'm not 100% sure this will work with (say) a 64-bit host.  Will we
get the right alignment for the next field?

I think my idea of "negative inheritance" where cpplib would
internally manipulate data by getting a pointer to the middle of the
object, and then the front-ends would subtract a few bytes to get a
proper tree_identifier is a little cleaner still.

Am I making sense?

  I'll put an enable-checking-only run-time check in the C front end
  that offset_of (rid_code) matches between the two, similarly for len
  and name, and that sizeof (cpp_hashnode) == sizeof
  (c_common_identifier).  That should be enough.

I wouldn't even bother with the ENABLE_CHECKING.  This will be a cheap
check done once, and failure is a total catastrophe, so we may as well
just always do it.

  We can try to save more space from the "tree_common" in a later patch,
  but I don't want to do too much at once.


  Besides, I have a plan to start to virtualize trees I'd like to put to



Mark Mitchell         
CodeSourcery, LLC     

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]