Adress => Access: types for unchecked conversion have different sizes

Adress => Access: types for unchecked conversion have different sizes

[Martin Krischik]

Hello,

I currently have another go at building GNAT for MAx OS X. the current  
error message I am looking at is:

{{{
/Volumes/Daten/Developer/MacPorts/dports/lang/gnat-gcc/work/build/./gcc/xgcc  
-B/Volumes/Daten/Developer/MacPorts/dports/lang/gnat-gcc/work/build/./gcc/  
-B/opt/local/x86_64-apple-darwin10/bin/  
-B/opt/local/x86_64-apple-darwin10/lib/ -isystem  
/opt/local/x86_64-apple-darwin10/include -isystem  
/opt/local/x86_64-apple-darwin10/sys-include    -c -g -O2 -m32 -fPIC  
-pipe  -W -Wall -gnatpg -m32  a-direct.adb -o a-direct.o
a-direct.adb:676:13: warning: types for unchecked conversion have  
different sizes
}}}

The code in question is:

{{{
          declare
             subtype Path_String is String (1 .. Filename_Len);
             type    Path_String_Access is access Path_String;

             function Address_To_Access is new
               Ada.Unchecked_Conversion
                 (Source => Address,
                  Target => Path_String_Access);

             Path_Access : constant Path_String_Access :=
                             Address_To_Access (Filename_Addr);

          begin
             Last := Filename_Len;
             Name (1 .. Last) := Path_Access.all;
          end;
}}}

Strange. Anybody got an idea what went wrong here?

And I wonder if some `for Address use` magic would not be more appropriate  
here.

Regards

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Adress => Access: types for unchecked conversion have different sizes

[Edward Fish]

On Mar 12, 8:08 am, "Martin Krischik" <krisc...@users.sourceforge.net>
wrote:
> Hello,
>
> I currently have another go at building GNAT for MAx OS X. the current  
> error message I am looking at is:
>
> {{{
> /Volumes/Daten/Developer/MacPorts/dports/lang/gnat-gcc/work/build/./gcc/xgcc  
> -B/Volumes/Daten/Developer/MacPorts/dports/lang/gnat-gcc/work/build/./gcc/  
> -B/opt/local/x86_64-apple-darwin10/bin/  
> -B/opt/local/x86_64-apple-darwin10/lib/ -isystem  
> /opt/local/x86_64-apple-darwin10/include -isystem  
> /opt/local/x86_64-apple-darwin10/sys-include    -c -g -O2 -m32 -fPIC  
> -pipe  -W -Wall -gnatpg -m32  a-direct.adb -o a-direct.o
> a-direct.adb:676:13: warning: types for unchecked conversion have  
> different sizes
>
> }}}
>
> The code in question is:
>
> {{{
>           declare
>              subtype Path_String is String (1 .. Filename_Len);
>              type    Path_String_Access is access Path_String;
>
>              function Address_To_Access is new
>                Ada.Unchecked_Conversion
>                  (Source => Address,
>                   Target => Path_String_Access);
>
>              Path_Access : constant Path_String_Access :=
>                              Address_To_Access (Filename_Addr);
>
>           begin
>              Last := Filename_Len;
>              Name (1 .. Last) := Path_Access.all;
>           end;
>
> }}}
>
> Strange. Anybody got an idea what went wrong here?
>
> And I wonder if some `for Address use` magic would not be more appropriate  
> here.
>
> Regards
>
> Martin
> --
> Martin Krischik
> mailto://krisc...@users.sourceforge.nethttps://sourceforge.net/users/krischik

You could try adding ALL to Path_String_Access; IIRC Access w/o the
ALL is a
fat-pointer (keeping info about the object) whereas the Access ALL is
a thin-
pointer (an address) in GNAT.

Re: Adress => Access: types for unchecked conversion have different sizes

[Simon Wright]

"Martin Krischik" <krischik@users.sourceforge.net> writes:

> I currently have another go at building GNAT for MAx OS X. the current
> error message I am looking at is:

Hi Martin,

I managed to build an x86_64 4.5.0, see
http://public.me.com/simon.j.wright in the gcc folder.

I've since used this to build 4.5.2 and a 4.6.0, no problems.

What version is that you're trying to build? the probematic code is about
100 lines further down in 4.6.0.

Re: Adress => Access: types for unchecked conversion have different sizes

[Randy Brukardt]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message 
news:op.vr8kbsndz25lew@macpro-eth1.krischik.com...
...
> The code in question is:
>
> {{{
>          declare
>             subtype Path_String is String (1 .. Filename_Len);
>             type    Path_String_Access is access Path_String;

As someone else noted, this is a pool-specific access type. It should never 
point at anything other than memory created by an allocator. (Janus/Ada 
actually checks that; you'd get Constraint_Error if you tried to dereference 
the result of the code below.) If you need to point it at something else, 
you need to use a general access type (that is, "access all").

>             function Address_To_Access is new
>               Ada.Unchecked_Conversion
>                 (Source => Address,
>                  Target => Path_String_Access);
>
>             Path_Access : constant Path_String_Access :=
>                             Address_To_Access (Filename_Addr);
>
>          begin
>             Last := Filename_Len;
>             Name (1 .. Last) := Path_Access.all;
>          end;
> }}}
...
> And I wonder if some `for Address use` magic would not be more appropriate 
> here.

No, that is a lousy way to handle this sort of problem, as is this code. 
(This appears to be an old Ada 83 design, completely inappropriate in modern 
Ada -- and a lousy idea in Ada 83, too.). Ada has package 
Address_to_Access_Conversions for this sort of problem. (That package also 
has an annoyance: it declares a new access type for each instance, forcing 
some extra conversions if you intend to use a type declared elsewhere.)

Lastly, access to unconstrained is rarely the right thing in such code; it 
might work on some compiler some of the time, but will not work in general. 
(Note that Annex B does not require such things to work for interfacing, and 
using addresses is very similar to interfacing.)

                            Randy.

Re: Adress => Access: types for unchecked conversion have different sizes

[Martin Krischik]

Hi Simon

Am 12.03.2011, 18:05 Uhr, schrieb Simon Wright <simon@pushface.org>:

> I managed to build an x86_64 4.5.0, see
> http://public.me.com/simon.j.wright in the gcc folder.

I give it a try.

> What version is that you're trying to build? the probematic code is about
> 100 lines further down in 4.6.0.

The current release version 4.5.2 for the MacPorts. Currently I try with  
the GPL 2010 version. But this version seems to be to advanced.

You would not want to join the MacPorts team to provide GNAT for Mac OS X,  
would you?

Regards

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Adress => Access: types for unchecked conversion have different sizes

[Martin Krischik]

Am 13.03.2011, 04:32 Uhr, schrieb Randy Brukardt <randy@rrsoftware.com>:

> No, that is a lousy way to handle this sort of problem, as is this code.

That for you insight.  Just, you did notice that we talk about the GNAT  
compile compiling itself here, did you?

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Adress => Access: types for unchecked conversion have different sizes

[Simon Wright]

"Martin Krischik" <krischik@users.sourceforge.net> writes:

> You would not want to join the MacPorts team to provide GNAT for Mac
> OS X, would you?

I haven't seen any advantage to me in using MacPorts myself, and it'd
seem very risky to attempt to build ports not being a user.

Re: Adress => Access: types for unchecked conversion have different sizes

[Martin Krischik]

Am 13.03.2011, 12:57 Uhr, schrieb Simon Wright <simon@pushface.org>:

> "Martin Krischik" <krischik@users.sourceforge.net> writes:
>
>> You would not want to join the MacPorts team to provide GNAT for Mac
>> OS X, would you?
>
> I haven't seen any advantage to me in using MacPorts myself, and it'd
> seem very risky to attempt to build ports not being a user.

Well, you can't. MacPorts is self hosted - you need to be a MacPorts user  
to build ports ;-).

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Adress => Access: types for unchecked conversion have different sizes

[Randy Brukardt]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message 
news:op.vr9z56ucz25lew@macpro-eth1.krischik.com...
> Am 13.03.2011, 04:32 Uhr, schrieb Randy Brukardt <randy@rrsoftware.com>:
>
>> No, that is a lousy way to handle this sort of problem, as is this code.
>
> That for you insight.  Just, you did notice that we talk about the GNAT 
> compile compiling itself here, did you?

I did, so it is of course true that portability is less important. But why 
use lousy Ada design in any Ada code? The only thing I can think of is that 
it was designed for Ada 83 -- but that doesn't make much sense for GNAT 
code.

                          Randy. 

Re: Adress => Access: types for unchecked conversion have different sizes

[Martin Krischik]

Am 14.03.2011, 00:16 Uhr, schrieb Randy Brukardt <randy@rrsoftware.com>:

> I did, so it is of course true that portability is less important. But  
> why
> use lousy Ada design in any Ada code? The only thing I can think of is  
> that
> it was designed for Ada 83 -- but that doesn't make much sense for GNAT
> code.

Indeed it does not. And there is quite a lot of strange stuff going on in  
the GNAT compiler.

Anyway it compiler it I remove the -m64 option. So I guess it is a problem  
in handling x86_64 code. Which in turn means I will “only” be able to  
create a 32 bit compiler. Ahh well, better then nothing.

Martin
--
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Adress => Access: types for unchecked conversion have different sizes

[Simon Wright]

"Martin Krischik" <martin.krischik@noser.com> writes:

> Anyway it compiler it I remove the -m64 option. So I guess it is a
> problem in handling x86_64 code. Which in turn means I will “only” be
> able to create a 32 bit compiler. Ahh well, better then nothing.

There were a lot of issues on the move to x86_64 on Snow Leopard (in
particular exception handling). The released 4.5.0 pretty much fixed
that. But, as I said, it works here with no problems - the 4.5.2 release
built (over 4.5.0, admittedly) with no problems, and I don't remember
much if any with gcc version 4.6.0 20110225 (experimental) [trunk
revision 157963] (GCC).

For what it's worth, this is the configure command line I used for 4.6.0:

../gcc-trunk-svn/configure --prefix=/opt/gcc-4.6.0-x86_64 \
--disable-multilib --enable-languages=c,ada,c++,fortran \
--with-gmp=/opt/gnu --with-mpfr=/opt/gnu --with-mpc=/opt/gnu \
--build=x86_64-apple-darwin10 --disable-bootstrap

(the GMP, MPFR and MPC links are to a set of static libraries - burnt
once too often by forgetting to give other users the dylibs).

Note the '--disable-bootstrap' confidence!