> > On irc today we were discussing handling 'this' in gcj. We can add an
> > attribute to the argument to mark it as non-null... but strangely
> > there doesn't seem to be a way to mark other local variables as
> > known-non-null -- a curious deficiency.
> It seems to me that for other locals tha
On 03/31/06 04:08, Jeffrey A Law wrote:
> Then we just need to make VRP not be so quick to ignore statements
> with virtual operands (ie, the same problem we need to solve if
> VRP is going to be able to use non-null attributes on function
> return values).
>
Certainly. The approach I had sketch
On Fri, 2006-03-31 at 09:55 +0100, Andrew Haley wrote:
> Well, it's not just functionss but also global variables. AFAICS
> there are three sources of data: args, retvals, and globals. And
> there are quite a few of these globals we can usefully tag as "known
> never to be null".
Seems to me the
Jeffrey A Law writes:
> On Thu, 2006-03-30 at 18:39 +0100, Andrew Haley wrote:
> > Jeffrey A Law writes:
> > > On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:
> > >
> > > > On irc today we were discussing handling 'this' in gcj. We can add an
> > > > attribute to the argument to ma
> "Jeff" == Jeffrey A Law <[EMAIL PROTECTED]> writes:
Jeff> It seems to me that for other locals that the non-null property
Jeff> ought to be a property of how those locals are assigned a value.
Yeah, thanks for the re-frame. This is PR 20318, and also related to
PR 21856.
Tom
On Thu, 2006-03-30 at 18:39 +0100, Andrew Haley wrote:
> Jeffrey A Law writes:
> > On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:
> >
> > > On irc today we were discussing handling 'this' in gcj. We can add an
> > > attribute to the argument to mark it as non-null... but strangely
> >
On Tue, 2006-03-28 at 23:49 +0200, Duncan Sands wrote:
> That still leaves the problem of how the Ada front-end tells the
> middle-end that a variable is known to be in a certain range. Due
> to the way the language works, the front-end often does know a useful
> range, helpful for optimisation.
Jeffrey A Law writes:
> On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:
>
> > On irc today we were discussing handling 'this' in gcj. We can add an
> > attribute to the argument to mark it as non-null... but strangely
> > there doesn't seem to be a way to mark other local variables as
On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:
> On irc today we were discussing handling 'this' in gcj. We can add an
> attribute to the argument to mark it as non-null... but strangely
> there doesn't seem to be a way to mark other local variables as
> known-non-null -- a curious deficien
On 03/30/06 07:24, Duncan Sands wrote:
> On Wednesday 29 March 2006 23:28, Tom Tromey wrote:
>
>> On irc today we were discussing handling 'this' in gcj. We can add an
>> attribute to the argument to mark it as non-null... but strangely
>> there doesn't seem to be a way to mark other local variabl
On Wednesday 29 March 2006 23:28, Tom Tromey wrote:
> > "Duncan" == Duncan Sands <[EMAIL PROTECTED]> writes:
>
> Duncan> That still leaves the problem of how the Ada front-end tells the
> Duncan> middle-end that a variable is known to be in a certain range. Due
> Duncan> to the way the langua
> "Duncan" == Duncan Sands <[EMAIL PROTECTED]> writes:
Duncan> That still leaves the problem of how the Ada front-end tells the
Duncan> middle-end that a variable is known to be in a certain range. Due
Duncan> to the way the language works, the front-end often does know a useful
Duncan> range
Hi Jeff, thanks for the info.
> > I agree that this kind of special casing by the middle-end is all
> > wrong - the front-end should do it.
> I'd disagree. While it may at first seem useful to have ASSERT_EXPRs
> live through the entire optimization pipeline, they're actually going
> to get in th
On Tue, 2006-03-28 at 01:03 +0200, Duncan Sands wrote:
> Hi Jeff,
>
> On Monday 27 March 2006 21:00, Jeffrey A Law wrote:
> > On Sat, 2006-03-25 at 10:35 -0500, Diego Novillo wrote:
> >
> > > Start by looking at tree-vrp.c:infer_value_range.
> > I'm not so sure this is the best place to start.
>
Hi Jeff,
On Monday 27 March 2006 21:00, Jeffrey A Law wrote:
> On Sat, 2006-03-25 at 10:35 -0500, Diego Novillo wrote:
>
> > Start by looking at tree-vrp.c:infer_value_range.
> I'm not so sure this is the best place to start.
it seems a good place for adding ASSERT_EXPRs on function return
value
On Sat, 2006-03-25 at 10:35 -0500, Diego Novillo wrote:
> Start by looking at tree-vrp.c:infer_value_range.
I'm not so sure this is the best place to start.
It seems to me that the asserts could be registered at the
start of insert_range_assertions.
Just walk the parameter list and extract the d
On 03/25/06 09:12, Duncan Sands wrote:
> I'm quite interested in trying out this scheme. Unfortunately it's not clear
> to me how I would go about finding which variables are subroutine parameters,
> and adding ASSERT_EXPRs for them; any hints would be welcome.
>
Probably not a bad idea to test.
Hi Jeff,
> > By the way, I hacked tree-vrp to start all value ranges for INTEGRAL_TYPE_P
> > variables to [TYPE_MIN, TYPE_MAX]. It certainly helps with eliminating many
> > Ada range checks. Maybe the compiler will even bootstrap :)
> The thing to check will be compile-time performance -- in gen
On Fri, 2006-03-24 at 18:50 +0100, Duncan Sands wrote:
> Hi Jeff, while your patch catches many cases, the logic seems a bit wonky
> for types with TYPE_MIN/TYPE_MAX different to those that can be deduced
> from TYPE_PRECISION. For example, there is nothing stopping inner_type
> having a bigger T
On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
> >
> > int u (unsigned char
On Thursday 23 March 2006 17:14, Andrew Pinski wrote:
>
> On Mar 23, 2006, at 11:10 AM, Richard Guenther wrote:
> >
> >
> > Well - we could hack a new type attribute to specify min/max values...
>
> Or maybe try to using C++ instead since C++ rules for enums are
> different
> than C :).
Well,
On Mar 23, 2006, at 11:10 AM, Richard Guenther wrote:
Well - we could hack a new type attribute to specify min/max values...
Or maybe try to using C++ instead since C++ rules for enums are
different
than C :).
-- Pinski
On 3/23/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-23 at 10:40 +0100, Duncan Sands wrote:
> > Hi Jeff, this seems to work nicely - thanks again. I still see a bunch
> > of suboptimal range calculations in the Ada code I'm looking at, but these
> > now just coming from having ev
On Thu, 2006-03-23 at 10:40 +0100, Duncan Sands wrote:
> Hi Jeff, this seems to work nicely - thanks again. I still see a bunch
> of suboptimal range calculations in the Ada code I'm looking at, but these
> now just coming from having everything initialised to VR_VARYING rather than
> [TYPE_MIN, T
> Which ones?
PR tree-optimization/26797.
--
Eric Botcazou
On Thursday 23 March 2006 11:31, Eric Botcazou wrote:
> > Hi Jeff, this seems to work nicely - thanks again.
>
> Well, this has introduced 3 regressions in the ACATS testsuite on x86/x86-64.
Which ones?
Ciao,
Duncan.
> Hi Jeff, this seems to work nicely - thanks again.
Well, this has introduced 3 regressions in the ACATS testsuite on x86/x86-64.
--
Eric Botcazou
On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
> >
> > int u (unsigned char
On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
> >
> > int u (unsigned char
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
> Hi Jeff, on the subject of seeing through typecasts, I was playing around
> with VRP and noticed that the following "if" statement is not eliminated:
>
> int u (unsigned char c) {
> int i = c;
>
> if (i < 0 || i > 255)
>
On Tue, 2006-03-21 at 11:29 -0500, Diego Novillo wrote:
> On 03/21/06 03:25, Laurent GUERBY wrote:
>
> > A casual read of tree-vrp.c showed that symbolic_range_p is mostly
> > used to do nothing, did I miss something? May be it's in another file.
> >
> That's correct. We mostly punt on symbolic
On Tue, 2006-03-21 at 18:13 +0100, Duncan Sands wrote:
> Is memory use a problem here? VR_VARYING has the advantage of using
> a bit less memory. On the other hand, I guess you could introduce the
> convention that VR_RANGE with null min/mae means to use TYPE_MIN/
> TYPE_MAX, or something along
On 03/21/06 12:14, Tom Tromey wrote:
>> "Jeff" == Jeffrey A Law <[EMAIL PROTECTED]> writes:
>
> Jeff> Note that this is closely related to some of the bounds checking
> Jeff> elimination we want to support for Java one day IIRC.
>
> My understanding from the PR (21855) is that this is stuck o
> "Jeff" == Jeffrey A Law <[EMAIL PROTECTED]> writes:
Jeff> Note that this is closely related to some of the bounds checking
Jeff> elimination we want to support for Java one day IIRC.
My understanding from the PR (21855) is that this is stuck on
aliasing, not VRP -- the VRP parts supposedly
On Tuesday 21 March 2006 18:01, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 17:41 +0100, Duncan Sands wrote:
>
> > Should it be? I was surprised to see that all ranges are initialised
> > to VR_VARYING in the vrp pass, since many types have natural ranges
> > associated with them, for example [0
On Tue, 2006-03-21 at 17:41 +0100, Duncan Sands wrote:
> Should it be? I was surprised to see that all ranges are initialised
> to VR_VARYING in the vrp pass, since many types have natural ranges
> associated with them, for example [0, 255] for the above unsigned char;
> starting off with this na
On Tuesday 21 March 2006 17:15, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
> >
> > int u (unsigned char
On 03/21/06 03:25, Laurent GUERBY wrote:
> A casual read of tree-vrp.c showed that symbolic_range_p is mostly
> used to do nothing, did I miss something? May be it's in another file.
>
That's correct. We mostly punt on symbolic ranges because they are
fairly expensive to track. We do try to use
On Mar 21, 2006, at 11:15 AM, Jeffrey A Law wrote:
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
Hi Jeff, on the subject of seeing through typecasts, I was playing
around
with VRP and noticed that the following "if" statement is not
eliminated:
int u (unsigned char c) {
in
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
> Hi Jeff, on the subject of seeing through typecasts, I was playing around
> with VRP and noticed that the following "if" statement is not eliminated:
>
> int u (unsigned char c) {
> int i = c;
>
> if (i < 0 || i > 255)
>
> > I think that it is easy for back end to make good use of
> > TYPE_MIN_VALUE/TYPE_MAX_VALUE. Namely, consider the assignment
> >
> > x := y + z * w;
> >
> > where variables y, z and w have values in the interval [0,7] and
> > x have values in [0,1000]. Pascal converts the above to the
> > foll
On Mon, 2006-03-20 at 19:47 -0700, Jeffrey A Law wrote:
> On Sat, 2006-03-18 at 10:24 +0100, Laurent GUERBY wrote:
> > On Fri, 2006-03-17 at 12:51 -0700, Jeffrey A Law wrote:
> > > I'm not suggesting the FEs deduce more types and track ranges;
> > > that would be rather absurd. What I'm saying is
On Sat, 2006-03-18 at 10:24 +0100, Laurent GUERBY wrote:
> On Fri, 2006-03-17 at 12:51 -0700, Jeffrey A Law wrote:
> > I'm not suggesting the FEs deduce more types and track ranges;
> > that would be rather absurd. What I'm saying is that exposing
> > these types outside the FE is most likely cost
On Fri, 2006-03-17 at 12:51 -0700, Jeffrey A Law wrote:
> I'm not suggesting the FEs deduce more types and track ranges;
> that would be rather absurd. What I'm saying is that exposing
> these types outside the FE is most likely costing you both on
> the compile-time side and on the run-time side.
On Tue, 2006-03-14 at 03:16 +0100, Waldek Hebisch wrote:
> I think that it is easy for back end to make good use of
> TYPE_MIN_VALUE/TYPE_MAX_VALUE. Namely, consider the assignment
>
> x := y + z * w;
>
> where variables y, z and w have values in the interval [0,7] and
> x have values in [0,1000
On Fri, 2006-03-17 at 15:07 +0100, Waldek Hebisch wrote:
> Robert Dewar wrote:
> > Laurent GUERBY wrote:
> > > On Mon, 2006-03-13 at 15:31 -0700, Jeffrey A Law wrote:
> > >> On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> > >>
> > >>> What do you mean by "abuse"? TYPE_MAX_VALUE means ma
Robert Dewar wrote:
> Laurent GUERBY wrote:
> > On Mon, 2006-03-13 at 15:31 -0700, Jeffrey A Law wrote:
> >> On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> >>
> >>> What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> >>> allowed by given type.
> >> As long as you're *abso
On 3/16/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>
> On Mar 16, 2006, at 8:10 AM, Richard Guenther wrote:
>
> > The above was for 4.1.0 - with mainline gigi now generates
> >
> > if (i == 0 || i > 10)
> > {
> > __gnat_rcheck_06 ("t2.adb", 7);
> > }
> > else
> > {
> >
> >
On Mar 16, 2006, at 8:10 AM, Richard Guenther wrote:
The above was for 4.1.0 - with mainline gigi now generates
if (i == 0 || i > 10)
{
__gnat_rcheck_06 ("t2.adb", 7);
}
else
{
}
x[() (t2__TrB) i]{lb: 1 sz: 4} = 0;
huh? That's even more bogus.
It might not be g
On 3/16/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 3/16/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > procedure T2 is
> >type R is range 1 .. 10;
> >type T is array (R) of Integer;
> >I : R;
> >X : T;
> > begin
> >X (I) := 0;
> > end T2;
> >
> > The Ada FE will ins
On 3/16/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-16 at 10:43 +0100, Richard Guenther wrote:
> > On 3/16/06, Geert Bosch <[EMAIL PROTECTED]> wrote:
> > >
> > > On Mar 16, 2006, at 05:09, Robert Dewar wrote:
> > > > Not quite right. If you have an uninitialized variable, the va
On 3/16/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 3/16/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > On Thu, 2006-03-16 at 10:43 +0100, Richard Guenther wrote:
> > > On 3/16/06, Geert Bosch <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On Mar 16, 2006, at 05:09, Robert Dewar wrote:
> >
On 3/16/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-16 at 10:43 +0100, Richard Guenther wrote:
> > On 3/16/06, Geert Bosch <[EMAIL PROTECTED]> wrote:
> > >
> > > On Mar 16, 2006, at 05:09, Robert Dewar wrote:
> > > > Not quite right. If you have an uninitialized variable, the va
On Mar 16, 2006, at 10:43, Richard Guenther wrote:
Uh - what do you expect here?? Does the Ada standard
require a out-of-range exception upon the first use of N?
In this case, the frontend needs to insert a proper check.
You cannot expect the middle-end to avoid the above
transformation, so thi
On Wed, 2006-03-15 at 23:09 -0500, Robert Dewar wrote:
> Laurent GUERBY wrote:
> > On Mon, 2006-03-13 at 15:31 -0700, Jeffrey A Law wrote:
> >> On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> >>
> >>> What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> >>> allowed by given
On Thu, 2006-03-16 at 10:43 +0100, Richard Guenther wrote:
> On 3/16/06, Geert Bosch <[EMAIL PROTECTED]> wrote:
> >
> > On Mar 16, 2006, at 05:09, Robert Dewar wrote:
> > > Not quite right. If you have an uninitialized variable, the value is
> > > invalid and may be out of bounds, but this is a bou
On 3/16/06, Geert Bosch <[EMAIL PROTECTED]> wrote:
>
> On Mar 16, 2006, at 05:09, Robert Dewar wrote:
> > Not quite right. If you have an uninitialized variable, the value is
> > invalid and may be out of bounds, but this is a bounded error
> > situation,
> > not an erroneous program. So the possib
On Mar 16, 2006, at 05:09, Robert Dewar wrote:
Not quite right. If you have an uninitialized variable, the value is
invalid and may be out of bounds, but this is a bounded error
situation,
not an erroneous program. So the possible effects are definitely NOT
unbounded, and the use of such valu
Laurent GUERBY wrote:
On Mon, 2006-03-13 at 15:31 -0700, Jeffrey A Law wrote:
On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
allowed by given type.
As long as you're *absolutely* clear that a variable with a
restricte
On Mon, 2006-03-13 at 15:31 -0700, Jeffrey A Law wrote:
> On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
>
> > What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> > allowed by given type.
> As long as you're *absolutely* clear that a variable with a
> restricted range can
Hi,
On Mon, 13 Mar 2006, Jeffrey A Law wrote:
> > What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> > allowed by given type.
> As long as you're *absolutely* clear that a variable with a
> restricted range can never hold a value outside that the
> restricted range in a conformin
On Tuesday 14 March 2006 03:16, Waldek Hebisch wrote:
> Jeffrey A Law wrote:
> > On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> >
> > > What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> > > allowed by given type.
> > As long as you're *absolutely* clear that a variabl
Jeffrey A Law wrote:
> On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
>
> > What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> > allowed by given type.
> As long as you're *absolutely* clear that a variable with a
> restricted range can never hold a value outside that th
On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> allowed by given type.
As long as you're *absolutely* clear that a variable with a
restricted range can never hold a value outside that the
restricted range in a conformin
On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> Jeffrey A Law wrote:
> > My suspicions appear to be correct. This never triggers except for
> > Ada code and it's relatively common in Ada code. No surprise since
> > I don't think any other front-end abuses TYPE_MAX_VALUE in the way
> >
Hello,
> > > Jeffrey A Law wrote:
> > > > Another possibility is to simply not allow conversions between a
> > > > subtype and basetype.
> > >
> > > Such a patch also solves the problem. But I'm not sure to understand
> > > the impact on other codes. Is this kind of conversion between a type
>
On Mon, 2006-02-27 at 20:26 +0100, Sebastian Pop wrote:
> Jeffrey A Law wrote:
> > On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
> > > Jeffrey A Law wrote:
> > > > Another possibility is to simply not allow conversions between a
> > > > subtype and basetype.
> > >
> > > Such a patch als
Jeffrey A Law wrote:
> On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
> > Jeffrey A Law wrote:
> > > Another possibility is to simply not allow conversions between a
> > > subtype and basetype.
> >
> > Such a patch also solves the problem. But I'm not sure to understand
> > the impact o
On Sat, 2006-02-25 at 09:48 +0100, Zdenek Dvorak wrote:
> Hello,
>
> > Jeffrey A Law wrote:
> > > Another possibility is to simply not allow conversions between a
> > > subtype and basetype.
> >
> > Such a patch also solves the problem. But I'm not sure to understand
> > the impact on other cod
On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
> Jeffrey A Law wrote:
> > Another possibility is to simply not allow conversions between a
> > subtype and basetype.
>
> Such a patch also solves the problem. But I'm not sure to understand
> the impact on other codes. Is this kind of con
Hello,
> Jeffrey A Law wrote:
> > Another possibility is to simply not allow conversions between a
> > subtype and basetype.
>
> Such a patch also solves the problem. But I'm not sure to understand
> the impact on other codes. Is this kind of conversion between a type
> and its basetype specif
Jeffrey A Law wrote:
> I suspect, but certainly have not confirmed that these conversions
> are very common in Ada, but relatively rare elsewhere. Confirming
> that suspicion one way or the other is on my TODO list for the weekend.
>
okay, thanks for your investigation. I won't be able to read
On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
> Jeffrey A Law wrote:
> > Another possibility is to simply not allow conversions between a
> > subtype and basetype.
>
> Such a patch also solves the problem. But I'm not sure to understand
> the impact on other codes. Is this kind of con
So if I understand correctly, if we can prove that the operation does
not overflow in natural___XDLU_0___2147483647, then there is no need
of a cast to the base type and back.
This stuff is complex, but I'm fairly sure that's correct.
Jeffrey A Law wrote:
> Another possibility is to simply not allow conversions between a
> subtype and basetype.
Such a patch also solves the problem. But I'm not sure to understand
the impact on other codes. Is this kind of conversion between a type
and its basetype specific to Ada?
Index: tre
Jeffrey A Law wrote:
> One possibility that isn't as drastic would be to add one to the
> TYPE_MAX_VALUE of the inner type, then see if the result fits in
> the outer type.
Yes, that's basically the idea that is implemented in chrec_convert.
Because we're in a loop and we keep adding "one"s to
On Fri, 2006-02-24 at 18:42 +0100, Sebastian Pop wrote:
> Richard Kenner wrote:
> > Just to make sure I've dotted the i's and crossed the t's, this is not
> > what's happening when we hang in VRP when compiling a-textio.
> >
> > We convert the incoming object from natural___XDLU_0___21
On Fri, 2006-02-24 at 18:42 +0100, Sebastian Pop wrote:
> Richard Kenner wrote:
> > Just to make sure I've dotted the i's and crossed the t's, this is not
> > what's happening when we hang in VRP when compiling a-textio.
> >
> > We convert the incoming object from natural___XDLU_0___21
On Fri, 2006-02-24 at 18:42 +0100, Sebastian Pop wrote:
> Richard Kenner wrote:
> > Just to make sure I've dotted the i's and crossed the t's, this is not
> > what's happening when we hang in VRP when compiling a-textio.
> >
> > We convert the incoming object from natural___XDLU_0___21
Richard Kenner wrote:
> Just to make sure I've dotted the i's and crossed the t's, this is not
> what's happening when we hang in VRP when compiling a-textio.
>
> We convert the incoming object from natural___XDLU_0___2147483647
> into its base type, perform the addition in the bas
Just to make sure I've dotted the i's and crossed the t's, this is not
what's happening when we hang in VRP when compiling a-textio.
We convert the incoming object from natural___XDLU_0___2147483647
into its base type, perform the addition in the base type, then
convert back to
On 2/24/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
> > When I speak about doing arithmetic in a type, I'm referring to the
> > type of the expression & its input operands in a gimplified
> > expression. At that point I do
On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
> When I speak about doing arithmetic in a type, I'm referring to the
> type of the expression & its input operands in a gimplified
> expression. At that point I do not care about base types or anything
> like that. All
Hi Laurent,
On Wednesday 22 February 2006 12:34, Laurent GUERBY wrote:
> On Wed, 2006-02-22 at 10:54 +0100, Richard Guenther wrote:
> > > > > > type T1 is range 0 .. 127;
> > > > > > -- Compiler will choose some type for T'Base, likely to be
> > > > > > -128..127
> > > > > > -- but could be In
On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
> The base type reference is that I'm *also* saying "If you see an arithmetic
> node where TREE_TYPE is *not* a base type, there's a bug someplace that
> has to be fixed". (Well, with the exception of such things as sizetypes
> or subtypes th
When I speak about doing arithmetic in a type, I'm referring to the
type of the expression & its input operands in a gimplified
expression. At that point I do not care about base types or anything
like that. All that should matter is TREE_TYPE (expr), nothing more,
nothin
On Tue, 2006-02-21 at 23:23 +0100, Laurent GUERBY wrote:
> On Tue, 2006-02-21 at 15:02 -0700, Jeffrey A Law wrote:
> > Given an expression, we have to do computations in some other type than
> > the type of the expression? Now that's just silly. If the expression
> > has some type X, then we shoul
On Mon, 2006-02-20 at 23:00 +0100, Richard Guenther wrote:
> On 2/20/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > Indeed. Ada should in this case generate
> >
> >R = (T)( (basetype)100 + (basetype)X - (basetype)X )
> >
> > i.e. carry out all arithmetic explicitly in the base
On Tue, 2006-02-21 at 18:11 -0500, Robert Dewar wrote:
> Richard Kenner wrote:
>
> > Let me try again and take a simpler example. If we have
> >
> > subtype T is Integer range 20..50;
> >
> > Y: T;
> >
> >... Y + 1 ...
> >
> > What the tree looks like is a PLUS_EXPR of type "I
On Tue, 2006-02-21 at 17:22 -0500, Richard Kenner wrote:
> Given an expression, we have to do computations in some other type than
> the type of the expression? Now that's just silly.
>
> Sure, but that's not what I said.
>
> If the expression has some type X, then we should be d
Jeffrey A Law wrote:
TYPE_MIN_VALUE/TYPE_MAX_VALUE should cover the entire range of
values that can be assigned to a particular object.
Do you mean assigned as in "with an assignment statement", or do
you mean "end up in the object by any mechanism"?
Most of the other stuff discussed so far
On Tue, 2006-02-21 at 18:20 -0500, Robert Dewar wrote:
> Laurent GUERBY wrote:
>
> > You keep saying "brain damage", but please if you see a better design
> > (other than "forget about user range types" :), let us all know!
>
> Actually I think everyone agrees on what is appropriate here. it is
>
Richard Guenther wrote:
On 2/21/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
But if the values in there do not reflect the reality of what values
are valid for the type, then I don't see how they can be generally
useful -- that's my point. We have two fields that are inaccurate,
On Wed, 2006-02-22 at 10:54 +0100, Richard Guenther wrote:
> > > > > type T1 is range 0 .. 127;
> > > > > -- Compiler will choose some type for T'Base, likely to be -128..127
> > > > > -- but could be Integer (implementation dependant)
> > > > > subtype T is T1 range 0 .. 100;
> > > > > R : T
On 2/21/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-02-20 at 22:00 +0100, Richard Guenther wrote:
> > On 2/20/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> > > On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
> > > > On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
On 2/21/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> But if the values in there do not reflect the reality of what values
> are valid for the type, then I don't see how they can be generally
> useful -- that's my point. We have two fields that are inaccurate,
> apparently on
Laurent GUERBY wrote:
You keep saying "brain damage", but please if you see a better design
(other than "forget about user range types" :), let us all know!
Actually I think everyone agrees on what is appropriate here. it is
a matter of working out a clear view. I don't think there are any
rea
Richard Kenner wrote:
Let me try again and take a simpler example. If we have
subtype T is Integer range 20..50;
Y: T;
... Y + 1 ...
What the tree looks like is a PLUS_EXPR of type "Integer" (the base type of
T), not T, whose first operand is a NOP_EXPR converting
On Tue, 2006-02-21 at 15:02 -0700, Jeffrey A Law wrote:
> ?!? WTF
>
> Given an expression, we have to do computations in some other type than
> the type of the expression? Now that's just silly. If the expression
> has some type X, then we should be doing our computations in type X.
That would
Given an expression, we have to do computations in some other type than
the type of the expression? Now that's just silly.
Sure, but that's not what I said.
If the expression has some type X, then we should be doing our
computations in type X.
Right.
Let me try again and
1 - 100 of 126 matches
Mail list logo
