Compiler Revisions Should go Out As Well as Going Up.

Compiler Revisions Should go Out As Well as Going Up.

[Austin Obyrne]

Decoded, I am saying here that there is a tendency in my opinion to view new compiler versions in a hierarchal sequence that tacitly suggest one should always use the most recent compiler version.  I don’t think this is right and instead older compilers should still be kept in hand as befits the users’ needs for specific applications without any suggestion of being outdated.  Very often there is nothing to be gained except a whole load of trouble in changing to newer compiler versions of the same language.

I’m sure the custodians of the Ada language know what they are doing just the same.

adacrypt

Re: Compiler Revisions Should go Out As Well as Going Up.

[Simon Clubley]

On 2013-12-11, Austin Obyrne <austin.obyrne@hotmail.com> wrote:
> Decoded, I am saying here that there is a tendency in my opinion to view new
> compiler versions in a hierarchal sequence that tacitly suggest one should
> always use the most recent compiler version.  I don?t think this is right and
> instead older compilers should still be kept in hand as befits the users?
> needs for specific applications without any suggestion of being outdated.
> Very often there is nothing to be gained except a whole load of trouble in
> changing to newer compiler versions of the same language.

Actually, I don't use the most recent compiler versions. However, I also don't
use compiler versions from around the late 1990s.

I do quite a bit of embedded work as a hobby and hence I have multiple gcc
toolchain versions installed for the various embedded environments I use.

About every couple of years or so, I go through a sequence of upgrading the
embedded and native gcc versions so that the oldest version is dropped and a
more recent version than the most recent version I was using is installed.
That's not the very latest version at that time, but a version that's been
out for a while and is perceived as a stable version.

I also use the same compiler toolchain versions to compile code written in
other languages such as C and C++ so that's also a factor as well as well
as the fact the packages being compiled have their own minimum required
gcc versions.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Compiler Revisions Should go Out As Well as Going Up.

[Austin Obyrne]

On Wednesday, December 11, 2013 1:04:41 PM UTC, Simon Clubley wrote:
> On 2013-12-11, Austin Obyrne <austin.obyrne@hotmail.com> wrote: > Decoded, I am saying here that there is a tendency in my opinion to view new > compiler versions in a hierarchal sequence that tacitly suggest one should > always use the most recent compiler version. I don?t think this is right and > instead older compilers should still be kept in hand as befits the users? > needs for specific applications without any suggestion of being outdated. > Very often there is nothing to be gained except a whole load of trouble in > changing to newer compiler versions of the same language. Actually, I don't use the most recent compiler versions. However, I also don't use compiler versions from around the late 1990s. I do quite a bit of embedded work as a hobby and hence I have multiple gcc toolchain versions installed for the various embedded environments I use. About every couple of years or so, I go through a sequence of upgrading the embedded and native gcc versions so that the oldest version is dropped and a more recent version than the most recent version I was using is installed. That's not the very latest version at that time, but a version that's been out for a while and is perceived as a stable version. I also use the same compiler toolchain versions to compile code written in other languages such as C and C++ so that's also a factor as well as well as the fact the packages being compiled have their own minimum required gcc versions. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world

I must confess to being a bit blinkered in my outlook possibly because of my preoccupation with cryptography but I am trying hard also to empathise with you guys who are up front at the cutting edge of all the diverse applications to Ada.

My overview (admittedly as a layman) is that the current 'one compiler does all is' modus operandi is extravagant in many cases that do not need the update.

I use a concept of mutual databases in my cryptography which if you think about is also very prevalent in commerce, military. financial situations.

In essence then the question boils down to this? would Ada be better deployed by becoming fragmented to suit a wider scope of needs instead of one all powerful compiler that fits all cases but with considerable redundancy.  

I repeat " The custodians of the langauge will no doubt have given much thought to this" 

Given that it is still early days in IT (even half a century is quite samll compared with other sciences and technologies)there is still vast changes to come in fighting malaware infections, identity theft, information security etc.

Ada programming will see much more change still to come in my view - it is not ridiculous to suggest rationalising this change as I am suggesting here.

Austin O'Byrne

Re: Compiler Revisions Should go Out As Well as Going Up.

[Pascal Obry]

Le 11/12/2013 13:11, Austin Obyrne a écrit :
> Decoded, I am saying here that there is a tendency in my opinion to
> view new compiler versions in a hierarchal sequence that tacitly
> suggest one should always use the most recent compiler version.

Right.

>  I don’t think this is right 

Wrong.

> and instead older compilers should still be
> kept in hand as befits the users’ needs for specific applications
> without any suggestion of being outdated. 

That's a really strange view. First many bugs are fixed from version to
version and the code being generated is always going in the right
direction. And since you noted that in another thread there is a huge
set of bug fixed since 3.11p in GNAT GPL 2013. The backend (GCC) has
also been updated many times since then and is generating lot faster code.

> Very often there is
> nothing to be gained except a whole load of trouble in changing to
> newer compiler versions of the same language.

That's plain wrong. And almost an insult to the people who have
development the compiler since all those years!

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Compiler Revisions Should go Out As Well as Going Up.

[Simon Wright]

Pascal Obry <pascal@obry.net> writes:

> Le 11/12/2013 13:11, Austin Obyrne a écrit :

>> Very often there is nothing to be gained except a whole load of
>> trouble in changing to newer compiler versions of the same language.
>
> That's plain wrong. And almost an insult to the people who have
> development the compiler since all those years!

For most people there's good reason to at least try the latest
version. Of course you need a good set of regression tests to be able to
do this!

But in some cases upgrading is a real problem. I'm thinking of systems
that have gone through extensive and expensive validation exercises,
including for example avionics flight tests or missile firings; even if
you trust the compiler team, you'll have an uphill task to persuade the
person who signs off (Design Authority, Chief Engineer, ...).

GNAT 5.02a1 had an off-the-cuff remark a long way down a release note
that for a certain architecture (the one we were using!) there was a
one-in-millions chance that a function result would be corrupted,
because the epilogue code wasn't interrupt-safe; you could use a switch
(-fno-something-or-other that I don't remember) to prevent
this. Needless to say we abandoned the upgrade.

Re: Compiler Revisions Should go Out As Well as Going Up.

[adambeneschan]

On Wednesday, December 11, 2013 6:16:35 AM UTC-8, Simon Wright wrote:

> But in some cases upgrading is a real problem. I'm thinking of systems
> that have gone through extensive and expensive validation exercises,
> including for example avionics flight tests or missile firings; even if
> you trust the compiler team, you'll have an uphill task to persuade the
> person who signs off (Design Authority, Chief Engineer, ...).

Yup.  I was involved in a project where the customer wanted the compiler ported from one host to another, but for the same embedded target.  One of their desires was for the compiler on the new host to generate the exact same binary code as the previous host; even if the compiler generated incorrect code, they wanted the new compiler to generate the same incorrect code so that they wouldn't need to revalidate.

Another somewhat similar issue comes up when a compiler incorrectly accepts illegal Ada code, and because of that, the customer gets their program working with illegal Ada in it.  Then they run into problems with newer versions of the compiler that have the bug fixed.  I've had to add a number of "compatibility" options to our Ada compiler to get it to accept illegal code that was incorrectly accepted by a 15-year-old version of the compiler.  (Or, sometimes, by some other vendor's compiler.)

                               -- Adam

Re: Compiler Revisions Should go Out As Well as Going Up.

[Shark8]

On Wednesday, December 11, 2013 8:56:38 AM UTC-7, adambe...@gmail.com wrote:
> 
> Another somewhat similar issue comes up when a compiler incorrectly accepts illegal Ada code, and because of that, the customer gets their program working with illegal Ada in it.  Then they run into problems with newer versions of the compiler that have the bug fixed.  I've had to add a number of "compatibility" options to our Ada compiler to get it to accept illegal code that was incorrectly accepted by a 15-year-old version of the compiler.  (Or, sometimes, by some other vendor's compiler.)


Yeah, it would have been good if GNAT had altered the defaults (at least in Ada2012-mode) to support aspects by-default. (The use of many aspects is reliant on assertions being in CHECKED-mode, which isn't on by default.)

Re: Compiler Revisions Should go Out As Well as Going Up.

[Pascal Obry]

Le 11/12/2013 15:16, Simon Wright a écrit :
> For most people there's good reason to at least try the latest
> version. Of course you need a good set of regression tests to be able to
> do this!
> 
> But in some cases upgrading is a real problem. I'm thinking of systems
> that have gone through extensive and expensive validation exercises,
> including for example avionics flight tests or missile firings; even if
> you trust the compiler team, you'll have an uphill task to persuade the
> person who signs off (Design Authority, Chief Engineer, ...).
> 
> GNAT 5.02a1 had an off-the-cuff remark a long way down a release note
> that for a certain architecture (the one we were using!) there was a
> one-in-millions chance that a function result would be corrupted,
> because the epilogue code wasn't interrupt-safe; you could use a switch
> (-fno-something-or-other that I don't remember) to prevent
> this. Needless to say we abandoned the upgrade.
> 

Sure but that's quite different as the OP saying that there is nothing
to gain to upgrade except troubles. And I was reacting to that.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B