> This code only works for one-complement machines, since it assumes a
> symmetric range for Int. It breaks when UI_To_Int returns Integer'First, as
> it did in this case. When it does, the abs produces an erroneous result
> (since checking is disabled). So it almost doesn't matter what it puts
> Just to be 100% clear, I'm leaving this one in the hands of the
> Ada maintainers. I'm not qualified to fix it. Once the Ada
> maintainers have this issue fixed, I'll re-run the Ada testsuite
> and attack the next regression introduced by the VRP changes
> (if any are left).
Sure. My message
Just to be 100% clear, I'm leaving this one in the hands of the
Ada maintainers. I'm not qualified to fix it.
Right.
We're also still need the uintp fix installed. I'm not qualified to
say if Kenner's fix is correct or not, thus I'm not comfortable
checking in that change.
On Thu, 2006-03-02 at 14:05 +0100, Eric Botcazou wrote:
> > # BLOCK 6
> > # PRED: 4 (false,exec)
> > :;
> > iftmp.78_63 = D.1309_32;
> > iftmp.78_64 = D.1309_32;
> > D.1316_65 = (c460008__unsigned_edge_8) D.1309_32;
> > if (D.1316_65 == 255) goto ; else goto ;
> > # SUCC: 7 (true,exec
> Excerpt from utils2.c:
>
> /* Likewise, but only return types known to the Ada source. */
> tree
> get_ada_base_type (tree type)
> {
> while (TREE_TYPE (type)
>&& (TREE_CODE (type) == INTEGER_TYPE
>
>|| TREE_CODE (type) == REAL_TYPE)
>
>&& !TYPE_EXTRA_SUBTYPE_P (typ
> # BLOCK 6
> # PRED: 4 (false,exec)
> :;
> iftmp.78_63 = D.1309_32;
> iftmp.78_64 = D.1309_32;
> D.1316_65 = (c460008__unsigned_edge_8) D.1309_32;
> if (D.1316_65 == 255) goto ; else goto ;
> # SUCC: 7 (true,exec) 8 (false,exec)
> [...]
> The problem (of course) is D.1316_65 can and
Here's the next segment in the ongoing saga of VRP vs Ada...
Not surprisingly we have another case where an object gets a
value outside of its TYPE_MIN_VALUE/TYPE_MAX_VALUE defined range.
Investigating the c460008 testsuite failure we have the following
code for Fixed_To_Short before VRP runs:
On Wed, 2006-03-01 at 08:24 -0500, Richard Kenner wrote:
> So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface
> issue, thanks for spotting this!
>
> Sorry, my last suggestion is clearly wrong. I think is right.
>
> *** uintp.adb 12 Sep 2003 21:50:56 - 1.80
So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface
issue, thanks for spotting this!
Sorry, my last suggestion is clearly wrong. I think is right.
*** uintp.adb 12 Sep 2003 21:50:56 - 1.80
--- uintp.adb 1 Mar 2006 13:16:21 -
*** package b
So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface
issue, thanks for spotting this!
Indeed, having looked a bit closer at Uintp, I think this is the right fix.
Robert, please confirm.
*** uintp.adb 12 Sep 2003 21:50:56 - 1.80
--- uintp.adb 1 Mar 2006 13:
On Tue, 2006-02-28 at 18:59 -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 28, 2006 at 03:40:37PM -0700, Jeffrey A Law wrote:
> > Here's a great example from uintp.adb (which is the cause of the
> > testsuite hang FWIW)
> >
> > We have a loop with the following termination code in uintp.num_bits
>
Jeffrey A Law wrote:
> I wouldn't have a problem with non-canonical bounds if there were
> no way to get a value into an object which is outside the
> bounds. But if we can get values into the object which are outside
> those bounds, then either the bounds are incorrect or the program
> is invali
We have a loop with the following termination code in uintp.num_bits
This sure looks like a bug in Num_Bits to me, not in the compilation
of the front-end.
The relevant code is:
function Num_Bits (Input : Uint) return Nat is
Bits : Nat;
Num : Nat;
begin
if UI_Is_In_
Which doesn't mean that Ada is DTRT. On the contrary, Ada ought to be
fixed. It's an ugly hack in extract_range_from_assert:
It wasn't a bug in the Ada front end, but in fold, which was long-ago
fixed. I thought this was removed a long time ago?
Basically with the way Ada's setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE
effectively makes them useless as we can not rely on them to
actually reflect the set of values allowed in an object.
As we've all told you numerous times before, TYPE_MIN_VALUE/TYPE_MAX_VALUE
are meant *precisely*
On Tue, Feb 28, 2006 at 03:40:37PM -0700, Jeffrey A Law wrote:
> Here's a great example from uintp.adb (which is the cause of the
> testsuite hang FWIW)
>
> We have a loop with the following termination code in uintp.num_bits
>
> # BLOCK 8
> # PRED: 5 [100.0%] (fallthru,exec) 6 (fallthru,dfs
On Tue, 2006-02-28 at 17:51 -0500, Diego Novillo wrote:
> Jeffrey A Law wrote:
>
> > Diego -- do you recall what code actually triggered this problem?
> >
> Not sure, exactly.
>
> However, in figuring out what this code was working around, I remembered
> this thread from Kenner where he fixed thi
Jeffrey A Law wrote:
> Diego -- do you recall what code actually triggered this problem?
>
Not sure, exactly.
However, in figuring out what this code was working around, I remembered
this thread from Kenner where he fixed this particular FE bug:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01347.
On Tue, 2006-02-28 at 18:50 +0100, Eric Botcazou wrote:
> > It's an ugly hack in extract_range_from_assert:
> >
> > /* Special handling for integral types with super-types. Some FEs
> > construct integral types derived from other types and restrict
> > the range of values these new typ
On Tue, 2006-02-28 at 18:42 +0100, Eric Botcazou wrote:
> > Basically with the way Ada's setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE
> > effectively makes them useless as we can not rely on them to
> > actually reflect the set of values allowed in an object.
>
> Sorry, but why are you saying "we can
> It's an ugly hack in extract_range_from_assert:
>
> /* Special handling for integral types with super-types. Some FEs
> construct integral types derived from other types and restrict
> the range of values these new types may take.
>
> It may happen that LIMIT is actually smaller
> Basically with the way Ada's setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE
> effectively makes them useless as we can not rely on them to
> actually reflect the set of values allowed in an object.
Sorry, but why are you saying "we can not rely on them to actually reflect the
set of values allowed in
On 2/28/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Eric Botcazou wrote:
>
> > This problem was already raised when Diego contributed the VRP pass and
> > Diego
> > ajusted it to cope with Ada. AFAIK Ada and VRP work fine on the 4.1 branch.
> >
> Which doesn't mean that Ada is DTRT. On the co
Eric Botcazou wrote:
> This problem was already raised when Diego contributed the VRP pass and Diego
> ajusted it to cope with Ada. AFAIK Ada and VRP work fine on the 4.1 branch.
>
Which doesn't mean that Ada is DTRT. On the contrary, Ada ought to be
fixed. It's an ugly hack in extract_range_
On Tue, 2006-02-28 at 12:06 +0100, Eric Botcazou wrote:
> [Sorry for the delay]
No worries.
> I was actually referring to explicit constraints on TYPE_MAX_VALUE and
> TYPE_MIN_VALUE derived from TYPE_PRECISION and TYPE_UNSIGNED, for example
> that ceil(log2(TYPE_MAX_VALUE - TYPE_MIN_VALUE)) must
[Sorry for the delay]
> > That's an old problem, which has already been discussed IIRC: should
> > TYPE_MAX_VALUE/TYPE_MIN_VALUE be constrained by TYPE_PRECISION and
> > TYPE_UNSIGNED?
>
> My feeling? Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
> represent the set of values that an objec
On Wed, Feb 22, 2006 at 10:06:25AM -0700, Jeffrey A Law wrote:
> > > This does highlight one of the issues that keeps nagging at me.
> > > For an enumeration type, presumably we have TYPE_PRECISION set to
> > > the minimum precision necessary to hold all the values in the enum.
> > > What are TYPE_
On Wed, 2006-02-22 at 09:00 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
>
> > This does highlight one of the issues that keeps nagging at me.
> > For an enumeration type, presumably we have TYPE_PRECISION set to
> > the minimum precision necessary to hold all the values in the enum.
> > Wha
Jeffrey A Law wrote:
> This does highlight one of the issues that keeps nagging at me.
> For an enumeration type, presumably we have TYPE_PRECISION set to
> the minimum precision necessary to hold all the values in the enum.
> What are TYPE_MIN_VAL/TYPE_MAX_VAL?Does TYPE_MAX_VALUE include
> va
On Tue, 2006-02-21 at 14:56 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
>
> > My feeling? Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
> > represent the set of values that an object of the type may hold.
> > Any other definition effectively renders those values useless.
>
> I agre
On Wed, 2006-02-22 at 11:51 +0100, Richard Guenther wrote:
> On 2/21/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Jeffrey A Law wrote:
> >
> > > My feeling? Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
> > > represent the set of values that an object of the type may hold.
> > > Any oth
On 2/21/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Jeffrey A Law wrote:
>
> > My feeling? Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
> > represent the set of values that an object of the type may hold.
> > Any other definition effectively renders those values useless.
>
> I agree --
Jeffrey A Law wrote:
> My feeling? Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
> represent the set of values that an object of the type may hold.
> Any other definition effectively renders those values useless.
I agree -- with the obvious caveat that it need not be the case that the
obj
On Sun, 2006-02-19 at 20:15 +0100, Eric Botcazou wrote:
> >"Now for the first "oddity". If we look at the underlying type
> > for last we have a type "natural___XDLU_0__2147483647". What's
> >interesting about it is that it has a 32bit type precision, but
> > the min/max values only specify 31 b
"Second, for a given integer type (such as
natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647.
ie, the type of an integer constant should be the same as the type of
its min/max values."
No, th
> Anyway, hopefully Eric and Jeff can work together in identifying the
> proper fix.
Jeff already did a thorough analysis of the problem (thanks!) and came to the
following double conclusion. Quoting him:
"First, the inconsistency between the type's precision in its min/max
values needs to be f
Andrew Pinski writes:
>
> On Feb 19, 2006, at 12:09 PM, Andrew Haley wrote:
>
> > When building a-textio in libada, today's gcc build fails when memory
> > is exhausted.
>
> This has already been reported as PR 26348 and it looks like a bug
> in the Ada front-end.
Oh right, thanks. Was
Andrew Haley <[EMAIL PROTECTED]> writes:
> When building a-textio in libada, today's gcc build fails when memory
> is exhausted.
This is PR26348.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58
> This has already been reported as PR 26348 and it looks like a bug
> in the Ada front-end.
Note that technically, its still a regression caused by a non Ada patch.
Anyway, hopefully Eric and Jeff can work together in identifying the
proper fix.
Arno
On Feb 19, 2006, at 12:09 PM, Andrew Haley wrote:
When building a-textio in libada, today's gcc build fails when memory
is exhausted.
This has already been reported as PR 26348 and it looks like a bug
in the Ada front-end.
Thanks,
Andrew Pinski
40 matches
Mail list logo
