GNAT 4.0 strange behaviour

GNAT 4.0 strange behaviour

[James]

This is a very small program compiled under linux debian with gnat 4 
based on gcc 4.0
The output of the program is
  1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
which is of course not right...
If line labelled 1 is removed and replaced by line labelled 2, the 
output is correct.
The output is also correct if part 1 is replaced by part 2.
Any advice or place where I could send a bug report?

with Text_Io;
use Text_Io;
with Interfaces;
use Interfaces;


procedure Toto is
    type Intboard is new Unsigned_64;
    for Intboard'Size use 64;
    type Bit is new Integer range 0..1;
    for Bit'Size use 1;
    type Bitboard is array (0..63) of Bit;
    pragma Pack(Bitboard);
    for Bitboard'Size use 64;

    A_B : Bitboard;
    A_I : Intboard;
    for A_I'Address use A_B'Address;        --label1
--   for A_B'Address use A_I'Address;      --label2

begin
    --part 1
    for I in 0 .. 7 loop
       for J in 0 .. 7 loop
          A_B(I*8+J) := 1;
          Put(Bit'Image(A_B(I*8+J)));
       end loop;
    end loop;

    --part 2
--   for I in 0 .. 63 loop
--      A_B(I) := 1;
--      Put(Bit'Image(A_B(I)));
--   end loop;
end Toto;

Re: GNAT 4.0 strange behaviour

[jimmaureenrogers]

James wrote:
> This is a very small program compiled under linux debian with gnat 4
> based on gcc 4.0
> The output of the program is
>   1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> which is of course not right...
> If line labelled 1 is removed and replaced by line labelled 2, the
> output is correct.
> The output is also correct if part 1 is replaced by part 2.
> Any advice or place where I could send a bug report?
>
> with Text_Io;
> use Text_Io;
> with Interfaces;
> use Interfaces;
>
>
> procedure Toto is
>     type Intboard is new Unsigned_64;
>     for Intboard'Size use 64;
>     type Bit is new Integer range 0..1;
>     for Bit'Size use 1;

You seem to think that Bit is an unsigned type.
It is not. It is a derived type from Integer, which is a
signed type.

If you want an unsigned integer with a range of 0..1
you should declare:

type Bit is mod 2;

Ada unsigned integer types are defined using modular types.

I am willing to bet the answer will improve if you use a
modular type.

Strictly speaking, the subtypes used in part 1 below do not
match the subype used in Bitboard array index definition.

The part 1 approach to indexing look suspiciuosly like C coding
logic. The part 2 approach is closer to a classical Ada.

The most correct and maintainable approach to the looping
is:

for I in A_B'Range loop
   A_B(I) := 1;
   Put(Bit'Image(A-B(I)));
end loop;

Clearly your goal is to set each element of A_B to 1 and
then print a string representation of that element. The
approack shown above will correctly satisfy that goal even
if the index range of A_B should change sometime in the
future due to changes in system requirements.

>     type Bitboard is array (0..63) of Bit;
>     pragma Pack(Bitboard);
>     for Bitboard'Size use 64;
>
>     A_B : Bitboard;
>     A_I : Intboard;
>     for A_I'Address use A_B'Address;        --label1
> --   for A_B'Address use A_I'Address;      --label2
>
> begin
>     --part 1
>     for I in 0 .. 7 loop
>        for J in 0 .. 7 loop
>           A_B(I*8+J) := 1;
>           Put(Bit'Image(A_B(I*8+J)));
>        end loop;
>     end loop;
>
>     --part 2
> --   for I in 0 .. 63 loop
> --      A_B(I) := 1;
> --      Put(Bit'Image(A_B(I)));
> --   end loop;
> end Toto;

Jim Rogers

Re: GNAT 4.0 strange behaviour

[Simon Wright]

"jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes:

> James wrote:
>> This is a very small program compiled under linux debian with gnat 4
>> based on gcc 4.0
>> The output of the program is
>>   1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> which is of course not right...
>> If line labelled 1 is removed and replaced by line labelled 2, the
>> output is correct.
>> The output is also correct if part 1 is replaced by part 2.
>> Any advice or place where I could send a bug report?
>>
>> with Text_Io;
>> use Text_Io;
>> with Interfaces;
>> use Interfaces;
>>
>>
>> procedure Toto is
>>     type Intboard is new Unsigned_64;
>>     for Intboard'Size use 64;
>>     type Bit is new Integer range 0..1;
>>     for Bit'Size use 1;
>
> You seem to think that Bit is an unsigned type.
> It is not. It is a derived type from Integer, which is a
> signed type.
>
> If you want an unsigned integer with a range of 0..1
> you should declare:
>
> type Bit is mod 2;
>
> Ada unsigned integer types are defined using modular types.
>
> I am willing to bet the answer will improve if you use a
> modular type.

It certainly _changes_ (well, I'm pretty sure it did, but I've been
playing around for a little while, so maybe I got confused ...). As it
does if you add

  A_I := 0;

before James's 'part 1' (prints all 0's), or if you change
optimisation level (-O2 gave

 0 1 1 1 0 1 1 0 0 1 1 1 0 1 1 0 0 1 1 0 1 1 1 0 0 1 1 1 0 1 1 0 0 1 1 0 1 1 1 0 0 1 1 1 0 1 1 0 0 1 1 0 1 1 1 0 0 1 1 0 1 1 1 0

). This is 4.0.0 on powerpc-apple-darwin7.9.0.

I think if it was a size problem, there would have been a compilation
error with

   type Bitboard is array (0 .. 63) of Bit;
   pragma Pack (Bitboard);
   for Bitboard'Size use 64;

or come to that with

   for Bit'Size use 1;

(remember that Natural'Size is 31).

Looks like a bug. To report bugs, go to http://gcc.gnu.org, there are
links at the bottom on the left.


As a general rule, using overlays like this is not something to be
done casually, Ada.Unchecked_Conversion is usually better. That said,
I've not seen overlays give this sort of problem before.

Re: GNAT 4.0 strange behaviour

[James]

jimmaureenrogers@worldnet.att.net wrote:
> James wrote:
> 
>>This is a very small program compiled under linux debian with gnat 4
>>based on gcc 4.0
>>The output of the program is
>>  1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
>>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>which is of course not right...
>>If line labelled 1 is removed and replaced by line labelled 2, the
>>output is correct.
>>The output is also correct if part 1 is replaced by part 2.
>>Any advice or place where I could send a bug report?
>>
>>with Text_Io;
>>use Text_Io;
>>with Interfaces;
>>use Interfaces;
>>
>>
>>procedure Toto is
>>    type Intboard is new Unsigned_64;
>>    for Intboard'Size use 64;
>>    type Bit is new Integer range 0..1;
>>    for Bit'Size use 1;
> 
> 
> You seem to think that Bit is an unsigned type.
> It is not. It is a derived type from Integer, which is a
> signed type.
> 
> If you want an unsigned integer with a range of 0..1
> you should declare:
> 
> type Bit is mod 2;
> 
> Ada unsigned integer types are defined using modular types.
> 
> I am willing to bet the answer will improve if you use a
> modular type.
> 
> Strictly speaking, the subtypes used in part 1 below do not
> match the subype used in Bitboard array index definition.
> 
> The part 1 approach to indexing look suspiciuosly like C coding
> logic. The part 2 approach is closer to a classical Ada.
> 
> The most correct and maintainable approach to the looping
> is:
> 
> for I in A_B'Range loop
>    A_B(I) := 1;
>    Put(Bit'Image(A-B(I)));
> end loop;
> 
> Clearly your goal is to set each element of A_B to 1 and
> then print a string representation of that element. The
> approack shown above will correctly satisfy that goal even
> if the index range of A_B should change sometime in the
> future due to changes in system requirements.
> 
> 
>>    type Bitboard is array (0..63) of Bit;
>>    pragma Pack(Bitboard);
>>    for Bitboard'Size use 64;
>>
>>    A_B : Bitboard;
>>    A_I : Intboard;
>>    for A_I'Address use A_B'Address;        --label1
>>--   for A_B'Address use A_I'Address;      --label2
>>
>>begin
>>    --part 1
>>    for I in 0 .. 7 loop
>>       for J in 0 .. 7 loop
>>          A_B(I*8+J) := 1;
>>          Put(Bit'Image(A_B(I*8+J)));
>>       end loop;
>>    end loop;
>>
>>    --part 2
>>--   for I in 0 .. 63 loop
>>--      A_B(I) := 1;
>>--      Put(Bit'Image(A_B(I)));
>>--   end loop;
>>end Toto;
> 
> 
> Jim Rogers
> 
Well, in fact in the beginning it was a boolean type. But I followed 
your suggestion using modular types and the result is exactly identical...
I must stress the fact that:
1) I don't use the overlay, I just declare it and never use it.
2) Part 2 is absolutely identical to part 1 from a semantical point of 
view, I just use two loops in part 1 instead of one in part 2, but the 
range is exactly the same (0..63). So the result should be the same if 
the compiler was working properly according to me, whatever the size, 
type or any other thing.

Any ideas?

Re: GNAT 4.0 strange behaviour

[James]

James wrote:
> jimmaureenrogers@worldnet.att.net wrote:
> 
>> James wrote:
>>
>>> This is a very small program compiled under linux debian with gnat 4
>>> based on gcc 4.0
>>> The output of the program is
>>>  1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
>>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>> which is of course not right...
>>> If line labelled 1 is removed and replaced by line labelled 2, the
>>> output is correct.
>>> The output is also correct if part 1 is replaced by part 2.
>>> Any advice or place where I could send a bug report?
>>>
>>> with Text_Io;
>>> use Text_Io;
>>> with Interfaces;
>>> use Interfaces;
>>>
>>>
>>> procedure Toto is
>>>    type Intboard is new Unsigned_64;
>>>    for Intboard'Size use 64;
>>>    type Bit is new Integer range 0..1;
>>>    for Bit'Size use 1;
>>
>>
>>
>> You seem to think that Bit is an unsigned type.
>> It is not. It is a derived type from Integer, which is a
>> signed type.
>>
>> If you want an unsigned integer with a range of 0..1
>> you should declare:
>>
>> type Bit is mod 2;
>>
>> Ada unsigned integer types are defined using modular types.
>>
>> I am willing to bet the answer will improve if you use a
>> modular type.
>>
>> Strictly speaking, the subtypes used in part 1 below do not
>> match the subype used in Bitboard array index definition.
>>
>> The part 1 approach to indexing look suspiciuosly like C coding
>> logic. The part 2 approach is closer to a classical Ada.
>>
>> The most correct and maintainable approach to the looping
>> is:
>>
>> for I in A_B'Range loop
>>    A_B(I) := 1;
>>    Put(Bit'Image(A-B(I)));
>> end loop;
>>
>> Clearly your goal is to set each element of A_B to 1 and
>> then print a string representation of that element. The
>> approack shown above will correctly satisfy that goal even
>> if the index range of A_B should change sometime in the
>> future due to changes in system requirements.
>>
>>
>>>    type Bitboard is array (0..63) of Bit;
>>>    pragma Pack(Bitboard);
>>>    for Bitboard'Size use 64;
>>>
>>>    A_B : Bitboard;
>>>    A_I : Intboard;
>>>    for A_I'Address use A_B'Address;        --label1
>>> --   for A_B'Address use A_I'Address;      --label2
>>>
>>> begin
>>>    --part 1
>>>    for I in 0 .. 7 loop
>>>       for J in 0 .. 7 loop
>>>          A_B(I*8+J) := 1;
>>>          Put(Bit'Image(A_B(I*8+J)));
>>>       end loop;
>>>    end loop;
>>>
>>>    --part 2
>>> --   for I in 0 .. 63 loop
>>> --      A_B(I) := 1;
>>> --      Put(Bit'Image(A_B(I)));
>>> --   end loop;
>>> end Toto;
>>
>>
>>
>> Jim Rogers
>>
> Well, in fact in the beginning it was a boolean type. But I followed 
> your suggestion using modular types and the result is exactly identical...
> I must stress the fact that:
> 1) I don't use the overlay, I just declare it and never use it.
> 2) Part 2 is absolutely identical to part 1 from a semantical point of 
> view, I just use two loops in part 1 instead of one in part 2, but the 
> range is exactly the same (0..63). So the result should be the same if 
> the compiler was working properly according to me, whatever the size, 
> type or any other thing.
> 
> Any ideas?
Well, just a last word: everything is OK with gnat 3.4. So, it's a 
certainly a bug in gnat 4.0

Thanks