GNAT GPL 2009 for Mac OS X (Snow Leopard)
in [ADA]
|
From: (see below) on 22 Dec 2009 22:29 On 22/12/2009 23:37, in article 96854a61-2032-49b1-a8b2-8a5aee181701(a)22g2000yqr.googlegroups.com, "sjw" <simon.j.wright(a)mac.com> wrote: > Have just uploaded gnat-gpl-2009-i386-apple-darwin10.2.0-1.tar.bz2, > without the dependency; will remove the offending files after a day or > two. Unfortunately, it goes very badly wrong at -O1 optimization level on another example: ---------------------------------------------------------------------------- package test is type i64 is mod 2**64; for i64'Size use 64; subtype a_virtual_address is i64; subtype an_offset is a_virtual_address; function fetch_byte_from ( location : i64; position : an_offset ) return i64; end test; -- package body test is type i08 is mod 2**8; for i08'Size use 8; type an_i08_array is array (a_virtual_address range <>) of i08; for an_i08_array'Component_Size use i08'Size; type an_i08_group is new an_i08_array (0..7); for an_i08_group'Size use i64'Size; pragma Convention (C, an_i08_group); function fetch_byte_from ( location : i64; position : an_offset ) return i64 is the_location_as_i08s : an_i08_group; for the_location_as_i08s'Address use location'Address; pragma Import (Ada, the_location_as_i08s); begin return i64(the_location_as_i08s ((position and 2#111#) xor 2#111#)); end fetch_byte_from; end test; ---------------------------------------------------------------------------- thus: +===========================GNAT BUG DETECTED==============================+ | GPL 2009 (20090519) (i386-apple-darwin10.2.0) GCC error: | | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:312 | | Error detected at test.adb:14:7 | .... This error message does not appear at -O3, but the generated object program is non-functional, although that may be for a different reason, of course. This code compiled and ran correctly under the Leopard compilers I was using until I stupidly installed SL. What on earth has happened for GNAT to regress so badly in the face of what is often described as a tidying-up and performance release of OS X? -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: sjw on 22 Dec 2009 18:37 On Dec 22, 9:52 pm, sjw <simon.j.wri...(a)mac.com> wrote: > On Dec 22, 5:46 pm, "(see below)" <yaldni...(a)blueyonder.co.uk> wrote: > > > > > This is what happened when I tried out the 32-bit version: > [...] > > dyld: Symbol not found: ___gmpn_bases > > Referenced from: > > /opt/gnat-gpl-2009/libexec/gcc/i386-apple-darwin10.2.0/4.3.4/gnat1 > > Expected in: /usr/local/lib/libmpfr.1.dylib > > in /opt/gnat-gpl-2009/libexec/gcc/i386-apple-darwin10.2.0/4.3.4/gnat1 > > Very sorry about that. Have uploaded a more appropriate libmpfr at the > same place as the compiler (seems to be taking its time to appear ...) > unpack /some/where and > > $ export DYLD_LIBRARY_PATH=/some/where > > Am rebuilding without the dependency. Have just uploaded gnat-gpl-2009-i386-apple-darwin10.2.0-1.tar.bz2, without the dependency; will remove the offending files after a day or two.
From: (see below) on 22 Dec 2009 19:08 On 22/12/2009 21:52, in article a7b97585-f616-43e9-ac61-c468c88362fa(a)b2g2000yqi.googlegroups.com, "sjw" <simon.j.wright(a)mac.com> wrote: > On Dec 22, 5:46�pm, "(see below)" <yaldni...(a)blueyonder.co.uk> wrote: > >> This is what happened when I tried out the 32-bit version: > [...] >> dyld: Symbol not found: ___gmpn_bases >> � Referenced from: >> /opt/gnat-gpl-2009/libexec/gcc/i386-apple-darwin10.2.0/4.3.4/gnat1 >> � Expected in: /usr/local/lib/libmpfr.1.dylib >> �in /opt/gnat-gpl-2009/libexec/gcc/i386-apple-darwin10.2.0/4.3.4/gnat1 > > Very sorry about that. Have uploaded a more appropriate libmpfr at the > same place as the compiler (seems to be taking its time to appear ...) > unpack /some/where and > > $ export DYLD_LIBRARY_PATH=/some/where That works very nicely, and, unlike the other SL compilers I've tried previously, code compiled with inlining at -O3 does not malfunction (on the two major test cases I've tried so far, anyway). You might be interested to see what I'm doing with it: <http://www.findlayw.plus.com/>. (The KDF9 had a 48-bit word, and M is a 64-bit machine, so their emulators run in 64-bit mode at more than twice the speed of 32-bit mode.) Thanks for these great efforts. -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: (see below) on 23 Dec 2009 12:18 On 23/12/2009 14:26, in article 68e6e09a-9f02-4fd4-a87c-d1c43dd104e1(a)27g2000yqr.googlegroups.com, "sjw" <simon.j.wright(a)mac.com> wrote: > On Dec 23, 3:29�am, "(see below)" <yaldni...(a)blueyonder.co.uk> wrote: >> On 22/12/2009 23:37, in article >> 96854a61-2032-49b1-a8b2-8a5aee181...(a)22g2000yqr.googlegroups.com, "sjw" >> >> <simon.j.wri...(a)mac.com> wrote: >>> Have just uploaded gnat-gpl-2009-i386-apple-darwin10.2.0-1.tar.bz2, >>> without the dependency; will remove the offending files after a day or >>> two. >> >> Unfortunately, it goes very badly wrong at -O1 optimization level on another >> example: .... >> thus: >> >> +===========================GNAT BUG DETECTED==============================+ >> | GPL 2009 (20090519) (i386-apple-darwin10.2.0) GCC error: � � � � � � � � | >> | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:312 � � � � � � � � � | >> | Error detected at test.adb:14:7 � � � � � � � � � � � � � � � � � � � � �| >> ... >> >> This error message does not appear at -O3, but the generated object program >> is non-functional, although that may be for a different reason, of course. >> >> This code compiled and ran correctly under the Leopard compilers I was using >> until I stupidly installed SL. >> >> What on earth has happened for GNAT to regress so badly in the face of what >> is often described as a tidying-up and performance release of OS X? > > I don't know either, because here it compiles without complaint at -O > {0,1,2,3}! Hmm. Interesting ... What could account for the difference? Do you have any other versions of GNAT installed in that testing environment? -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: (see below) on 23 Dec 2009 12:21
On 23/12/2009 13:48, in article 4b321fb4$0$7621$9b4e6d93(a)newsspool1.arcor-online.net, "Georg Bauhaus" <rm.dash-bauhaus(a)futureapps.de> wrote: > (see below) schrieb: > >> That works very nicely, and, unlike the other SL compilers I've tried >> previously, code compiled with inlining at -O3 does not malfunction >> (on the two major test cases I've tried so far, anyway). > > FWIW, when we tried to find the best options for the Shootout > programs, it turned out that -gnatn -O2 -funroll-loops was > about as good as -O3. Sometimes the results were even faster. I dare say. I have made similar trials for my own code, and the optimization flags I use are empirically the best for its object code speed. -- Bill Findlay <surname><forename> chez blueyonder.co.uk |