[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

["charlet at act-europe dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From charlet at act-europe dot fr  2004-03-08 23:17 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

> I would run the binary regression hunter and find which of your changes has
> changed the way the compiler is broken.  This may give some clue about which

Do you mean that the binary regression hunter is not smart enough to
do that ? How does it work ? Can it be improved ? I have no problem
doing semi-manual regression hunting using e.g. dates.

> file is miscompiled.  Now, this time this is not that important, because my
> patch did break the compiler, but in the case of latent bugs it would be
> better to could track down the exact change that exposed the latent bug.

This time, it is completely unimportant and even misleading: Ada bootstrap had
been generally broken for a few days by another change, and fixed by
the change in trans.c, as I explained in my message to gcc-patches,
and as explained in the ChangeLog very clearly.

During the period Ada bootstrap was broken, you committed your change.

So knowing that trans.c is showing the new problem isn't going to help you
at all in this case, since in fact the problem is not 'new' to trans.c, and
would have appeared immediately, had Ada bootstrap not been broken.

Of course, having Ada enabled would have detected both (the general
bootstrap failure and your recent regression) failures early.

> The only necessary things for me to look at Ada failures (I *am* interested in
> them) would be more fine-grained commits and better source-code compatibility

As I said, the ChangeLog are completely fine-grained, so I still don't
understand what added value there would be.

Note that I am trying to understand and be constructive here: if there's
indeed an added value in having more fine-grained commits, then I'd
be willing to investigate it, but I don't see it.

> between GNAT releases (why should I compile 3.3 as an intermediate step if my
> distro only provides me with 3.2.x?).  Everything else is a plus, but these
> two are must-haves.

Actually current GNAT sources are still compatible with GNAT 3.13, we've
made sure of that. The only cases where a version more recent than
GNAT 3.13 is needed is when GNAT 3.13 (or any other version for that
matter) has a codegen bug that makes it unusable on a given target.

Arno


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14462