> --- single/blanks_to_underscores.ali 2012-06-23 18:15:09
> +++ multi/blanks_to_underscores.ali 2012-06-23 19:07:39
> @@ -7,20 +7,17 @@
> .
> -X 3 blanks_to_underscores.adb
> +X 1 blanks_to_underscores.adb
>
> In multi source compilations, main units may get assigned different
> unit numb
Hello,
The patch attached at http://gcc.gnu.org/ml/gcc/2012-06/msg00261.html
was just barely enough to get gnat1 compiled but failed on compiling the
rts files. Please replace it by the patch here. (This one is against
gcc/trunk r162542 of 2010-07-26 but I'm moving forward these days.)
One occa
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
>
> 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
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 s
Consider compilation of the following code:
function Exception_Id (Self : in Object) return CORBA.String is
begin
return To_Unbounded_String
(Interfaces.C.Strings.Value
(Self.C_Str));
end Exception_Id;
The interesting part is the call to Interfaces
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
http://gcc.gnu.org/ml/gcc-help/2009-08/msg00113.html
2) The 'X' lines in the ALI files are not what they
I'm now using a variable length data structure for Q_E_Name
as suggested by Robert Dewar.
Also I've added a -multi option to gnatmake to switch on
the multi source compile mode. This allows test driving the
new feature.
I plan to send my next patch to gcc-patches and appreciate
any comments you m
I got my first main program built in multi-source mode running.
The ALI file and debug-info generation isn't perfect yet; also I'm
using raw gnat1 as gnatmake is not yet adapted to multi-source mode.
Oliver
gnat1_multi_demo.tgz
Description: application/compressed-tar
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 compilat
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
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
> "Oliver" == Oliver Kellogg writes:
Oliver> Also, I'm thinking that in multi-source mode, the switch "-o"
Oliver> can perhaps continue to be used - not by giving a filename
Oliver> but instead by giving a directory. All object files would then
Oliver> be placed in the given directory. What d
Oliver Kellogg wrote:
> Further question, what is the process for integrating my changes
> into the GCC trunk?
The generic procedure is documented at the gcc web site:
http://gcc.gnu.org/contribute.html
http://gcc.gnu.org/svnwrite.html
> I would assume that I need to
> 1) Make
Robert Dewar wrote:
>
> I don't see that Str3 is free in any of these nodes, what
> nodes are you talking about (remember that Str3 overlaps
> Node3, List3 etc).
Okay.
> How about not doing the name expansion in-place but rather
> storing the expanded name in an extra node field?
>
>
Oliver Kellogg wrote:
Sorry if I'm slow in understanding:
Are you saying that introducing an extra field would
cause problems (memory or other) ?
Do you think it would be okay to use the Str3 field, then?
I don't see that Str3 is free in any of these nodes, what
nodes are you talking about (rem
Sorry if I'm slow in understanding:
Are you saying that introducing an extra field would
cause problems (memory or other) ?
Do you think it would be okay to use the Str3 field, then?
Thanks.
Robert Dewar wrote:
> Oliver Kellogg wrote:
> > On 2009-04-19, at 23:19 +0200, Oliver Kellogg wrote:
> >>
Oliver Kellogg wrote:
On 2009-04-19, at 23:19 +0200, Oliver Kellogg wrote:
[...]
How about not doing the name expansion in-place but rather
storing the expanded name in an extra node field?
I haven't received any reaction on this question yet.
Perhaps I could reuse the Str3 field instead? (I
On 2009-04-19, at 23:19 +0200, Oliver Kellogg wrote:
> [...]
>
> How about not doing the name expansion in-place but rather
> storing the expanded name in an extra node field?
I haven't received any reaction on this question yet.
Perhaps I could reuse the Str3 field instead? (I haven't looked
int
On 2009-04-27, at 14:28, Tom Tromey wrote:
>
> Tom> I am curious how you handle locations on shared bits of the AST.
> Tom> I needed some disturbing hacks to make this work well for C.
>
> Oliver> I'm not sure what you mean; could you explain?
>
> In the server, the global line map is reset for e
> "Oliver" == Oliver Kellogg writes:
Tom> There are some differences in invocation. I designed the incremental
Tom> compiler so that no changes to user Makefiles would be needed; I don't
Tom> know whether that is a consideration with Ada.
Oliver> The idea is that gnatmake determines the tot
On 2009-04-27, at 12:19, Tom Tromey wrote:
>
> This sounds like it has a lot of overlap with the incremental compiler
> project I was working on. I think you could probably rearrange things
> to use the compile server infrastructure from the branch without
> trouble.
>
> There are some difference
> "Oliver" == Oliver Kellogg writes:
Oliver> First tests look very promising. I'm getting noticeable speedups
Oliver> of when supplying N interrelated bodies in a single call as opposed
Oliver> to N individual calls to gnat1. Precise measurements will follow.
This sounds like it has a lot of
On 2009-04-27 at 10:27, Ian Lance Taylor wrote:
>
> > gcc has a new command line switch, "-multi".
> > This tells gcc to forward all given input files to a single execution
> > of the compiler proper, in a similar way as done for "-combine".
>
> This is good work, but why not just reuse -combine?
oliver.kell...@t-online.de (Oliver Kellogg) writes:
> gcc has a new command line switch, "-multi".
> This tells gcc to forward all given input files to a single execution
> of the compiler proper, in a similar way as done for "-combine".
This is good work, but why not just reuse -combine? What i
Oliver Kellogg wrote:
Here's the current status of my work (see appended patch.)
This is great work, something we always thought about (as you
can see from some of the existing code), but seemed like a
very big task!
gnat1 can now handle multiple input files as previously
described (produce o
Here's the current status of my work (see appended patch.)
gnat1 can now handle multiple input files as previously
described (produce one assembly and ALI file per input file.)
First tests look very promising. I'm getting noticeable speedups
of when supplying N interrelated bodies in a single cal
On Mon, 2009-04-20 at 14:55 -0400, Geert Bosch wrote:
> > For an invocation
> > gnat1 a.adb b.adb c.adb
> > , the files a.{s,ali} b.{s,ali} c.{s,ali} are produced.
>
> The back end is not prepared to produce multiple assembly files.
> The "gcc" driver program also assumes each invocation produces
On Apr 20, 2009, at 14:45, Oliver Kellogg wrote:
It would be best to first contemplate what output a single
invocation of the compiler, with multiple compilation units
as arguments, should produce.
For an invocation
gnat1 a.adb b.adb c.adb
, the files a.{s,ali} b.{s,ali} c.{s,ali} are produced
Hi Geert,
Thanks for your answer - I was starting to feel I'm entertaining a
monologue here ;)
On Mon, 2009-04-20 at 13:05 -0400, Geert Bosch wrote:
>
> While this may be an interesting idea, there are some fundamental
> assumptions in the compiler that each compilation indeed processes
> a sin
On Apr 12, 2009, at 13:29, Oliver Kellogg wrote:
On Tue, 4 Mar 2003, Geert Bosch wrote:
[...]
Best would be to first post a design overview,
before doing a lot of work in order to prevent spending time
on implementing something that may turn out to have fundamental
problems.
I've done a lit
Anybody out there?
How about not doing the name expansion in-place but rather
storing the expanded name in an extra node field?
--Oliver
On 2009-04-18 at 21:35 +0200, Oliver Kellogg wrote:
> I've run up against a problem with reusing the GNAT trees:
> Apparently during semantic analysis entity
I've run up against a problem with reusing the GNAT trees:
Apparently during semantic analysis entity names are expanded
to their fully qualified names in the tree.
For example, when compiling the following file with the node
for System already installed by a previous compilation,
-- file: ext.ad
Interim note:
Apparently, calling compile_file() more than once has not been done
before?
I am seeing many global variables in cgraphunit.c that need to
be reinitialized in this case.
Also, some static variables are defined locally in functions, e.g.
'first_analyzed' and 'first_analyzed_var' in cg
Picking up an old thread,
http://gcc.gnu.org/ml/gcc/2003-03/msg00281.html
On Tue, 4 Mar 2003, Geert Bosch wrote:
> [...]
> Best would be to first post a design overview,
> before doing a lot of work in order to prevent spending time
> on implementing something that may turn out to have fundament
35 matches
Mail list logo
