* Re: [Bug ada/36939] Build Failure Ada SH2e
[not found] ` <20110207090408.GB75472@adacore.com>
@ 2011-02-07 18:32 ` Laurent GUERBY
2011-02-07 21:33 ` Arnaud Charlet
0 siblings, 1 reply; 4+ messages in thread
From: Laurent GUERBY @ 2011-02-07 18:32 UTC (permalink / raw)
To: Arnaud Charlet; +Cc: Joel Sherrill, gcc-patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bug ada/36939] Build Failure Ada SH2e
2011-02-07 18:32 ` [Bug ada/36939] Build Failure Ada SH2e Laurent GUERBY
@ 2011-02-07 21:33 ` Arnaud Charlet
2011-02-07 21:56 ` Joel Sherrill
0 siblings, 1 reply; 4+ messages in thread
From: Arnaud Charlet @ 2011-02-07 21:33 UTC (permalink / raw)
To: Laurent GUERBY; +Cc: Joel Sherrill, gcc-patches
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bug ada/36939] Build Failure Ada SH2e
2011-02-07 21:33 ` Arnaud Charlet
@ 2011-02-07 21:56 ` Joel Sherrill
2011-02-07 22:20 ` Ralf Corsepius
0 siblings, 1 reply; 4+ messages in thread
From: Joel Sherrill @ 2011-02-07 21:56 UTC (permalink / raw)
To: Arnaud Charlet; +Cc: Laurent GUERBY, gcc-patches, Ralf Corsepius
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bug ada/36939] Build Failure Ada SH2e
2011-02-07 21:56 ` Joel Sherrill
@ 2011-02-07 22:20 ` Ralf Corsepius
0 siblings, 0 replies; 4+ messages in thread
From: Ralf Corsepius @ 2011-02-07 22:20 UTC (permalink / raw)
To: Joel Sherrill; +Cc: Arnaud Charlet, Laurent GUERBY, gcc-patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-02-07 22:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-36939-4@http.gcc.gnu.org/bugzilla/>
[not found] ` <bug-36939-4-BH0KHwqDLZ@http.gcc.gnu.org/bugzilla/>
[not found] ` <20110207090408.GB75472@adacore.com>
2011-02-07 18:32 ` [Bug ada/36939] Build Failure Ada SH2e Laurent GUERBY
2011-02-07 21:33 ` Arnaud Charlet
2011-02-07 21:56 ` Joel Sherrill
2011-02-07 22:20 ` Ralf Corsepius
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).