Re: [gnat] reuse of ASTs already constructed

[oliver.kell...@t-online.de]

I am finally finding some some time to continue this work,
having left off with
  http://gcc.gnu.org/ml/gcc/2009-08/msg00475.html :

> [...]
> There are two problems right now:
> 
> 1) Mixing of Ada.Text_IO and Text_IO as described at
>http://gcc.gnu.org/ml/gcc-help/2009-08/msg00113.html

The solution to this one turned out to be quite simple, see attached patch.
Sem_Ch12.Analyze_Package_Instantiation calls Rtsfind.Text_IO_Kludge,
and the latter contains:

  if Chrs in Text_IO_Package_Name then
 for U in Main_Unit .. Last_Unit loop
Get_Name_String (Unit_File_Name (U));
...
On compiling the second file, Main_Unit is not 0 but some larger value.
The existing node for Text_IO was not being found because it is at an
index smaller than the current Main_Unit. The solution was to start the
loop at index 0.

I will now start looking into the second problem,

> 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.

By the way, I am currently using trunk r152433 (4.5.0 pre-release) and
moving forward to the 4.5.0 release.
When that is done: Should I continue on trunk or switch to the
gcc-4_5-branch ?

Thanks,

Oliver
Index: rtsfind.adb
===
--- rtsfind.adb	(revision 152433)
+++ rtsfind.adb	(working copy)
@@ -1406,7 +1406,7 @@
   --  or [Wide_]Wide_Text_IO already loaded, then load the proper child.
 
   if Chrs in Text_IO_Package_Name then
- for U in Main_Unit .. Last_Unit loop
+ for U in 0 .. Last_Unit loop
 Get_Name_String (Unit_File_Name (U));
 
 if Name_Len = 12 then

Re: [gnat] reuse of ASTs already constructed

[oliver.kell...@t-online.de]

I looked into the second problem from
  http://gcc.gnu.org/ml/gcc/2009-08/msg00475.html ,

> 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. [...]

and I see two possible solutions:

1) Extend Lib.Xref.Generate_Reference, Sem_Util.Process_End_Label
and others for the case "not In_Extended_Main_Source_Unit" in multi
source compilation mode to buffer the generated references for possible
later consumption by the main unit for which they are intended.
If the main unit is not part of the main units given in the multi source
compile job then the buffered data can be discarded.

2) Determine an ordering of the main units such that main units with
little or no dependencies precede main units that depend on them.
Submit units to semantic analysis in the determined order.

Both approaches seem quite heavy.
Solution 2 looks more elegant to me. OTOH this would require a
separate analysis of the with clauses prior to invoking Sem proper.

Oliver