Re: GNAT GPL 2005 Edition is now available

[Florian Weimer <fw@deneb.enyo.de>]

* Ludovic Brenta:

> Florian Weimer <fw@deneb.enyo.de> writes:
>> GNAT 3.15p has no AMD64 support, and the tasking run-time is broken
>> on multiprocessor systems on x86.  (Could be a kernel bug on this
>> particular machine, I don't have many SMP systems to test,
>> obviously.)
>
> I have a dual Pentium II @300 MHz, where Ada tasking programs utilise
> both processors without a problem (Debian Sarge, Linux 2.4.27, gnat
> 3.15p-12).

Ah, I saw the problems on a quad-Xeon machine (with hyperthreading),
Linux 2.6.0-test9 (slightly patched, don't ask) and NTPL.  The latter
is probably the culprit.

>> This will be painful for me because I cannot use your GNAT packages
>> anymore.
>
> You can use my packages for as long as you use Sarge :)

I use unstable because I feel I need security support. 8-)

> More seriously, your desire for support for amd64 is one good reason
> to move forward. 

To some extent, yes.  But if AdaCore doesn't manage to base a stable
compiler on current 4.x releases (which is a real possibility we
should consider), 3.4 won't buy us that much, especially if AdaCore
won't make any further GNAT GPL releases.

AMD64 shows that even in today's marketplace, it's possible to
introduce a new instruction set and gain at least some relevance.
This is quite surprising.  Otherwise, I would have thought that x86
and SPARC support would have sufficed for years to come (with problems
in the area of tasking, sure, but this is a different issue).

> GNAT GPL 2005 Edition is based on GCC 3.4.4 (with
> several patches).  It may or may not ICE on your code like GCC 3.4
> does.  I suggest you try it and decide for yourself which one suits
> you best.

Okay, downloaded it and ran it through my testsuite.  It passes, on
x86 at least.  However, there are two quite unsettling warnings: one
about an initialized variable of type Exception_Occurrence (the RM
guarantees that objects of this type are initialized to
Null_Occurrence), and a claim that a certain expression is always
false, which doesn't seem to match reality.  (Both issues are also
present in the GCC 4 codebase.)

There's also a new restriction on pragma Inline_Always: it can't be
applied to dispatching subprograms.  This doesn't make much sense
because often, the tag is known at compile time, so cross-compilation
unit inlining would still be possible.

>> But unless there's a perspective for de-facto support of GNAT (with
>> regular releases, and new platforms such as AMD64), I expect that
>> I'll have to rewrite the software anyway. 8-(
>
> I will try to support whichever version of GNAT is chosen for
> Debian.

And I'm grateful for your work. 8-)