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 :).
