egcs1.1b and gnat3.10p

egcs1.1b and gnat3.10p

[grave]

Hi all,

After compiling egcs-1.1b (on a solaris 2.6) with the following patch :
http://www.teaser.fr/~fabiven/gnat-3.10p-patch/egcs-1.1b-patch.gz

I tryed to compile the examples given with the sources of gnat
the example diners give the following error :
raised STORAGE_ERROR
example tgef doesn't do anything and
example text_io_example give :
raised ADA.IO_EXCEPTIONS.DATA_ERROR

any help possible on such kind of problem ?        

xavier

Re: egcs1.1b and gnat3.10p

[Juergen Pfeifer]

I don't believe that the patch is good enough.
One suspicious line is Line# 2720. There is

+           TYPE_SIZE (new_type) = TYPE_SIZE_UNIT (right_type);

and I believe it should be

+           TYPE_SIZE_UNIT (new_type) = TYPE_SIZE_UNIT (right_type);

Maybe there are more such locations. When I applied the patch and built
it on my Linux box using the bootstrap target of the Makefile, I got
errors in one of the higher stages in the object file comparision.
So I decided not to use that. I'm quite happy with my egcs-1.03 based
GNAT 3.10p on RedHat 5.1 which I built myself.

Cheers
Juergen

grave wrote:
> 
> Hi all,
> 
> After compiling egcs-1.1b (on a solaris 2.6) with the following patch :
> http://www.teaser.fr/~fabiven/gnat-3.10p-patch/egcs-1.1b-patch.gz
> 
> I tryed to compile the examples given with the sources of gnat
> the example diners give the following error :
> raised STORAGE_ERROR
> example tgef doesn't do anything and
> example text_io_example give :
> raised ADA.IO_EXCEPTIONS.DATA_ERROR
> 
> any help possible on such kind of problem ?
> 
> xavier

-- 
http://home.t-online.de/home/Juergen.Pfeifer

Re: egcs1.1b and gnat3.10p

[Frederic Abiven]

Hello,


Juergen.Pfeifer@t-online.de (Juergen Pfeifer) writes:

> I don't believe that the patch is good enough.
> One suspicious line is Line# 2720. There is
> 
> +           TYPE_SIZE (new_type) = TYPE_SIZE_UNIT (right_type);
> 
> and I believe it should be
> 
> +           TYPE_SIZE_UNIT (new_type) = TYPE_SIZE_UNIT (right_type);

Yes, it's a bug (by the way, it's on line 588 in a-trans4.c)

> Maybe there are more such locations. 

Perhaps ...

> When I applied the patch and built
> it on my Linux box using the bootstrap target of the Makefile, I got
> errors in one of the higher stages in the object file comparision.

Me too.

I think these errors are in change of link step (egcs-1.1b use
collect2) and symbol naming (for debugging purpose).

On my system (Redhat-4.0 + libc.so.5.4.44 + binutils-2.8.1.0.23), i need
another compile stage to suppress errors in the object file comparison.

Because of the use of collect2, gnatlink MUST use the ld of 
binutils-2.8.1.0.15 (or newer). 

> So I decided not to use that. I'm quite happy with my egcs-1.03 based
> GNAT 3.10p on RedHat 5.1 which I built myself.

For me, all tests in the example directory of gnat pass (diners, hello, 
etc ...).

But several other personal tests fail so i don't think this is 
really usable :-(.

Sorry for the trouble.



       -- FA


-- 
-- Frederic Abiven     home : <mailto:Frederic.ABIVEN@teaser.fr>
--

Re: egcs1.1b and gnat3.10p

[Richard Kenner]

In article <m267borf5b.fsf@marius.teaser.fr> fabiven@teaser.fr writes:
>For me, all tests in the example directory of gnat pass (diners, hello, 
>etc ...).
>
>But several other personal tests fail so i don't think this is 
>really usable :-(.

I don't think it's going to be at all easy to get a reliably working mix
of GNAT 3.10P and EGCS at the moment.  You can come quite close, but there
are likely to be some suble code generation problems remaining.

The patches that have been discussed deal with the fact that EGCS has
changed the interface between the front ends and the core compiler in
an incompatible way.  Those are relatively straightforward.

Much more subtle problems relate to GCC patches included with GNAT to
fix bugs in GCC 2.8.1 related to alias detection and instruction scheduling.
Some of these patches were not applied to EGCS and are not applicable there
as written due to major changes by EGCS in this area.

Dealing with this situation is not at all trivial.  However, as part of the
process of merging EGCS improvements back in GCC, some of these issues
will come up and I will deal with them over the next couple of months.

It's much too early to guess the practicability or timeframe of proving
patches to the various GCC code bases to deal with these issues.