Re: [Bug ada/36939] Build Failure Ada SH2e

Re: [Bug ada/36939] Build Failure Ada SH2e

[Laurent GUERBY]

On Mon, 2011-02-07 at 10:04 +0100, Arnaud Charlet wrote:
> > With Laurent's stub version of s-scaval.adb added as s-scaval-sh.adb and a
> > minor change to a ada/gcc-interface/Makefile.in, sh-rtems now builds
> > Ada.
> > 
> > Is this OK to commit?
> 
> Note that the proper place to submit a patch officially is gcc-patches.
> 
> In any case, adding s-scaval-sh.adb isn't OK, s-scaval.adb isn't meant to
> have target specific implementations, or stubbed implementation, that's
> a kludge which is not really acceptable for mainstream.

Yes my solution was a kludge to let at least the RTS compile on this
target.

The issue is that s-scaval.adb makes pretty strong target assumptions
and so isn't portable as is.

How should we deal with targets supporting only single precision? What
do you suggest?

Thanks in advance,

Laurent

Re: [Bug ada/36939] Build Failure Ada SH2e

[Arnaud Charlet]

> The issue is that s-scaval.adb makes pretty strong target assumptions
> and so isn't portable as is.
> 
> How should we deal with targets supporting only single precision? What
> do you suggest?

Aren't double precision supported/supportable in software?

In any case, if you don't have support for double precision, then you'll
have much more troubles than just s-scaval.adb, so this is really not
the way to go, and you should basically give up on trying to build a
full Ada run-time.

Arno

Re: [Bug ada/36939] Build Failure Ada SH2e

[Joel Sherrill]

On 02/07/2011 03:33 PM, Arnaud Charlet wrote:
>> The issue is that s-scaval.adb makes pretty strong target assumptions
>> and so isn't portable as is.
>>
>> How should we deal with targets supporting only single precision? What
>> do you suggest?
> Aren't double precision supported/supportable in software?
>
I would assume that the compile theoretically could
generate the code.  But I don't know if it does or not.
> In any case, if you don't have support for double precision, then you'll
> have much more troubles than just s-scaval.adb, so this is really not
> the way to go, and you should basically give up on trying to build a
> full Ada run-time.
>
But this is just one of the multilib's for this target.  The others
are OK.

What did you guys do for the AVR?  It is also limited.

Ralf  Corsepius also mentioned to me the case where the
size of int/long varies amongst a target's various multilib's.
This would also break since AFAIK the same Ada source is
being built for all multilibs.

> Indirectly related to this issue: How does Ada handle 2-byte int/4-byte
> long and 4-byte int/4-byte long targets?
> We also have them (the 2-byte int/4-byte long rtems multilibs list is
> almost idential to the list above - Particularily interesting: h8300 -
> It's sizeof(int) varies between multilib variants).
>
> I'd expect them to either have the similar issues with them, or them to
> have implemented an approach which could be extended to handling the 4
> byte-float/4 byte-double issue.
>
> --- Could also be they are always using "long" and presuming it to be
> 4-byte wide (Which would mean Ada's C-API would likely be broken).
>
I am suspicious there is an unwritten set of assumptions
about a target's features so it can support Ada.  I already
ignore Ada on 3 RTEMS targets since their memory space
is too limited.

> Arno

--joel

Re: [Bug ada/36939] Build Failure Ada SH2e

[Ralf Corsepius]

On 02/07/2011 10:56 PM, Joel Sherrill wrote:
>
> Ralf  Corsepius also mentioned to me the case where the
> size of int/long varies amongst a target's various multilib's.
> This would also break since AFAIK the same Ada source is
> being built for all multilibs. 

AFAICT from a quick check, the only *-rtems* target with this behavior 
is the h8300-rtems*:

h8300-rtems4.11/h8300s/config.h:#define SIZEOF_INT 2
h8300-rtems4.11/h8300s/config.h:#define SIZEOF_LONG 4
h8300-rtems4.11/h8300s/int32/config.h:#define SIZEOF_INT 4
h8300-rtems4.11/h8300s/int32/config.h:#define SIZEOF_LONG 4
h8300-rtems4.11/h8300s/int32/config.log:#define SIZEOF_INT 4
h8300-rtems4.11/h8300s/int32/config.log:#define SIZEOF_LONG 4
h8300-rtems4.11/h8300s/config.log:#define SIZEOF_INT 2
h8300-rtems4.11/h8300s/config.log:#define SIZEOF_LONG 4
h8300-rtems4.11/config.h:#define SIZEOF_INT 2
h8300-rtems4.11/config.h:#define SIZEOF_LONG 4
h8300-rtems4.11/config.log:#define SIZEOF_INT 2
h8300-rtems4.11/config.log:#define SIZEOF_LONG 4
h8300-rtems4.11/h8sx/config.h:#define SIZEOF_INT 2
h8300-rtems4.11/h8sx/config.h:#define SIZEOF_LONG 4
h8300-rtems4.11/h8sx/int32/config.h:#define SIZEOF_INT 4
h8300-rtems4.11/h8sx/int32/config.h:#define SIZEOF_LONG 4
h8300-rtems4.11/h8sx/int32/config.log:#define SIZEOF_INT 4
h8300-rtems4.11/h8sx/int32/config.log:#define SIZEOF_LONG 4
h8300-rtems4.11/h8sx/config.log:#define SIZEOF_INT 2
h8300-rtems4.11/h8sx/config.log:#define SIZEOF_LONG 4
h8300-rtems4.11/h8300h/config.h:#define SIZEOF_INT 2
h8300-rtems4.11/h8300h/config.h:#define SIZEOF_LONG 4
h8300-rtems4.11/h8300h/int32/config.h:#define SIZEOF_INT 4
h8300-rtems4.11/h8300h/int32/config.h:#define SIZEOF_LONG 4
h8300-rtems4.11/h8300h/int32/config.log:#define SIZEOF_INT 4
h8300-rtems4.11/h8300h/int32/config.log:#define SIZEOF_LONG 4
h8300-rtems4.11/h8300h/config.log:#define SIZEOF_INT 2
h8300-rtems4.11/h8300h/config.log:#define SIZEOF_LONG 4

Note: sizeof(int) varies between multilib-variants.

Ralf