Differences in finalization of controlled objects between gcc 4.6 and gcc 4.7

Differences in finalization of controlled objects between gcc 4.6 and gcc 4.7

[Markus Schöpflin]

Hello,

please consider the following piece of code:

---%<---
with ADA.FINALIZATION;
package CTRL is
    type T is new ADA.FINALIZATION.CONTROLLED with null record;
    procedure INITIALIZE (X : in out T);
    procedure ADJUST (X : in out T);
    procedure FINALIZE (X : in out T);
end CTRL;
--
with TEXT_IO;
with SYSTEM.ADDRESS_IMAGE;
package body CTRL is
    procedure INITIALIZE (X : in out T) is
    begin
       TEXT_IO.PUT_LINE (SYSTEM.ADDRESS_IMAGE (X'Address) & ": I");
    end INITIALIZE;

    procedure ADJUST (X : in out T) is
    begin
       TEXT_IO.PUT_LINE (SYSTEM.ADDRESS_IMAGE (X'Address) & ": A");
    end ADJUST;

    procedure FINALIZE (X : in out T) is
    begin
       TEXT_IO.PUT_LINE (SYSTEM.ADDRESS_IMAGE (X'Address) & ": F");
    end FINALIZE;

end CTRL;
--
with CTRL;
procedure TEST_CTRL
is
    function CREATE return CTRL.T is
    begin
       return X : CTRL.T;
    end;
    X : array (1 ..2) of CTRL.T := (others => CREATE);
begin
    null;
end;
--->%---

Compiled and executed with gcc-4.6.3 it gives the following result:

 > /opt/gcc-4.6.3/bin/gnatmake -j4 -O3 -g -gnatwa -gnatn test_ctrl
gcc -c -O3 -g -gnatwa -gnatn test_ctrl.adb
test_ctrl.adb:13:04: warning: variable "X" is not referenced
gcc -c -O3 -g -gnatwa -gnatn ctrl.adb
gnatbind -x test_ctrl.ali
gnatlink test_ctrl.ali -O3 -g
 > ./test_ctrl
BFD1BA54: I
08078450: A
BFD1BA54: F
BFD1BA20: A
BFD1BA54: I
08078460: A
BFD1BA54: F
BFD1BA2C: A
08078460: F
08078450: F
BFD1BA2C: F
BFD1BA20: F

Compiled and executed with gcc-4.7.1 it gives the following result:

 > /opt/gcc-4.7.1/bin/gnatmake -j4 -O3 -g -gnatwa -gnatn test_ctrl
gcc -c -O3 -g -gnatwa -gnatn test_ctrl.adb
test_ctrl.adb:13:04: warning: variable "X" is not referenced
gcc -c -O3 -g -gnatwa -gnatn ctrl.adb
gnatbind -x test_ctrl.ali
gnatlink test_ctrl.ali -O3 -g
 > ./test_ctrl
BFE0B018: I
08077F90: A
BFE0B018: F
BFE0B028: A
08077F90: F
08077F90: F
BFE0B018: I
08077FA0: A
BFE0B018: F
BFE0B02C: A
08077FA0: F
08077FA0: F
BFE0B02C: F
BFE0B028: F

What surprises me is that the objects with address 08077F90 and 08077FA0 are 
finalized twice in the second case. I'm aware that this is allowed but 
nevertheless I'm wondering why it happens here, because up to now I was 
thinking that only by explicitly calling finalize() or when tasks are involved 
that this actually happens. Should I consider this a regression in gcc and 
report it as such?

On a second note, I'm quite surprised at the number of temporary objects 
created in this example, both by gcc 4.6 and 4.7. Is there a way to have the 
objects created in place directly in the array?

Regards,
Markus

Re: Differences in finalization of controlled objects between gcc 4.6 and gcc 4.7

[Georg Bauhaus]

On 19.07.12 14:23, Markus Schï¿œpflin wrote:
> Is there a way to have the objects created in place directly in the array?


Can you make the type limited?

(And of so, then T could also be self-initializing:

   type T is new ADA.FINALIZATION.LIMITED_CONTROLLED with
      record
         SELF : T_PTR := INIT_T (T'Unchecked_Access);
         ITEM : INTEGER;
      end record;
(...

   function INIT_T (X : T_PTR) return T_PTR is
   begin
      TEXT_IO.PUT_LINE (SYSTEM.ADDRESS_IMAGE (X'Address) & ": <");
      X.ITEM := 123;
      return X;
   end INIT_T;

...)

Re: Differences in finalization of controlled objects between gcc 4.6 and gcc 4.7

[Markus Schöpflin]

Am 19.07.2012 15:45, schrieb Georg Bauhaus:
> On 19.07.12 14:23, Markus Schï¿œpflin wrote:
>> Is there a way to have the objects created in place directly in the array?
>
> Can you make the type limited?

No, I need to be able to copy them around. But IMHO that shouldn't make a 
difference in this case, the compiler should be able to figure out that it can 
construct the objects in place, shouldn't it?

Surprisingly (at least for me) it *does* make a difference when I define T as

      type T is new ADA.FINALIZATION.LIMITED_CONTROLLED with null record;

Then the output looks like this with both versions of gcc:

 > ./test_ctrl
BFBE03D4: I
BFBE03D8: I
BFBE03D8: F
BFBE03D4: F

Regards,
Markus

Re: Differences in finalization of controlled objects between gcc 4.6 and gcc 4.7

[Georg Bauhaus]

On 19.07.12 15:59, Markus Schï¿œpflin wrote:
> Am 19.07.2012 15:45, schrieb Georg Bauhaus:
>> On 19.07.12 14:23, Markus Schï¿œpflin wrote:
>>> Is there a way to have the objects created in place directly in the array?
>>
>> Can you make the type limited?
> 
> No, I need to be able to copy them around. But IMHO that shouldn't make a
> difference in this case, the compiler should be able to figure out that it can
> construct the objects in place, shouldn't it?

Not sure, wouldn't this optimize the AFCed actions away without
the user saying so? Anyway, maybe renaming works better?

   subtype SMALL is POSITIVE range 1 .. 2;
   type A is array (SMALL) of CTRL.T;

   function MAKER return A is
   begin
      return RESULT : A;
   end MAKER;

   X : A renames MAKER;

Re: Differences in finalization of controlled objects between gcc 4.6 and gcc 4.7

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

"Markus Sch�pflin" <no.spam@spam.spam> wrote in message 
news:ju93rg$43j$1@speranza.aioe.org...
> Am 19.07.2012 15:45, schrieb Georg Bauhaus:
>> On 19.07.12 14:23, Markus Sch�pflin wrote:
>>> Is there a way to have the objects created in place directly in the 
>>> array?
>>
>> Can you make the type limited?
>
> No, I need to be able to copy them around. But IMHO that shouldn't make a 
> difference in this case, the compiler should be able to figure out that it 
> can construct the objects in place, shouldn't it?

If the type isn't limited, there are cases where you can't build the objects 
in place. And it's likely that the implementation of build-in-place 
functions is different than ones that copy (BiP probably passes in some 
memory and/or a storage pool; regular just returns a temporary created 
inside the function).

It's unlikely that an implementer would want to have two versions of a 
function, so its quite possible that they don't ever build-in-place 
non-limited objects.

(But there is a permission to do so, so you cannot depend on the Adjust 
being called.)

                                  Randy.

Re: Differences in finalization of controlled objects between gcc 4.6 and gcc 4.7

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]


"Markus Sch�pflin" <no.spam@spam.spam> wrote in message 
news:ju8u7t$kh9$1@speranza.aioe.org...
...
> What surprises me is that the objects with address 08077F90 and 08077FA0 
> are finalized twice in the second case. I'm aware that this is allowed but 
> nevertheless I'm wondering why it happens here, because up to now I was 
> thinking that only by explicitly calling finalize() or when tasks are 
> involved that this actually happens. Should I consider this a regression 
> in gcc and report it as such?

Those look like the temporary objects to me (since the array X should be 
finalized last, and these aren't that). And I don't know of any reason that 
temporaries should be finalized twice (or any reason that an implementer 
would want to do that). I think it is a bug, and you ought to report it as 
such.

                                                  Randy.

Re: Differences in finalization of controlled objects between gcc 4.6 and gcc 4.7

[Markus Schöpflin]

Am 20.07.2012 04:59, schrieb Randy Brukardt:
> "Markus Schï¿œpflin" <no.spam@spam.spam> wrote in message
> news:ju8u7t$kh9$1@speranza.aioe.org...
> ...
>> What surprises me is that the objects with address 08077F90 and 08077FA0
>> are finalized twice in the second case. I'm aware that this is allowed but
>> nevertheless I'm wondering why it happens here, because up to now I was
>> thinking that only by explicitly calling finalize() or when tasks are
>> involved that this actually happens. Should I consider this a regression
>> in gcc and report it as such?
>
> Those look like the temporary objects to me (since the array X should be
> finalized last, and these aren't that). And I don't know of any reason that
> temporaries should be finalized twice (or any reason that an implementer
> would want to do that). I think it is a bug, and you ought to report it as
> such.

It turned out that GNAT Pro 7 shows the same behaviour, so I reported it to 
AdaCore. So the fix will probably end up in GCC/GNAT in the foreseeable future.

Thanks,
Markus