Static vs dynamic evaluation anomaly?
Matt Jaffe
The test pattern, X, is a modulo 2**6 integer = 31 or 2#11111#Here are the relevant declarations:
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#
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;
The exponent J is the integer index of the for loop that does the printing. The printout on the right is what I expect to see, multiplication by a power of 2 being a left shift within the number of bits used to represent the type Six_Bits. It's the printout on the left that has me stumped. It's easy to see what is happening; the question is why. X*2**3, for example, evaluates exactly as one expects: It shifts X to the left 3 bits, "losing" the left most 3 bits and inserting 0's on the right. X*2**J also shifts X to the left 3 bits, inserting 0's on the right, but the leftmost bits are not dropped until the result of the expression's evaluation exceeds 8 bits in length. (Looking at a test pattern of X=31, 5 rightmost bits all set to 1's, there are 5 1's in the result of X*2**J all the way up until J=4, at which point the leftmost 1 has dropped off the left end.)
It seems clear and not very surprising that the compiler has chosen to implement the Six_Bits type in the smallest unit of memory big enough for it on our hardware, namely an 8-bit byte. But why the change in the result of the evaluation process when the integer variable J is replaced by an integer literal? When J=3, 2**J should evaluate to the Six_Bits value 8, should it not? And 2**3 should also evaluate to the Six_Bits value 8, otherwise, in both cases, the subsequent multiplication times X would fail of compilation on an operand/type mis-match.The only difference I can see is that one expression (2**3) is being evaluated at compile time as a static expression and the other, with the J exponent, is being evaluated dynamically (during execution). That's as far as my diagnosis has gone at this point.
Another clue/oddity here is that the Six_Bit_IO.Put(X*2**J) is printing 8-bit values that are not Six_Bits values. I very carefully did not include or instantiate any integer IO (in fact to get the J value printed, the line has to be Six_Bit_IO.Put(Six_Bits(J)) so the only Put's that should be available are Text_IO.Put and Six_Bit_IO.Put, neither of which should be producing values >63.
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.)
Jeffrey R. Carter
> 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
Adam Beneschan
> 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
Ludovic Brenta
> 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.
Matt....@gmail.com
Ah, well, thank you all very much; good to know I wasn't missing
something obvious.
Steve
news:1170792077....@q2g2000cwa.googlegroups.com...
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
>
Matt Jaffe
Grein, Christoph (Fa. ESG)
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;
Stefan Lucks
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: lu...@th.informatik.uni-mannheim.de
home: http://th.informatik.uni-mannheim.de/people/lucks/
------ I love the taste of Cryptanalysis in the morning! ------
Grein, Christoph (Fa. ESG)
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 ((Z * 2**J) mod Six_Bits'Modulus));
end loop;
end test271;
_______________________________________________
comp.lang.ada mailing list
comp.l...@ada-france.org
http://www.ada-france.org/mailman/listinfo/comp.lang.ada
Ludovic Brenta
> Adam Beneschanwrote
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.
Ludovic Brenta
> 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.
Georg Bauhaus
> 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
Adam Beneschan
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
Jeffrey R. Carter
>
> 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
Adam Beneschan
> 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
Matt....@gmail.com
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?
Simon Wright
> 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
Simon Wright
-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.
Jeffrey R. Carter
>
> 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
Adam Beneschan
> 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
Matt Jaffe
> 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.
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.
Ludovic Brenta
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.
Georg Bauhaus
> Matt Jaffe <jaf...@cableone.net> writes:
> > I remain curious, however: Is
> > it a known issue for which a correction to gnat is planned? Or is it
>
> 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? :-)
Jean-Pierre Rosen
> 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.
that's the only case).
--
---------------------------------------------------------
J-P. Rosen (ro...@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
Ludovic Brenta
> 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.
Matt Jaffe
Jeffrey R. Carter
>
> 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
Stefan Lucks
> 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
Peter Hermann
funny: a precious hint! I never knew from GNAT documentation...
Is more informative than all those options in gcc,gnatmake,etc.
Thank you
--
--Peter....@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/
Jeffrey R. Carter
>
> 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
Stefan Lucks
> 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)!
Jeffrey R. Carter
>
> 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.
Ludovic Brenta
> 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.