Re: [PATCH] Adjust develop.html to reflect recent practice
On Sun, 27 Sep 2009, Gerald Pfeifer wrote: > On Sun, 20 Sep 2009, Richard Guenther wrote: > > As commented to my last status report develop.html does not reflect > > reality anymore. The following tries to adjust it carefully in > > this respect. > > I believe you got the math wrong in one case, when you went from > four months that a branch will need to be maintained in the old > model up to six months. Is it possible you ment to substract the > two months Stage 2 used to take instead of add it? Indeed, I mixed in the length of stage1. Four month would be still about correct (2 month stage3 plus 2 month before we branch, in the old model it was 2 month stage2 plus 2 month stage3). > Since it seems hard to predicat the time between the end of Stage 3 > and branching, I suggest to just say "a few months". > > The patch below does that in its last hunk and makes one or the > other editorial change. > > Thoughts? Ok with me. Thanks, Richard.
libgcc rpaths with --enable-version-specific-runtime-libs
when libgcc multilibs are built the Makefile forces two vars to be
empty during the build phase viz:
slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR)
unfortunately, "libsubdir" is used in configure.ac like this.
AC_ARG_WITH(slibdir,
[ --with-slibdir=DIR shared libraries in DIR [LIBDIR]],
slibdir="$with_slibdir",
if test "${version_specific_libs}" = yes; then
slibdir='$(libsubdir)'
elif test -n "$with_cross_host" && test x"$with_cross_host" != x"no";
then
slibdir='$(exec_prefix)/$(host_noncanonical)/lib'
else
slibdir='$(libdir)'
fi)
AC_SUBST(slibdir)
and slibdir :
shlib_slibdir = @slibdir@
and shlib_slibdir ends up as the path for the instal_name (via
shlib_slibdir expansion in the LINK fragment).
== the upshot is that (at least on dawin) when building with "--
enable-version-specific-runtime-libs"
libgcc gets built with
/libgcc_s.1.dylib
as the embedded rpath
This then gets referenced by the other libs (e.g. libgfortran.dylib)
[ because the stub libs 10.X refer to it].
Whilst the libgcc path is corrected in the install phase; the
references in the other libraries are not.
libsubdir is expanded
libsubdir = $(libdir)/gcc/$(host_noncanonical)/$(version)
in Makefile.in.
If this expansion is applied in configure.ac, all works OK on darwin.
i.e.
if test "${version_specific_libs}" = yes; then
slibdir='$(libdir)/gcc/$(host_noncanonical)/$(version)'
Would that change cause a problem on any other target?
Iain
Re: [gnat] reuse of ASTs already constructed
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.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?
Thanks,
Oliver
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
>http://gcc.gnu.org/ml/gcc-help/2009-08/msg00113.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. 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
> > > > http://gcc.gnu.org/ml/gcc/2009-04/msg00380.html)
> > > > 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
> >
gcc-4.3-20090927 is now available
Snapshot gcc-4.3-20090927 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090927/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 152226 You'll find: gcc-4.3-20090927.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090927.tar.bz2 C front end and core compiler gcc-ada-4.3-20090927.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090927.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090927.tar.bz2 C++ front end and runtime gcc-java-4.3-20090927.tar.bz2 Java front end and runtime gcc-objc-4.3-20090927.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090927.tar.bz2The GCC testsuite Diffs from 4.3-20090920 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
