Bugzilla Bug 238452

dev-lang/gnat-gpl-4.1.3.2008-r1 and dev-lang/gnat-gpl-4.1.3.2008 produce
erroneous code unless an assertion, which should not have side effects, is
included in the source code.

Reproducible: Always

Steps to Reproduce:
Build and run the following program:
with System.Storage_Elements; use System.Storage_Elements;
with Ada.Text_IO; use Ada.Text_IO;
procedure Prov is
   B : aliased Boolean := False;
   A : access Boolean := B'Access;
begin
   while A /= null loop
      declare
         procedure P (M : in String);
         procedure P (M : in String) is
         begin
            Put (M & " : ");
--            pragma Assert --  Program fails without this useless pragma!
--              (To_Integer (A'Address) = 0 or To_Integer (A'Address) /= 0);
            if A = null then
               Put_Line ("(null)");
            else
               Put_Line (A.all'Img);
            end if;
         end P;
      begin
         P ("foo");
         A := null;
         P ("bar");
      end;
   end loop;
end Prov;

Actual Results:  
foo : FALSE
bar :

raised STORAGE_ERROR : stack overflow (or erroneous memory access)

Expected Results:  
foo : FALSE
bar : (null)

The expected result is achieved if the program is rebuilt and run with the
pragma Assert uncommented. i686-pc-linux-gnu-gnat-gcc-4.2 does not have this
bug, so removing the gnat-gpl packages from Portage and letting people use
gnat-gcc would solve this bug.

*** Bug 238453 has been marked as a duplicate of this bug. ***

Well, I can't reproduce this here (amd64):

gerr@Deleron ~/proj/prog/ada_stuff/tst $ gnatmake -O0 prov.adb
gnatgcc -c -O0 prov.adb
gnatbind -x prov.ali
gnatlink prov.ali
gerr@Deleron ~/proj/prog/ada_stuff/tst $ ./prov
foo : FALSE
bar : (null)

gerr@Deleron ~/proj/prog/ada_stuff/tst $ gnatgcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/dev-lang/gnat-gpl-4.1.3.2008-r1/work/gcc-4.1.3/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gnat-gpl-bin/4.1-2008
--includedir=/usr/lib64/gnat-gpl/x86_64-pc-linux-gnu/4.1-2008/include
--libdir=/usr/lib64/gnat-gpl/x86_64-pc-linux-gnu/4.1-2008
--libexecdir=/usr/libexec/gnat-gpl/x86_64-pc-linux-gnu/4.1-2008
--datadir=/usr/share/gnat-gpl-data/x86_64-pc-linux-gnu/4.1-2008
--mandir=/usr/share/gnat-gpl-data/x86_64-pc-linux-gnu/4.1-2008/man
--infodir=/usr/share/gnat-gpl-data/x86_64-pc-linux-gnu/4.1-2008/info
--program-prefix=gnat --enable-languages=c,ada --with-gcc
--enable-threads=posix --enable-shared --with-system-zlib
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --enable-nls
--without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-libada
Thread model: posix
gcc version 4.1.320080521 for GNAT GPL 2008 (20080521)

It may be x86 specific, or even specific to your system - gnat is quite
sensitive to system configuration. Try rebuilding gnat or rebuilding
binutils/libtool, possibly few other system packages (but I doubt that e.g. gcc
or glibc would affect this, the other two might) and just run revdep-rebuild
for a good measure, to see if you've accumulated some stray symbol resolution
failures..

As for:
>so removing the gnat-gpl packages from Portage and letting people use
>gnat-gcc would solve this bug.
this would be quite harsh, don't you think? ;)
The whole point of having multiple implementations is to give users a choice,
especially in the case of Ada, where we get new 2005 features implemented
yearly via one compiler then another.
gnat-gpl has lately (last 5+ years) a "cutting edge" - implementing the most
Ada-2005 features, so people definitely want (and request) it. Correspondingly,
in the experience of many, it is the less stable version. For this very reason
I never stabilized any of the gnat-gpl variant (this version is only ~arch, if
you did not notice) and likely will not, at least for a while. So, the usual
motto applies: if you want stable packages use stable profile ;), but pulling
this version off is, well, harsh given the circumstances :).