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]
Other format: [Raw text]

Re: [gnat] reuse of ASTs already constructed

Consider compilation of the following code:

   function Exception_Id (Self : in Object) return CORBA.String is
      return To_Unbounded_String
   end Exception_Id;

The interesting part is the call to Interfaces.C.Strings.Value which
returns String.

If this is in the the first file compiled, there is no problem.
However, if this is the second file of a multi file compile job,
a GNAT node may have already been built for the entity "value"
(i.e. the same function call already appeared in a previous file.)

The problem is in gnat_to_gnu_entity (ada/gcc-interface/decl.c:3996ff.)

    /* If the Mechanism is By_Reference, ensure the return type uses
       the machine's by-reference mechanism, which may not the same
       as above (e.g., it might be by passing a fake parameter).  */
    else if (kind == E_Function
             && Mechanism (gnat_entity) == By_Reference)
        TREE_ADDRESSABLE (gnu_return_type) = 1;

Since the entity's Mechanism attribute was changed from Default to
By_Reference by a previous compilation (see Set_Mechanism calls in
decl.c), the "if" condition here becomes true, and TREE_ADDRESSABLE
is set true on the gnu_return_type.
But that seems to wreak havoc with the further processing.

I'm not sure about how best to address this problem.
Perhaps the easy way out would be to buffer the original value of 
the Mechanism of all entities, and restore those values before
compiling the next file?



On Wed, 2009-08-26 at 19:45 +0200, Oliver Kellogg wrote:
> I've been making progress on the Ada side, the basic usage pattern for
> gnat1 and gnatmake is working.
> There are two problems right now:
> 1) Mixing of Ada.Text_IO and Text_IO as described at
> 2) The 'X' lines in the ALI files are not what they should be.
> This is due to the fact that Lib.Xref.Generate_(Definition|Reference) is
> called during semantic analysis. However, when I discover that a
> tree was already built for a main unit by a previous compilation,
> Sem is not redone for that tree. Depending on whether
> Lib.Xref.Initialize is called per-job or per-file, this leads to either
> too much or too little cross ref info.
> Ideas?
> Thanks,
>  Oliver
> On Thu, 2009-07-02 at 00:23 +0200, Oliver Kellogg wrote:
> > I am approaching the point where the basic multi-source mechanism
> > in the gnat1/gnatmake Ada code is working but I am getting
> > lots of crashes in the gigi/gnat_to_gnu triggered core gcc code.
> > I will have to learn much more about the GCC internals than
> > I know right now so progress will inevitably be slow.
> > 
> > For your information I am appending the current patch that
> > I am using, as well as a log of a valgrind session that shows
> > some of the current problems.
> > 
> > On Wed, 2009-04-22 at 18:22 -0400, Robert Dewar wrote:
> > > Oliver Kellogg wrote:
> > > > [...]
> > > > One more thing, procedure Initialize crashes with a libc report of
> > > > double free() when invoked more than once. (Found this while
> > > > working on the gnat1 multi-source compile feature, see
> > > >
> > > > FYI I'm attaching the patch that works for me.
> > > 
> > > gnat1 does not have the capability of compiling more than one
> > > source file without being loaded, yes there is some preparation
> > > for this, but it would require major work to get this working,
> > > there are many known problems.
> > 
> > For interest, what are the known problems?
> > 
> > Thanks,
> > 
> > Oliver
> > 

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