This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"
- From: "bonzini at gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Mar 2004 18:21:34 -0000
- Subject: [Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"
- References: <20040306175828.14462.danglin@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From bonzini at gnu dot org 2004-03-08 18:21 -------
Subject: Re: [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"
> As for committing Ada changes individually, I do not understand why this
would
> make a difference to you, since each change comes with a separate, complete
> entry in the changelog, so could you explain how it would help you to
> have the commits performed separately ? Why would it encourage you to
> enable Ada and look at Ada failures more than you do now ?
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
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.
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
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.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14462