Re: Yet another gnat/TFFE difference

Re: Yet another gnat/TFFE difference

[dennison]

In article <yecwvy15tv5.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> dennison@telepath.com writes:
> > Gnat has no problem with this, which makes sense as the slices are
the
> > same size and the base type of the arrays are the same.
>
> I think you mean element type, not base type.

Correct.

>
> > TFFE compilers blow up with a constrataint error here. I'm gessing
that
> > is because objects of type T2 have to be 5 elements long, but my
slice
> > is 2 elements.
>
> A conversion to subtype T2 includes a constraint check against T2's
> bounds, 1..5, so the Constraint_Error is correct.
>
> > I have two questions here: First off, which vendor gets the bug
> > report? :-)
>
> Probably neither one.  I just tried this with GNAT 3.11p, and it did
> raise Constraint_Error.

Hmmm. You're right. However, I have some code which does just that,
except that the type ranges and the slice ranges are computed at
runtime. Gnat lets that by no problem, but two separate TFFE compilers
choke on it. It looks like I *might* have a gnat bug here, but I'm going
to have to find some time to play with my toy example to be sure.


> You're doing an array subtype conversion; what you want is an array
> base type conversion.  The problem is, the base types are anonymous.
> Here's something that should do what you want:
>
>    type UT1 is array(Positive  range <>) of Float;
>    subtype T1 is UT1(1..2250);
>    O1 : T1;
>
>    type UT2 is array(Positive  range <>) of Float;
>    subtype T2 is UT2(1..5);
>    O2 : T2;

Hmmm...or perhaps I could just make one parent type for both of them...
Thanks.

--
T.E.D.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Yet another gnat/TFFE difference

[dennison]

I have found one last difference between Gnat and Tucker's favorite
front end (both Aonix and GreenHills variants). This one has to do with
array slicing and type conversions. Assume I have the following code:


type T1 is array (1..2250) of Float;
O1 : T1;

type T2 is array (1..5) of Float;
O2 : T2:

...

O2(1..2) := T2 (O1 (2..3));


Gnat has no problem with this, which makes sense as the slices are the
same size and the base type of the arrays are the same.

TFFE compilers blow up with a constrataint error here. I'm gessing that
is because objects of type T2 have to be 5 elements long, but my slice
is 2 elements.

I have two questions here: First off, which vendor gets the bug
report? :-)

Secondly, does anyone have any good ideas about how to make the TFFE
compilers happy? It doesn't make sense that I should have to make two
separate assignments to do this. I know making T1 a subtype of T2 would
work. But in the environment this came up in that is not a feasable
solution (T2 is actually sized based on generic-derived parameters that
are only known at runtime).

--
T.E.D.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: Yet another gnat/TFFE difference

[Keith Thompson]

dennison@telepath.com writes:
> I have found one last difference between Gnat and Tucker's favorite
> front end (both Aonix and GreenHills variants). This one has to do with
> array slicing and type conversions. Assume I have the following code:
> 
> 
> type T1 is array (1..2250) of Float;
> O1 : T1;
> 
> type T2 is array (1..5) of Float;
> O2 : T2:
> 
> ...
> 
> O2(1..2) := T2 (O1 (2..3));
> 
> 
> Gnat has no problem with this, which makes sense as the slices are the
> same size and the base type of the arrays are the same.

I think you mean element type, not base type.

> TFFE compilers blow up with a constrataint error here. I'm gessing that
> is because objects of type T2 have to be 5 elements long, but my slice
> is 2 elements.

A conversion to subtype T2 includes a constraint check against T2's
bounds, 1..5, so the Constraint_Error is correct.

> I have two questions here: First off, which vendor gets the bug
> report? :-)

Probably neither one.  I just tried this with GNAT 3.11p, and it did
raise Constraint_Error.

> Secondly, does anyone have any good ideas about how to make the TFFE
> compilers happy? It doesn't make sense that I should have to make two
> separate assignments to do this. I know making T1 a subtype of T2 would
> work. But in the environment this came up in that is not a feasable
> solution (T2 is actually sized based on generic-derived parameters that
> are only known at runtime).

You're doing an array subtype conversion; what you want is an array
base type conversion.  The problem is, the base types are anonymous.
Here's something that should do what you want:

   type UT1 is array(Positive  range <>) of Float;
   subtype T1 is UT1(1..2250);
   O1 : T1;

   type UT2 is array(Positive  range <>) of Float;
   subtype T2 is UT2(1..5);
   O2 : T2;

   ...

   O2(1..2) := UT2 (O1 (2..3));

(I'm probably misusing the terms "subtype" and "base type".)

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
Techno-geek.  Mouse bigger than phone.  Bites heads off virtual chickens.