GNAT GPL 2009 for Mac OS X (Snow Leopard)
sjw
find it at http://sourceforge.net/projects/gnuada/files/ (navigate to
GNAT_GPL Mac OS X/2009-snow-leopard-i386).
(see below)
af608388-8088-4779...@r24g2000yqd.googlegroups.com, "sjw"
<simon.j...@mac.com> wrote:
Many thanks -- I'll try it ASAP.
Any chance of a 64-bit build?
--
Bill Findlay
<surname><forename> chez blueyonder.co.uk
sjw
> On 22/12/2009 12:09, in article
>
> <simon.j.wri...@mac.com> wrote:
> > I've just released a 32-bit build of GNAT GPL 2009 for Snow Leopard;
> > GNAT_GPL Mac OS X/2009-snow-leopard-i386).
>
> Many thanks -- I'll try it ASAP.
> Any chance of a 64-bit build?
Will have a go, but it's a cross-build so may take some getting my
head round!
(see below)
5b0bf629-0935-414d...@d10g2000yqh.googlegroups.com, "sjw"
<simon.j...@mac.com> wrote:
Thanks. My two main projects run at 2.25 times the 32-bit speed in 64-bit
mode, so it is quite an issue for me.
This is what happened when I tried out the 32-bit version:
gnatmake -j2 -aI/Users/wf/emulation/Source -aO/Users/wf/emulation/MacOSX
-funwind-tables -g -gnatfl05wawCwl -gnatoVa -m32 -k -O1 EE9.adb -largs
-lgcc_eh -bargs -Sev >komlog.ada
gcc -c -I./ -I/Users/wf/emulation/Source -funwind-tables -g -gnatfl05wawCwl
-gnatoVa -m32 -O1 -I- /Users/wf/emulation/Source/EE9.adb
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
gcc: Internal error: Trace/BPT trap (program gnat1)
Please submit a full bug report to
<http://gcc.gnu.org/bugs.html>
with preprocessed source if appropriate.
gnatmake: "/Users/wf/emulation/Source/EE9.adb" compilation error
sjw
> 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.
sjw
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.
(see below)
a7b97585-f616-43e9...@b2g2000yqi.googlegroups.com, "sjw"
<simon.j...@mac.com> wrote:
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.
(see below)
96854a61-2032-49b1...@22g2000yqr.googlegroups.com, "sjw"
<simon.j...@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?
Georg Bauhaus
> 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.
sjw
> On 22/12/2009 23:37, in article
I don't know either, because here it compiles without complaint at -O
{0,1,2,3}!
(see below)
68e6e09a-9f02-4fd4...@27g2000yqr.googlegroups.com, "sjw"
<simon.j...@mac.com> wrote:
> On Dec 23, 3:29�am, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
>> On 22/12/2009 23:37, in article
>> 96854a61-2032-49b1-a8b2-8a5aee181...@22g2000yqr.googlegroups.com, "sjw"
>>
>> <simon.j.wri...@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?
(see below)
4b321fb4$0$7621$9b4e...@newsspool1.arcor-online.net, "Georg Bauhaus"
<rm.dash...@futureapps.de> wrote:
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.
Jerry
> On 22/12/2009 23:37, in article
I thought OS X was officially supported by AdaCore. From the viewpoint
of a casual bystander, it looks like someone is asleep at the wheel.
This isn't support that I can believe in.
Jerry
sjw
Mac OS X is indeed supported by AdaCore. But we, the users of GNAT
GPL, are *not*.
I have taken the source code provided by AdaCore in GNAT GPL 2009
about 9 months before Snow Leopard was released to the world and
rebuilt it with one change (caused by Apple's removal of sigreturn()).
I don't know any of AdaCore's customers who are supported on Mac OS X
so I can't say what AdaCore's advice to them has been; possibly those
customers who mustmustmust upgrade have been provided with wavefronts.
sjw
> On 23/12/2009 14:26, in article
> <simon.j.wri...@mac.com> wrote:
> > On Dec 23, 3:29 am, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
> >> 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?
Several! though I'd be surprised if any of them got invoked. Will
check further.
(see below)
eeaf5cb6-a582-4c90...@v25g2000yqk.googlegroups.com, "sjw"
<simon.j...@mac.com> wrote:
What I had in mind was interference between libraries, etc.
sjw
> On 23/12/2009 23:44, in article
> <simon.j.wri...@mac.com> wrote:
> > On Dec 23, 5:18 pm, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
> >> On 23/12/2009 14:26, in article
> >> Do you have any other versions of GNAT installed in that testing
> >> environment?
>
> > Several! though I'd be surprised if any of them got invoked. Will
> > check further.
>
> What I had in mind was interference between libraries, etc.
Each compiler I have installed lives in a different top-level
directory. I set my path using
$ export PATH=/opt/gnat-gpl-2009/bin:/usr/bin:/bin:/usr/sbin:/sbin
(ie, the 32-bit Snow Leopard compiler I just released on SF); now I
can compile your example without trouble. Did you use more options?
nidhoggr:findlay simon$ gnatmake -f test
gcc -c test.adb
nidhoggr:findlay simon$ gnatmake -f test -O0
gcc -c -O0 test.adb
nidhoggr:findlay simon$ gnatmake -f test -O1
gcc -c -O1 test.adb
nidhoggr:findlay simon$ gnatmake -f test -O2
gcc -c -O2 test.adb
nidhoggr:findlay simon$ gnatmake -f test -O3
gcc -c -O3 test.adb
nidhoggr:findlay
sjw
The cross-build (I think I may be wrong about that; perhaps there's an
'architecture' switch?) eventually produced a compiler. Unfortunately
it wouldn't process the simplest exception properly (SIGABRT).
I then had the idea, since the problem that stops building is that
init.c calls sigreturn() which isn't present in Snow Leopard, why not
fake up our own sigreturn() that does exactly what the patch did, then
link against that?
This turned out to work as hoped, result being that we can use Apple's
GNAT-GPL-2009 on Snow Leopard; see http://sourceforge.net/projects/gnuada/files/(navigate
to GNAT_GPL Mac OS X/2009-snow-leopard, get sigreturn.tar.bz2).
Sadly, the failure to handle exceptions with the 64-bit compiler is
unchanged (the 32-bit compiler is OK):
with Ada.Text_IO; use Ada.Text_IO;
procedure Raiser is
begin
begin
raise Constraint_Error;
exception
when Constraint_Error =>
Put_Line ("CE raised.");
end;
end Raiser;
nidhoggr:Test simon$ GNAT_PREFIX=/opt/gnat-gpl-2009_64-leopard
gnatmake -g -f raiser -largs sigreturn-64.o
gcc -c -g raiser.adb
gnatbind -x raiser.ali
gnatlink raiser.ali -g sigreturn-64.o
nidhoggr:Test simon$ ./raiser
Segmentation fault
Rats.
John B. Matthews
<f0b47208-95f0-48ef...@a32g2000yqm.googlegroups.com>,
sjw <simon.j...@mac.com> wrote:
> Each compiler I have installed lives in a different top-level
> directory. I set my path using
>
> $ export PATH=/opt/gnat-gpl-2009/bin:/usr/bin:/bin:/usr/sbin:/sbin
FWIW, here's a bash shell script I use to show the current PATH and the
alternative. The checkPath() and removePath() functions could be used in
managing multiple versions:
<http://home.roadrunner.com/~jbmatthews/gtk/lady.html#ada.sh>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
sjw
> In article
> <f0b47208-95f0-48ef-8184-9f36f2a2f...@a32g2000yqm.googlegroups.com>,
>
> sjw <simon.j.wri...@mac.com> wrote:
> > Each compiler I have installed lives in a different top-level
> > directory. I set my path using
>
> > $ export PATH=/opt/gnat-gpl-2009/bin:/usr/bin:/bin:/usr/sbin:/sbin
>
> FWIW, here's a bash shell script I use to show the current PATH and the
> alternative. The checkPath() and removePath() functions could be used in
> managing multiple versions:
>
> <http://home.roadrunner.com/~jbmatthews/gtk/lady.html#ada.sh>
Thanks for that.
I was meaning to reply specifically to Bill's query about possible
clashes caused by multiple compiler installations.
For normal work, I use a script gnatfe - https://sourceforge.net/projects/gnuada/files/,
navigate to gnatfe.
(see below)
65af5bac-a490-4e08...@m25g2000yqc.googlegroups.com, "sjw"
<simon.j...@mac.com> wrote:
> On Dec 24, 3:31�pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
>> In article
>> <f0b47208-95f0-48ef-8184-9f36f2a2f...@a32g2000yqm.googlegroups.com>,
>>
>> �sjw <simon.j.wri...@mac.com> wrote:
>>> Each compiler I have installed lives in a different top-level
>>> directory. I set my path using
>>
>>> � $ export PATH=/opt/gnat-gpl-2009/bin:/usr/bin:/bin:/usr/sbin:/sbin
>>
>> FWIW, here's a bash shell script I use to show the current PATH and the
>> alternative. The checkPath() and removePath() functions could be used in
>> managing multiple versions:
>>
>> <http://home.roadrunner.com/~jbmatthews/gtk/lady.html#ada.sh>
>
> Thanks for that.
>
> I was meaning to reply specifically to Bill's query about possible
> clashes caused by multiple compiler installations.
Well, I have deleted every copy of GNAT I could find, and downloaded
gnat-gpl-2009-i386-apple-darwin10.2.0-1.tar.bz2 afresh.
My .profile sets the PATH to:
PATH=/Users/wf/a2z/MPS/Cstage2:/Users/wf/ex-GU/HOCUS/sysdev/bin:/Users/wf/Pr
ograms:/Users/wf/KDF9/emulation/testing:/Users/wf/a2z/Testing:/Users/wf/Prog
rams/bin:/opt/gnat-gpl-2009/bin:/opt/local/sbin:/opt/local/bin:/usr/X11R6/bi
n:/usr/share:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
which gnat gives /opt/gnat-gpl-2009/bin/gnat
which gcc gives /opt/gnat-gpl-2009/bin/gcc
The error I reported on the "test" package has not gone away. 8-(
(see below)
"(see below)" <yald...@blueyonder.co.uk> wrote:
>
> Well, I have deleted every copy of GNAT I could find, and downloaded
> gnat-gpl-2009-i386-apple-darwin10.2.0-1.tar.bz2 afresh.
>
> My .profile sets the PATH to:
>
> PATH=/Users/wf/a2z/MPS/Cstage2:/Users/wf/ex-GU/HOCUS/sysdev/bin:/Users/wf/Pr
> ograms:/Users/wf/KDF9/emulation/testing:/Users/wf/a2z/Testing:/Users/wf/Prog
> rams/bin:/opt/gnat-gpl-2009/bin:/opt/local/sbin:/opt/local/bin:/usr/X11R6/bi
> n:/usr/share:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
>
> which gnat gives /opt/gnat-gpl-2009/bin/gnat
> which gcc gives /opt/gnat-gpl-2009/bin/gcc
>
> The error I reported on the "test" package has not gone away. 8-(
|||||||||
I.e., the compiler failure at -O1 has not gone away.
The malfunction at -O3 was my fault, and the optimised module does work.
sjw
> On 24/12/2009 17:24, in article
I said 'gnatmake -f test -O1' etc, did you have any other options?
sjw
Not actually a cross build, which would be specified by configuring
with --target=x86_64-apple-darwin10.2.0; I don't know what the
technical name is, but configuring with --build=x86_64-apple-
darwin10.2.0 does the trick.
Unfortunately the built compiler won't handle exceptions; a severe
failing. Perhaps Apple have changed the OS features that GNAT uses to
support exception handling? (I tried configuring with --enable-sjlj-
exceptions, no joy).
sjw
> On 24/12/2009 19:20, in article C7596F6A.12FADA%yaldni...@blueyonder.co.uk,
> The malfunction at -O3 was my fault, and the optimised module does work.
The verbose results of my compilation are
$ GNAT_PREFIX=/opt/gnat-gpl-2009 gnatmake -f test -O1 -cargs -v
gcc -c -O1 -v test.adb
Using built-in specs.
Target: i386-apple-darwin10.2.0
Configured with: ../gcc-43-src/configure --prefix=/opt/gnat-gpl-2009 --
with-gmp=/opt/gnu --with-mpfr=/opt/gnu --disable-multilib --enable-
languages=c,ada --disable-libada
Thread model: posix
gcc version 4.3.4 20090511 for GNAT GPL 2009 (20090511) (GCC)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-gnatea' '-c' '-O1'
'-v' '-gnatez' '-mtune=generic'
/opt/gnat-gpl-2009/libexec/gcc/i386-apple-darwin10.2.0/4.3.4/gnat1 -
quiet -dumpbase test.adb -O1 -gnatez -mmacosx-version-min=10.6.2 -
gnatea -gnatez -mtune=generic -fPIC test.adb -o /var/folders/it/
itCqFVrG2P8Zlk+F71KE3U+++TI/-Tmp-//cccOTx7p.s
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-gnatea' '-c' '-O1'
'-v' '-gnatez' '-mtune=generic'
as -arch i386 -force_cpusubtype_ALL -o test.o /var/folders/it/
itCqFVrG2P8Zlk+F71KE3U+++TI/-Tmp-//cccOTx7p.s
COMPILER_PATH=/opt/gnat-gpl-2009/libexec/gcc/i386-apple-
darwin10.2.0/4.3.4/:/opt/gnat-gpl-2009/libexec/gcc/i386-apple-
darwin10.2.0/4.3.4/:/opt/gnat-gpl-2009/libexec/gcc/i386-apple-
darwin10.2.0/:/opt/gnat-gpl-2009/lib/gcc/i386-apple-
darwin10.2.0/4.3.4/:/opt/gnat-gpl-2009/lib/gcc/i386-apple-
darwin10.2.0/
LIBRARY_PATH=/opt/gnat-gpl-2009/lib/gcc/i386-apple-
darwin10.2.0/4.3.4/:/opt/gnat-gpl-2009/lib/gcc/i386-apple-
darwin10.2.0/4.3.4/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-gnatea' '-c' '-O1'
'-v' '-gnatez' '-mtune=generic'
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-gnatea' '-c' '-O1'
'-v' '-gnatez' '-mtune=generic'
Not sure if we'll be able to glean any significant differences ...
(see below)
c7699bca-f565-4ae7...@b2g2000yqi.googlegroups.com, "sjw"
<simon.j...@mac.com> wrote:
Many, many options. 8-)
gnatmake -j2 -I- -aI//Users/wf/a2z/Source/a -aI//Users/wf/Adalib/My/Bit_Sets
-aI//Users/wf/Adalib/My/Containers -aI//Users/wf/Adalib/My/Timing
-aI//Users/wf/Adalib/My/Distributor -aI//Users/wf/a2z/Source/shared
-aI//Users/wf/a2z/Source/a -aO//Users/wf/a2z/MacOSX -funwind-tables -g
-gnatfl05wawCwl -gnatoVa -O1 test -largs -lgcc_eh -bargs -Sev >comlog.ada
Jerry
> This turned out to work as hoped, result being that we can use Apple's
> GNAT-GPL-2009 on Snow Leopard;
Is this a typo?
Jerry
sjw
Yes, sorry; s/Apple/AdaCore/