[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-05 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #10 from Eric Botcazou --- The code doesn't compile now: gcc -c test1.adb +===GNAT BUG DETECTED==+ | 5.3.1 20151205 [gcc-5-branch revision 231314] (x86_64-suse-linux)| | Program_Error exp_disp.adb:8404 explicit raise | | Error detected at test1.adb:14:4
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181 --- Comment #9 from nicolas.boulenguez at free dot fr --- 4.9.0 20140218 (experimental) [trunk revision 207856] (x86_64-linux-gnu) Program_Error exp_disp.adb:8456 explicit raise Error detected at test1.adb:21:4
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #8 from nicolas.boulenguez at free dot fr 2011-08-31 22:22:13 UTC --- found 4.6.1
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
--- Comment #7 from anhvofrcaus at gmail dot com 2008-04-24 15:37 --- Samuel and Ludovic, You both are right that GNAT has a bug, and the original test code was a good one. In fact, Pak2.Eq(Z1, Z2) would return True if GNAT worked correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
--- Comment #6 from ludovic at ludovic-brenta dot org 2008-04-24 09:55 --- (In reply to comment #4) Anh Vo, you are perfectly right up to a point: Pak1.Eq returns True and Pak2.Eq returns False, therefore comparing the two results yields False. Where you are wrong is where you think Pak2.Eq is correct in returning False. This is the bug. Pak2.Eq should return True. To explain another way: ARM 3.4(27) defines precisely the behaviour of a call to an inherited subprogram. Pak2.Eq is inherited and not overridden, so 3.4(27) applies. Per ARM 3.4(27), calling Pak2.Eq (Z1, Z2) is by definition equivalent to calling Pak1.Eq (Pak1.T1 (Z1), Pak1.T1 (Z2)) Therefore the two calls must yield the same result (i.e. True). The test case shows clearly that this is not the case, i.e. GNAT has a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
--- Comment #5 from sam at gcc dot gnu dot org 2008-04-24 08:36 --- Ahn Vo: Pak2.Eq is *the same* as Pak1.Eq, that's the whole point. Thus both consider only T1 aspects of the objects. What you say would be true if the code had been: package Pak1 is type T1 is tagged null record; function Eq(X, Y: T1) return Boolean renames "="; end Pak1; package Pak2 is type T2 is new Pak1.T1 with record F1: Integer; end record; function Eq(X, Y: T2) return Boolean renames "="; -- This line added end Pak2; But there is no such line in the original example. In the original example, Pak2.Eq is *not* the "=" operator on T2, it is the "=" operator on T1 objects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
--- Comment #4 from anhvofrcaus at gmail dot com 2008-04-24 01:32 --- Samuel: That is exactly my point. Pak1.= operator only operates on T1. The conversion Pak1.T1(Z1) and Pak1.T1(Z2) will drop component F1. Thus, as I said before Pak1.Eq(Pak1.T1(Z1), Pak1.T1(Z2)) always yields True. In the meantime, Pak2.Eq(Z1, Z2) always returns False. Therefore, comparing True and False should yield False. -- anhvofrcaus at gmail dot com changed: What|Removed |Added CC||anhvofrcaus at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
--- Comment #3 from ludovic at ludovic-brenta dot org 2008-04-23 23:47 --- Exactly. The quoted portion of the ARM says that Pak2.Eq (Z1, Z2) should implicitly convert Z1 and Z2 to type T1, then call Pak1.Eq, then return True. Instead, it returns False as though GNAT synthesised a new function Eq (X, Y : T2) return Boolean renames "="; inside of Pak2, where "=" is the predefined equality operator for T2. This synthetic function overrides Pak1.Eq without the programmer's consent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
--- Comment #2 from sam at gcc dot gnu dot org 2008-04-23 23:21 --- Anh Vo: I think that you are wrong and that Ludovic is right. Note that Eq (T2, T2) is not a renaming of T2 "=" operator, it is, through inheritance, a renaming of T1 "=" operator with signature function "=" (X, Y : T1) return Boolean; Note that this function knows *nothing* about T2, so it cannot obviously compare new fields added in T2, it only compares fields already present in T1. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
--- Comment #1 from anhvofrcaus at gmail dot com 2008-04-23 21:59 ---
The GNAT behaves correctly by printing FAILED because the test code has a
problem. When converting Child type to the Parent type, any component(s) of the
Child type will be lost. Therefore, Pak1.Eq(Pak1.T1(Z1), Pak1.T1(Z2) should
return True (due to the Parent type having null record), and Pak2.Eq(Z1, Z2)
should return False because the objects are different obviously. Thus, the
equality Pak2.Eq(Z1, Z2) = Pak1.Eq(Pak1.T1(Z1), Pak1.T1(Z2)) should evaluate to
False. In summary, the equality should be changed to inequality as shown below.
with Text_IO; use Text_IO;
procedure Test1 is
package Pak1 is
type T1 is tagged null record;
function Eq(X, Y: T1) return Boolean renames "=";
end Pak1;
package Pak2 is
type T2 is new Pak1.T1 with record
F1: Integer;
end record;
end Pak2;
Z1: Pak2.T2 := (F1 => 1);
Z2: Pak2.T2 := (F1 => 2);
begin
if Pak2.Eq(Z1, Z2) /= Pak1.Eq(Pak1.T1(Z1), Pak1.T1(Z2))
then Put_Line("PASSED");
else Put_Line("FAILED");
end if;
end Test1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181
