Re: Static vs dynamic evaluation anomaly?

Re: Static vs dynamic evaluation anomaly?

[Jeffrey R. Carter]

Matt Jaffe wrote:
>   A student of mine stumbled over a problem that I can reproduce but 
> can't explain.  It manifests itself in the two different values computed 
> by two almost identical expressions when an integer variable is replaced 
> by an integer literal of the same value.  Here's a sample output:
> 
>     The test pattern, X, is a modulo 2**6 integer = 31 or 2#11111#
> 
>     When J=0, X*2**J = 31 or 2#11111#        but X*2**0 = 31 or 2#11111#
>     When J=1, X*2**J = 62 or 2#111110#       but X*2**1 = 62 or 2#111110#
>     When J=2, X*2**J =124 or 2#1111100#      but X*2**2 = 60 or 2#111100#
>     When J=3, X*2**J =248 or 2#11111000#     but X*2**3 = 56 or 2#111000#
>     When J=4, X*2**J =240 or 2#11110000#     but X*2**4 = 48 or 2#110000#
>     When J=5, X*2**J =224 or 2#11100000#     but X*2**5 = 32 or 2#100000#
> 
> Here are the relevant declarations:
> 
>   type Six_Bits is mod 2**6;
>    package Six_Bit_IO is new Ada.Text_IO.Modular_IO(Six_Bits); use 
> Six_Bit_IO;
>    X : Six_Bits := 31;

I would need to see more to comment, but I suggest you eliminate all use 
clauses and see if that makes a difference.

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61

Re: Static vs dynamic evaluation anomaly?

[Adam Beneschan]

On Feb 6, 9:29 am, Matt Jaffe <jaf...@cableone.net> wrote:

> Any further help in explaining these anomalies would be much appreciated.  (It's always possible we've stumbled across a compiler bug; but I am reluctant to come to that conclusion prematurely.)

I'm not so reluctant.  It's a compiler bug.

The following program produces incorrect results on GNAT, or at least
on the version I'm using:

with Ada.Text_IO;
procedure test271 is
    type Six_Bits is mod 2**6;
    package Six_Bit_IO is new Ada.Text_IO.Modular_IO(Six_Bits);
    X : Six_Bits := 31;
begin
    for J in 0..5 loop
        Ada.Text_IO.Put ("When J=" & Integer'image(J));
        Ada.Text_IO.Put (", X*2**J =");
        Six_Bit_IO.Put(X*2**J);
        Ada.Text_IO.New_Line;
    end loop;
end test271;

                      -- Adam

Re: Static vs dynamic evaluation anomaly?

[Ludovic Brenta]

Adam Beneschan writes:
> On Feb 6, 9:29 am, Matt Jaffe <jaf...@cableone.net> wrote:
>
>> Any further help in explaining these anomalies would be much
>> appreciated.  (It's always possible we've stumbled across a
>> compiler bug; but I am reluctant to come to that conclusion
>> prematurely.)
>
> I'm not so reluctant.  It's a compiler bug.

Confirmed on Debian gnat 4.1.1-22.

-- 
Ludovic Brenta.

Re: Static vs dynamic evaluation anomaly?

[Matt.Jaffe]

On Feb 6, 1:15 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Adam Beneschan writes:
> > On Feb 6, 9:29 am, Matt Jaffe <jaf...@cableone.net> wrote:
>
> >> Any further help in explaining these anomalies would be much
> >> appreciated.  (It's always possible we've stumbled across a
> >> compiler bug; but I am reluctant to come to that conclusion
> >> prematurely.)
>
> > I'm not so reluctant.  It's a compiler bug.
>
> Confirmed on Debian gnat 4.1.1-22.
>
> --
> Ludovic Brenta.

Ah, well, thank you all very much; good to know I wasn't missing
something obvious.

Re: Static vs dynamic evaluation anomaly?

[Ludovic Brenta]

Matt Jaffe writes:
> Ludovic Brenta wrote:
>> Confirmed on Debian gnat 4.1.1-22.

I take that back.  The bug is not present on Debian gnat 4.1.1-22.

> Is there a bug tracking system I should sent something in to?  The
> host machine is a Sun running Solaris.  I issued the shell command
> "gnatmake" (no arguments) but none of the resultant list of
> arguments and options seemed to indicate how to obtain precise
> version description information. Before I dig deeper, I need to know
> if its likely that someone is collecting bug reports for a gnat
> running on Solaris. If so, I will "do the right thing" and gather
> the necessary data and submit it.

It depends where you obtained this GNAT from.  If it is GNAT Pro, then
report it to AdaCore.  If it is from the FSF, report it to
http://gcc.gnu.org/bugzilla.  If it is from Blaswave, report it to
Blastwave.

You can obtain more information if you do:

$ locate gnat1
$ ..../gnat1 --version

You can also try gcc --version but then you'd have to make sure that
the gcc you're invoking is the one you use for Ada.

-- 
Ludovic Brenta.

Re: Static vs dynamic evaluation anomaly?

[Simon Wright]

Matt Jaffe <jaffem@cableone.net> writes:

> Is there a bug tracking system I should sent something in to?  The host
> machine is a Sun running Solaris.  I issued the shell command
> "gnatmake" (no arguments) but none of the resultant list of arguments
> and options seemed to indicate how to obtain precise version
> description information.

The standard way to get GNAT's version is 
  gnatls -v

GNAT's version

[Peter Hermann]

Simon Wright <simon.j.wright@mac.com> wrote:
> The standard way to get GNAT's version is 
>   gnatls -v

funny: a precious hint! I never knew from GNAT documentation...
Is more informative than all those options in gcc,gnatmake,etc.
Thank you

-- 
--Peter.Hermann@ihr.uni-stuttgart.de        (+49)0711-685-872-44(Fax79)
--Nobelstr.19 Raum 0.030, D-70569 Stuttgart IHR Hoechstleistungsrechnen
--http://www.ihr.uni-stuttgart.de/

Re: Static vs dynamic evaluation anomaly?

[Steve]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:1170792077.235994.10900@q2g2000cwa.googlegroups.com...
> On Feb 6, 9:29 am, Matt Jaffe <jaf...@cableone.net> wrote:
>
>> Any further help in explaining these anomalies would be much appreciated. 
>> (It's always possible we've stumbled across a compiler bug; but I am 
>> reluctant to come to that conclusion prematurely.)
>
> I'm not so reluctant.  It's a compiler bug.
>
> The following program produces incorrect results on GNAT, or at least
> on the version I'm using:
>
> with Ada.Text_IO;
> procedure test271 is
>    type Six_Bits is mod 2**6;
>    package Six_Bit_IO is new Ada.Text_IO.Modular_IO(Six_Bits);
>    X : Six_Bits := 31;
> begin
>    for J in 0..5 loop
>        Ada.Text_IO.Put ("When J=" & Integer'image(J));
>        Ada.Text_IO.Put (", X*2**J =");
>        Six_Bit_IO.Put(X*2**J);
>        Ada.Text_IO.New_Line;
>    end loop;
> end test271;
>

One more data point... ObjectAda 7.2.2 gives the result:

When J= 0, X*2**J = 31
When J= 1, X*2**J = 62
When J= 2, X*2**J = 60
When J= 3, X*2**J = 56
When J= 4, X*2**J = 48
When J= 5, X*2**J = 32

Which I believe is correct,
Regards,

Steve
(The Duck)

>                      -- Adam
> 

Re: Static vs dynamic evaluation anomaly?

[Ludovic Brenta]

Steve writes:
> Adam Beneschanwrote
>> On Feb 6, 9:29 am, Matt Jaffe wrote:
>>
>>> Any further help in explaining these anomalies would be much appreciated. 
>>> (It's always possible we've stumbled across a compiler bug; but I am 
>>> reluctant to come to that conclusion prematurely.)
>>
>> I'm not so reluctant.  It's a compiler bug.
>>
>> The following program produces incorrect results on GNAT, or at least
>> on the version I'm using:
>>
>> with Ada.Text_IO;
>> procedure test271 is
>>    type Six_Bits is mod 2**6;
>>    package Six_Bit_IO is new Ada.Text_IO.Modular_IO(Six_Bits);
>>    X : Six_Bits := 31;
>> begin
>>    for J in 0..5 loop
>>        Ada.Text_IO.Put ("When J=" & Integer'image(J));
>>        Ada.Text_IO.Put (", X*2**J =");
>>        Six_Bit_IO.Put(X*2**J);
>>        Ada.Text_IO.New_Line;
>>    end loop;
>> end test271;
>>
>
> One more data point... ObjectAda 7.2.2 gives the result:
>
> When J= 0, X*2**J = 31
> When J= 1, X*2**J = 62
> When J= 2, X*2**J = 60
> When J= 3, X*2**J = 56
> When J= 4, X*2**J = 48
> When J= 5, X*2**J = 32
>
> Which I believe is correct,
> Regards,


Actually I'll take back what I said earlier.  With Debian gnat
4.1.1-22 I also get these seemingly correct results.

-- 
Ludovic Brenta.

Re: Static vs dynamic evaluation anomaly?

[Georg Bauhaus]

On Wed, 2007-02-07 at 11:00 +0100, Ludovic Brenta wrote:
> Steve writes:
> > Adam Beneschanwrote
> >> On Feb 6, 9:29 am, Matt Jaffe wrote:
> >>
> >> The following program produces incorrect results on GNAT, or at least
> >> on the version I'm using:
> >>
> >> with Ada.Text_IO;
> >...
> >> end test271;
> >>
> >
> > One more data point... ObjectAda 7.2.2 gives the result:
> >
> > When J= 0, X*2**J = 31
> > When J= 1, X*2**J = 62
> > When J= 2, X*2**J = 60
> > When J= 3, X*2**J = 56
> > When J= 4, X*2**J = 48
> > When J= 5, X*2**J = 32
> >
> > Which I believe is correct,
> > Regards,
> 
> 
> Actually I'll take back what I said earlier.  With Debian gnat
> 4.1.1-22 I also get these seemingly correct results.

It seems to depend on a compiler switch, could you try

$ gnatmake -gnatp -s test271
$ gnatmake -gnato -s test271


-- Georg 

Re: Static vs dynamic evaluation anomaly?

[Adam Beneschan]

On Feb 7, 2:21 am, Georg Bauhaus <bauh...@futureapps.de> wrote:
> On Wed, 2007-02-07 at 11:00 +0100, Ludovic Brenta wrote:
> > Steve writes:
> > > Adam Beneschanwrote
> > >> On Feb 6, 9:29 am, Matt Jaffe wrote:
>
> > >> The following program produces incorrect results on GNAT, or at least
> > >> on the version I'm using:
>
> > >> with Ada.Text_IO;
> > >...
> > >> end test271;
>
> > > One more data point... ObjectAda 7.2.2 gives the result:
>
> > > When J= 0, X*2**J = 31
> > > When J= 1, X*2**J = 62
> > > When J= 2, X*2**J = 60
> > > When J= 3, X*2**J = 56
> > > When J= 4, X*2**J = 48
> > > When J= 5, X*2**J = 32
>
> > > Which I believe is correct,
> > > Regards,
>
> > Actually I'll take back what I said earlier.  With Debian gnat
> > 4.1.1-22 I also get these seemingly correct results.
>
> It seems to depend on a compiler switch, could you try
>
> $ gnatmake -gnatp -s test271
> $ gnatmake -gnato -s test271

Yes, it does make a difference.  It appears that I'm using version
4.0.0.  When I use -gnato, I get the correct results; when I use -
gnatp, or no flag, I get incorrect results (Text_IO displays values
greater than 63, same as what Matt was seeing).

                         -- Adam

Re: Static vs dynamic evaluation anomaly?

[Jeffrey R. Carter]

Adam Beneschan wrote:
> 
> Yes, it does make a difference.  It appears that I'm using version
> 4.0.0.  When I use -gnato, I get the correct results; when I use -
> gnatp, or no flag, I get incorrect results (Text_IO displays values
> greater than 63, same as what Matt was seeing).

This is a known issue. GNAT is not Ada without -gnato and -fstack-check.

-- 
Jeff Carter
"No one is to stone anyone until I blow this whistle,
do you understand? Even--and I want to make this
absolutely clear--even if they do say, 'Jehovah.'"
Monty Python's Life of Brian
74

Re: Static vs dynamic evaluation anomaly?

[Adam Beneschan]

On Feb 7, 10:27 am, "Jeffrey R. Carter" <jrcar...@acm.org> wrote:
> Adam Beneschan wrote:
>
> > Yes, it does make a difference.  It appears that I'm using version
> > 4.0.0.  When I use -gnato, I get the correct results; when I use -
> > gnatp, or no flag, I get incorrect results (Text_IO displays values
> > greater than 63, same as what Matt was seeing).
>
> This is a known issue. GNAT is not Ada without -gnato and -fstack-check.

Seems like a pretty lame excuse, though.  Ada does have a Suppress
pragma to suppress checks; as I understand the documentation, omitting
-gnato causes certain checks not to be performed, and using -gnatp
causes even more checks not to be performed, so the result should be
more or less equivalent to using Suppress.  So it probably isn't
accurate to say that GNAT isn't Ada in that case, but that's perhaps a
matter of semantics.  In any case, though, using Suppress, or not
using -gnato, or using -gnatp, shouldn't produce *different* results.
The most I would expect is that the behavior would be different in
cases where an exception would be raised if the check were performed---
but I would not expect different behavior in a case where *no*
exception is raised.  And in this case, no exception is raised---the
Put is outputting different values.  So I still think this is a bug
that needs to be fixed.  The current behavior (assuming that 4.1.1-22
behaves the same as 4.0.0) isn't reasonable.

                        -- Adam

Re: Static vs dynamic evaluation anomaly?

[Simon Wright]

"Adam Beneschan" <adam@irvine.com> writes:

> On Feb 7, 10:27 am, "Jeffrey R. Carter" <jrcar...@acm.org> wrote:
>> Adam Beneschan wrote:
>>
>> > Yes, it does make a difference.  It appears that I'm using version
>> > 4.0.0.  When I use -gnato, I get the correct results; when I use -
>> > gnatp, or no flag, I get incorrect results (Text_IO displays values
>> > greater than 63, same as what Matt was seeing).
>>
>> This is a known issue. GNAT is not Ada without -gnato and -fstack-check.
>
> Seems like a pretty lame excuse, though.  Ada does have a Suppress
> pragma to suppress checks; as I understand the documentation, omitting
> -gnato causes certain checks not to be performed, and using -gnatp
> causes even more checks not to be performed, so the result should be
> more or less equivalent to using Suppress.  So it probably isn't
> accurate to say that GNAT isn't Ada in that case, but that's perhaps a
> matter of semantics.  In any case, though, using Suppress, or not
> using -gnato, or using -gnatp, shouldn't produce *different* results.
> The most I would expect is that the behavior would be different in
> cases where an exception would be raised if the check were performed---
> but I would not expect different behavior in a case where *no*
> exception is raised.  And in this case, no exception is raised---the
> Put is outputting different values.  So I still think this is a bug
> that needs to be fixed.  The current behavior (assuming that 4.1.1-22
> behaves the same as 4.0.0) isn't reasonable.

-gnato makes GNAT check for integer overflow, so it is at least in the
 right area!

I must say that I would have expected to get unsigned behaviour
independent of -gnato, though (and don't forget the RTL isn't getting
recompiled).

Similar results with GNAT-GPL-2006 on G4 Mac, BTW.

Re: Static vs dynamic evaluation anomaly?

[Jeffrey R. Carter]

Adam Beneschan wrote:
> 
> Seems like a pretty lame excuse, though.  Ada does have a Suppress
> pragma to suppress checks; as I understand the documentation, omitting
> -gnato causes certain checks not to be performed, and using -gnatp
> causes even more checks not to be performed, so the result should be
> more or less equivalent to using Suppress.  So it probably isn't
> accurate to say that GNAT isn't Ada in that case, but that's perhaps a
> matter of semantics.  In any case, though, using Suppress, or not
> using -gnato, or using -gnatp, shouldn't produce *different* results.
> The most I would expect is that the behavior would be different in
> cases where an exception would be raised if the check were performed---
> but I would not expect different behavior in a case where *no*
> exception is raised.  And in this case, no exception is raised---the
> Put is outputting different values.  So I still think this is a bug
> that needs to be fixed.  The current behavior (assuming that 4.1.1-22
> behaves the same as 4.0.0) isn't reasonable.

What's happening (I think) is the base type is 8 bits. Without -gnato, 
there's no check to see if the result exceeds this and should be reduced 
mod the modulus, so an out-of-range value is produced. The output is 
always outputting an 8-bit value; with the check, this value always fits 
in 6 bits; without it, it may be larger.

This may well be an error, possibly with Modular_IO.

-- 
Jeff Carter
"It's all right, Taggart. Just a man and a horse being hung out there."
Blazing Saddles
34

Re: Static vs dynamic evaluation anomaly?

[Adam Beneschan]

On Feb 7, 4:48 pm, "Jeffrey R. Carter" <jrcar...@acm.org> wrote:

> What's happening (I think) is the base type is 8 bits. Without -gnato,
> there's no check to see if the result exceeds this and should be reduced
> mod the modulus, so an out-of-range value is produced.

Hmmm.  This is certainly not the way I would expect a "perform this
check" or "don't perform this check" flag to work.  To me, if the
semantics of the language say that a value should be reduced by a
modulus, then it should always be reduced regardless of what flags are
present.  The only effect I'd expect a flag like this to have is in a
case where performing a check would raise an exception; then not
performing the check would have different behavior (possibly returning
an out-of-range value or reading out-of-range memory or dying on an
invalid memory access or something).  But I wouldn't expect any change
in behavior in a case where no exception is raised even with checking
turned on.

                              -- Adam

Re: Static vs dynamic evaluation anomaly?

[Jeffrey R. Carter]

Adam Beneschan wrote:
> 
> Hmmm.  This is certainly not the way I would expect a "perform this
> check" or "don't perform this check" flag to work.  To me, if the
> semantics of the language say that a value should be reduced by a
> modulus, then it should always be reduced regardless of what flags are
> present.  The only effect I'd expect a flag like this to have is in a
> case where performing a check would raise an exception; then not
> performing the check would have different behavior (possibly returning
> an out-of-range value or reading out-of-range memory or dying on an
> invalid memory access or something).  But I wouldn't expect any change
> in behavior in a case where no exception is raised even with checking
> turned on.

I understand your logic; I'm not even saying I disagree. But perhaps the 
compiler writer's view is that it's OK to store the larger value as long 
as the extra bits are never used. Then the error is in the I/O, which is 
using the extra bits.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: Static vs dynamic evaluation anomaly?

[Stefan Lucks]

On Thu, 8 Feb 2007, Jeffrey R. Carter wrote:

> Adam Beneschan wrote:
> > Hmmm.  This is certainly not the way I would expect a "perform this
> > check" or "don't perform this check" flag to work.  To me, if the
[...]
> I understand your logic; I'm not even saying I disagree. But perhaps the
> compiler writer's view is that it's OK to store the larger value as long
> as the extra bits are never used. Then the error is in the I/O, which is
> using the extra bits.

This is a valid point -- except that the extra bits are not just used by
the IO, but also, e.g., for comparisons:

with Ada.Text_IO;
use  Ada.Text_IO;
procedure test272 is
  type Six_Bits is mod 2**6;
  X: constant Six_Bits := 31;
  Z: constant Integer  := 31;
  T: integer;
begin
  for J in 0..9 loop
    T := (Integer(X) * 2**Integer(J)) mod Six_Bits'Modulus;
    Put (Integer 'Image         (J) &
         Six_Bits'Image  (X * 2**J) &
         Integer 'Image  (T)          );
    if (X * 2**J) = Six_Bits(T) then
      Put_Line(" equal");
    else
      Put_Line(" different!!!");
    end if;
  end loop;
end test272;

With "gnatmake" (no option) or "gnatmake -gnatp" I get wrong results:

./test272
 0 31 31 equal
 1 62 62 equal
 2 124 60 different!!!
 3 248 56 different!!!
 4 240 48 different!!!
 5 224 32 different!!!
 6 192 0 different!!!
 7 128 0 different!!!
 8 0 0 equal
 9 0 0 equal


-- 
Stefan Lucks      Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
            e-mail: lucks@th.informatik.uni-mannheim.de
            home: http://th.informatik.uni-mannheim.de/people/lucks/
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Static vs dynamic evaluation anomaly?

[Jeffrey R. Carter]

Stefan Lucks wrote:
> 
> This is a valid point -- except that the extra bits are not just used by
> the IO, but also, e.g., for comparisons:

OK. I would say that this is a compiler error. But I can still see how 
the compiler writer could argue that it is not.

-- 
Jeff Carter
"Sheriff murdered, crops burned, stores looted,
people stampeded, and cattle raped."
Blazing Saddles
35

Re: Static vs dynamic evaluation anomaly?

[Stefan Lucks]

On Fri, 9 Feb 2007, Jeffrey R. Carter wrote:

> OK. I would say that this is a compiler error. But I can still see how
> the compiler writer could argue that it is not.

OK, does the following test case convince you, that the compiler writer
cannot reasonably deny that the compiler is false (if -gnatp or no
compiler options are chosen)?

The only kind of defense on the side of the compiler writer I can still
imagine is that gnat without the -gnato option isn't an Ada compiler, but
rather a compiler for a language with an Ada syntax but a non-Ada
semantic.

---

with Ada.Text_IO;
use  Ada.Text_IO;

procedure test273 is
  type Six_Bits is mod 2**6;
  X: constant Six_Bits := 31;
  Z: constant Integer  := 31;
  Outside : Boolean;
begin
  for J in 0..9 loop
    Outside := True;
    Put (Integer 'Image         (J) &
         Six_Bits'Image  (X * 2**J) );
    for I in Six_Bits loop
      if (X * 2**J) = I then
        Put(" equal to" & Six_Bits'Image(I));
        Outside := False;
      end if;
    end loop;
    if Outside then
      Put(" (value NOT IN");
    else
      Put(" (value in");
    end if;
    Put_Line(Six_Bits'Image(Six_Bits'First) & " .." &
             Six_Bits'Image(Six_Bits'Last) & ")!"    );
  end loop;
end test273;

---

gnatmake test273

---

./test273
 0 31 equal to 31 (value in 0 .. 63)!
 1 62 equal to 62 (value in 0 .. 63)!
 2 124 (value NOT IN 0 .. 63)!
 3 248 (value NOT IN 0 .. 63)!
 4 240 (value NOT IN 0 .. 63)!
 5 224 (value NOT IN 0 .. 63)!
 6 192 (value NOT IN 0 .. 63)!
 7 128 (value NOT IN 0 .. 63)!
 8 0 equal to 0 (value in 0 .. 63)!
 9 0 equal to 0 (value in 0 .. 63)!

-- 
Stefan Lucks      Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
            e-mail: lucks@th.informatik.uni-mannheim.de
            home: http://th.informatik.uni-mannheim.de/people/lucks/
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Static vs dynamic evaluation anomaly?

[Jeffrey R. Carter]

Stefan Lucks wrote:
> 
> The only kind of defense on the side of the compiler writer I can still
> imagine is that gnat without the -gnato option isn't an Ada compiler, but
> rather a compiler for a language with an Ada syntax but a non-Ada
> semantic.

Well, yes, the crux of the matter is that without -gnato, the compiler 
is not inserting certain checks. The argument I could see being used 
would be something like: When the result of the multiplication is not in 
the range of the type, the value "overflows" into the unused bits of the 
base type. With -gnato, that overflow is detected and corrected as 
required by the language. Without it, the overflow goes undetected and 
you get the results you have posted.

As I said, I think this is an error, since the ARM says that values are 
taken mod the modulus for the type, not that they're taken mod the 
modulus when they "overflow" the range of the type.

I think someone has posted here that they're reporting this as an error; 
it will be interesting to see the response.

-- 
Jeff Carter
"Sheriff murdered, crops burned, stores looted,
people stampeded, and cattle raped."
Blazing Saddles
35

Re: Static vs dynamic evaluation anomaly?

[Ludovic Brenta]

Jeffrey R. Carter writes:
> I think someone has posted here that they're reporting this as an
> error; it will be interesting to see the response.

Yes, see http://gcc.gnu.org/PR30740

-- 
Ludovic Brenta.

Re: Static vs dynamic evaluation anomaly?

[Matt Jaffe]

Jeffrey R. Carter wrote:
> Adam Beneschan wrote:
>>
>> Yes, it does make a difference.  It appears that I'm using version
>> 4.0.0.  When I use -gnato, I get the correct results; when I use -
>> gnatp, or no flag, I get incorrect results (Text_IO displays values
>> greater than 63, same as what Matt was seeing).
>
> This is a known issue. GNAT is not Ada without -gnato and -fstack-check.
Since you say this is an already known issue, I think that means I can 
be excused from trying to figure out how to submit a bug report on it 
(which I was dutifully going to try to do, based on the suggestions that 
several others here have made).  I remain curious, however:  Is it a 
known issue for which a correction to gnat is planned? Or is it planned 
to leave it forever as a "known oddity"?  Or is the question as to 
whether or not to correct it still under debate somewhere?  I have no 
particular axe to grind here, just pure curiosity.

Re: Static vs dynamic evaluation anomaly?

[Ludovic Brenta]

Matt Jaffe <jaffem@cableone.net> writes:
> Jeffrey R. Carter wrote:
>> Adam Beneschan wrote:
>>>
>>> Yes, it does make a difference.  It appears that I'm using version
>>> 4.0.0.  When I use -gnato, I get the correct results; when I use -
>>> gnatp, or no flag, I get incorrect results (Text_IO displays values
>>> greater than 63, same as what Matt was seeing).
>>
>> This is a known issue. GNAT is not Ada without -gnato and -fstack-check.
> Since you say this is an already known issue, I think that means I can
> be excused from trying to figure out how to submit a bug report on it
> (which I was dutifully going to try to do, based on the suggestions
> that several others here have made).  I remain curious, however:  Is
> it a known issue for which a correction to gnat is planned? Or is it
> planned to leave it forever as a "known oddity"?  Or is the question
> as to whether or not to correct it still under debate somewhere?  I
> have no particular axe to grind here, just pure curiosity.

I agree with Simon and Adam: this is a compiler bug.  My rationale is
that -gnato is defined as enabling "overflow checks", but modular
types never overflow.  So, -gnato should have no effect on modular
types.

Since this bug has now been confirmed on several platforms, we now
know it is not specific to any one distribution, so the proper place
to submit it is http://gcc.gnu.org/bugzilla.  Please go ahead.

-- 
Ludovic Brenta.

Re: Static vs dynamic evaluation anomaly?

[Georg Bauhaus]

On Thu, 2007-02-08 at 10:01 +0100, Ludovic Brenta wrote:
> Matt Jaffe <jaffem@cableone.net> writes:
> >  I remain curious, however:  Is
> > it a known issue for which a correction to gnat is planned? Or is it
> > planned to leave it forever as a "known oddity"? ...
>
> I agree with Simon and Adam: this is a compiler bug.  My rationale is
> that -gnato is defined as enabling "overflow checks", but modular
> types never overflow.  So, -gnato should have no effect on modular
> types.

Wasn't there a persistent nagging at Ada designers that
they chose to include modular types having a modulus other
that Storage_Element'Size?    :-)

Re: Static vs dynamic evaluation anomaly?

[Jean-Pierre Rosen]

Ludovic Brenta a �crit :
> I agree with Simon and Adam: this is a compiler bug.  My rationale is
> that -gnato is defined as enabling "overflow checks", but modular
> types never overflow.  
Just to nit-pick a little bit: C_E is raised in case of divide by 0 (but 
that's the only case).
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Static vs dynamic evaluation anomaly?

[Ludovic Brenta]

Jean-Pierre Rosen writes:
> Ludovic Brenta a écrit :
>> I agree with Simon and Adam: this is a compiler bug.  My rationale is
>> that -gnato is defined as enabling "overflow checks", but modular
>> types never overflow.
> Just to nit-pick a little bit: C_E is raised in case of divide by 0
> (but that's the only case).

Is that an overflow? I don't think so, and even without -gnato there
is bound to be a run-time check.

-- 
Ludovic Brenta.

Re: Static vs dynamic evaluation anomaly?

[Matt.Jaffe]

On Feb 7, 3:21 am, Georg Bauhaus <bauh...@futureapps.de> wrote:
> On Wed, 2007-02-07 at 11:00 +0100, Ludovic Brenta wrote:
> > Steve writes:
> > > Adam Beneschanwrote
> > >> On Feb 6, 9:29 am, MattJaffewrote:
>
> > >> The following program produces incorrect results on GNAT, or at least
> > >> on the version I'm using:
>
> > >> with Ada.Text_IO;
> > >...
> > >> end test271;
>
> > > One more data point... ObjectAda 7.2.2 gives the result:
>
> > > When J= 0, X*2**J = 31
> > > When J= 1, X*2**J = 62
> > > When J= 2, X*2**J = 60
> > > When J= 3, X*2**J = 56
> > > When J= 4, X*2**J = 48
> > > When J= 5, X*2**J = 32
>
> > > Which I believe is correct,
> > > Regards,
>
> > Actually I'll take back what I said earlier.  With Debian gnat
> > 4.1.1-22 I also get these seemingly correct results.
>
> It seems to depend on a compiler switch, could you try
>
> $ gnatmake -gnatp -s test271
> $ gnatmake -gnato -s test271
>
> -- Georg

You are correct; the anomaly does not appear when the -gnato option is
used for the compilation.  And since I have now looked up the
significance of the -gnato option, I now know why; sort of.  I am
disturbed, however, in that the default (no overflow checking) allows
the production and execution of code yielding what seem to me to be
semantically invalid results.  To allow the deliberately disabling,
for performance reasons, of a feature that insures semantic compliance
may be something that a compiler should allow to broaden its appeal;
but to have default behavior that is not compliant with the language's
semantics seems very odd to me.  Or am I mis-interpreting the
situation here?

AW: Static vs dynamic evaluation anomaly?

[Grein, Christoph (Fa. ESG)]

No, this program is absolute correct. Modular types do not overflow,
they use modular arithmetic.

with Ada.Text_IO;
use  Ada.Text_IO;
procedure test271 is
  type Six_Bits is mod 2**6;
  X: constant Six_Bits := 31;
  Z: constant Integer  := 31;
begin
  for J in 0..5 loop
    Put_Line (Integer 'Image         (J) &
              Six_Bits'Image  (X * 2**J) &
              Integer 'Image ((X * 2**J) mod Six_Bit'Modulus));
  end loop;
end test271;

Re: AW: Static vs dynamic evaluation anomaly?

[Stefan Lucks]

There seems to be something wrong with the Put_Line statement:

On Wed, 7 Feb 2007, Grein, Christoph (Fa. ESG) wrote:

> with Ada.Text_IO;
> use  Ada.Text_IO;
> procedure test271 is
>   type Six_Bits is mod 2**6;
>   X: constant Six_Bits := 31;
>   Z: constant Integer  := 31;
> begin
>   for J in 0..5 loop
>     Put_Line (Integer 'Image         (J) &
>               Six_Bits'Image  (X * 2**J) &
>               Integer 'Image ((X * 2**J) mod Six_Bit'Modulus));
    Put_Line (Integer 'Image         (J) &
              Six_Bits'Image  (X * 2**J) &
              Integer 'Image ((Integer(X) * 2**Integer(J))
                                mod Six_Bits'Modulus)
             );
>   end loop;
> end test271;
>

-- 
Stefan Lucks      Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
            e-mail: lucks@th.informatik.uni-mannheim.de
            home: http://th.informatik.uni-mannheim.de/people/lucks/
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------