Change in GCC 5.1.0

Change in GCC 5.1.0

[Simon Wright]

GCC 4.9.1 (and presumably GNAT GPL 2014) allowed variable indexing on a
Set, even though there was no Variable_Indexing aspect in the spec.

GCC 5.1.0 doesn't.

So this code (from Gprbuild GPL 2014) compiled and, presumably, worked
when it shouldn't have:

   with Ada.Containers.Ordered_Sets;
   procedure Iteration is
      type Slave is new Integer;
      package Slave_S is new Ada.Containers.Ordered_Sets
        (Element_Type => Slave);
      Pool : Slave_S.Set;
      procedure Iterate (Proc : access procedure (S : in out Slave)) is
      begin
         for C in Pool.Iterate loop
            declare
               S : Slave := Slave_S.Element (C);
            begin
               Proc (S);
               Pool (C) := S;     -- <<<<<<<<<<<<<<< wrong
            end;
         end loop;
      end Iterate;
   begin
      null;
   end Iteration;

The thing about an (ordered) set is that replacing an element must
involve re-ordering the set, in case the element's position has
changed. So the compilable code in this case is

               Pool.Replace_Element (C, S);

That said, that looks awfully like tampering to me (if the order
changes, anyway). I await Gprbuild GPL 2015 with interest.

Re: Change in GCC 5.1.0

[jan.de.kruyf]

On Sunday, April 26, 2015 at 6:51:54 PM UTC+2, Simon Wright wrote:
> GCC 4.9.1 (and presumably GNAT GPL 2014) allowed variable indexing on a
> Set, even though there was no Variable_Indexing aspect in the spec.
> 
> GCC 5.1.0 doesn't.
> 
> So this code (from Gprbuild GPL 2014) compiled and, presumably, worked
> when it shouldn't have:
> 
>    with Ada.Containers.Ordered_Sets;
>    procedure Iteration is
>       type Slave is new Integer;
>       package Slave_S is new Ada.Containers.Ordered_Sets
>         (Element_Type => Slave);
>       Pool : Slave_S.Set;
>       procedure Iterate (Proc : access procedure (S : in out Slave)) is
>       begin
>          for C in Pool.Iterate loop
>             declare
>                S : Slave := Slave_S.Element (C);
>             begin
>                Proc (S);
>                Pool (C) := S;     -- <<<<<<<<<<<<<<< wrong
>             end;
>          end loop;
>       end Iterate;
>    begin
>       null;
>    end Iteration;
> 
> The thing about an (ordered) set is that replacing an element must
> involve re-ordering the set, in case the element's position has
> changed. So the compilable code in this case is
> 
>                Pool.Replace_Element (C, S);
> 
> That said, that looks awfully like tampering to me (if the order
> changes, anyway). I await Gprbuild GPL 2015 with interest.



Hi Simon,
Just to dampen your expectations a bit:
-------------------
$ gcc --version
gcc (GCC) 4.7.4 20140401 for GNAT GPL gpl-2014 (20140405)
Copyright (C) 2012 Free Software Foundation, Inc.
-------------------

And I had Ada code braking before, that should never have passed the compiler in the first place (shame on me).

On another note: I promised to do a write up on my embedded runtime development.. Well the runtime is going ok, but the laptop with my notes on it was nicked, so I went through the moves of rebuilding my development system etc, the last couple of weeks. The work itself was safe though.
And by the way there is still a fair bit of 32 bit stuff in the present Gnat release for Linux.

So as soon as I see that the board is running ok, i.e. the runtime is reasonably tested, I will try to do a summary.


Cheers,

j.

Re: Change in GCC 5.1.0

[Dmitry A. Kazakov]

On Sun, 26 Apr 2015 11:42:02 -0700 (PDT), jan.de.kruyf@gmail.com wrote:

> And by the way there is still a fair bit of 32 bit stuff in the present Gnat release for Linux.

I noticed that Stream_Element_Offset is now 64-bit on 32-bit systems. Maybe
some other standard types are as well.

That has serious consequences for implementations of lock-free concurrent
data structures, because pragma Atomic still does not accept 64-bit scalar
types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Change in GCC 5.1.0

[jan.de.kruyf]

> 
> I noticed that Stream_Element_Offset is now 64-bit on 32-bit systems. Maybe
> some other standard types are as well.
> 
> That has serious consequences for implementations of lock-free concurrent
> data structures, because pragma Atomic still does not accept 64-bit scalar
> types.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

And thanks for that observation Dmitry. I have a few of those in this project. But mostly 32 bit I think.

I was merely referring to trying to install GPS. There is always a host of unfulfilled dependencies when you try to run the 64 bit version. Which then turn out to be 32 bit libraries.

j.

Re: Change in GCC 5.1.0

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lypp6q96jb.fsf@pushface.org...
> GCC 4.9.1 (and presumably GNAT GPL 2014) allowed variable indexing on a
> Set, even though there was no Variable_Indexing aspect in the spec.
>
> GCC 5.1.0 doesn't.

Yeah, someone wrote an ACATS test and added it to the test suite. Presumably 
GNAT was fixed to pass the test.

                             Randy.