This is the mail archive of the gcc@gcc.gnu.org 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]
Other format: [Raw text]

Re: [gnat] reuse of ASTs already constructed


A further problem that I'm seeing is that
Lib.Writ.Write_Unit_Information assumes the current unit to depend on
all entries in Lib.Units. However, when letting Lib.Units accumulate
units across several compilations this dependency does not
necessarily hold true. The generated ALI files for compilation 2
to N contain more entries than needed.

--Oliver


On Sat, 2009-05-09 at 16:08 -0400, Robert Dewar wrote:
> Oliver Kellogg wrote:
> > On 2009-05-04, at 07:36 +0200, Oliver Kellogg wrote:
> >> Robert Dewar wrote:
> >>>>>>> How about not doing the name expansion in-place but rather
> >>>>>>> storing the expanded name in an extra node field?
> >>> You could have a separate vector for expanded names I suppose ...
> >> So be it. I will change the code to not overwrite the Name field
> >> with the expanded name but rather store the expanded name in a
> >> data structure separate from the Node.
> >>
> > 
> > Luckily, this change was limited to the Exp_Dbug package body.
> > FYI I am appending the diff.
> > The new Q_E_Name array holds the Name_Id for the expanded name
> > of a given entity. The implementation as a fixed array is
> > preliminary and I would appreciate suggestions on a better
> > data structure to use.
> 
> use a table .. we never use fixed length arrays in the compiler



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