https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #18 from Georg-Johann Lay ---
(In reply to Francois-Xavier Coudert from comment #11)
> As far as I can say, the targets with this problem are: avr, bfin, h8300,
> picochip and sh (for some subtargets of sh).
>
> On avr, bfin, h8300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #17 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #16 from Joel Sherrill ---
I assume this ICE during a build of bfin-rtems on the master is indicative of
the same underlying problem. I have reported this before on the sh2e but didn't
know of this PR.
libtool: compile:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #15 from Oleg Endo ---
(In reply to Oleg Endo from comment #14)
>
> This switch is already there: -fshort-double
... and it seems it's been causing trouble and is going to be removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #14 from Oleg Endo ---
(In reply to Oleg Endo from comment #13)
>
> I think it would be easier to leave DOUBLE_TYPE_SIZE == 64 in all cases and
> use software fp if the hardware can't do double precision. If users insist
> on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Francois-Xavier Coudert from comment #11)
As far as I can say, the targets with this problem are: avr, bfin, h8300,
picochip and sh (for some subtargets of sh).
On
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
CC||olegendo at
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2009-05-05 08:18
---
As far as I can say, the targets with this problem are: avr, bfin, h8300,
picochip and sh (for some subtargets of sh).
On avr, bfin, h8300 and picochip, we're doomed anyway because there is no
double-sized type
