[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[gjl at gcc dot gnu.org via Gcc-bugs]

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 and picochip, we're doomed anyway because there is no
> double-sized type at all. On sh, we could use long double math calls.
> 
> I'm making this into an enhancement; it will probably be very painful,
> because most of the front-end assumes FLOAT_TYPE_SIZE == 32 and
> DOUBLE_TYPE_SIZE == 64.

At least for AVR, the situation changed with v10, see
https://gcc.gnu.org/gcc-10/changes.html#avr
https://gcc.gnu.org/install/configure.html#avr

In order to keep v10 compatible with older versions of avr-gcc, double still
defaults to 32 bits, though.  To get 64-bit double, you'll have to configure
using --with-double=64 (or use --with-double=64,32 so you can which to 32-bit
double with -mdouble=32 at compile-time).

The default for this option is --with-double=32,64; hence what's also possible
is to use default configuraton, but provide -mdouble=64 for every translation
unit.

FYI, the 64-bit double support is provided by LibF7, which is a part of
avr-libgcc.  For details and shortcomings, see
https://gcc.gnu.org/wiki/avr-gcc#Libf7
https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libgcc/config/avr/libf7

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[dominiq at lps dot ens.fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #17 from Dominique d'Humieres  ---
Target issue?

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[joel at gcc dot gnu.org]

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:  /home/joel/test-gcc/b-bfin-rtems5-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-bfin-rtems5-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-bfin-rtems5-gcc/bfin-rtems5/newlib/ -isystem
/home/joel/test-gcc/b-bfin-rtems5-gcc/bfin-rtems5/newlib/targ-include -isystem
/home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/bfin-rtems5/bin/
-B/home/joel/test-gcc/install-master/bfin-rtems5/lib/ -isystem
/home/joel/test-gcc/install-master/bfin-rtems5/include -isystem
/home/joel/test-gcc/install-master/bfin-rtems5/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc/libgfortran -iquote../../../gcc/libgfortran/io
-I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config
-I../.././gcc -I../../../gcc/libgfortran/../libgcc -I../libgcc
-I../../../gcc/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace
-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT sum_c8.lo -MD -MP -MF
.deps/sum_c8.Tpo -c ../../../gcc/libgfortran/generated/sum_c8.c -o sum_c8.o
during RTL pass: reload
../../../gcc/libgfortran/generated/sum_c8.c: In function 'sum_c8':
../../../gcc/libgfortran/generated/sum_c8.c:191:1: internal compiler error: in
require, at machmode.h:282
 }
 ^
0x59f58c opt_mode::require() const
../../gcc/gcc/machmode.h:282
0x59f58c replace_reg_with_saved_mem
../../gcc/gcc/caller-save.c:1151
0x5a00c6 mark_referenced_regs
../../gcc/gcc/caller-save.c:1073
0x5a00c6 mark_referenced_regs
../../gcc/gcc/caller-save.c:1073
0x5a1105 save_call_clobbered_regs()
../../gcc/gcc/caller-save.c:895
0x9ba530 reload(rtx_insn*, int)
../../gcc/gcc/reload1.c:980
0x8540ce do_reload
../../gcc/gcc/ira.c:5458
0x8540ce execute
../../gcc/gcc/ira.c:5630
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [sum_c8.lo] Error 1

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[olegendo at gcc dot gnu.org]

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/ml/gcc-patches/2014-09/msg02464.html

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[olegendo at gcc dot gnu.org]

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 doubles being automatically truncated to floats then there should be a
> compiler switch for that.

This switch is already there: -fshort-double

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[olegendo at gcc dot gnu.org]

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 avr, bfin, h8300 and picochip, we're doomed anyway because there is no
 double-sized type at all. On sh, we could use long double math calls.
 
 I'm making this into an enhancement; it will probably be very painful,
 because most of the front-end assumes FLOAT_TYPE_SIZE == 32 and
 DOUBLE_TYPE_SIZE == 64.

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
doubles being automatically truncated to floats then there should be a compiler
switch for that.  E.g. on SH we have -m4-single-only option to control this. 
On SH2E code would then use hardware fp for floats and software fp for doubles
by default.

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[kkojima at gcc dot gnu.org]

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 gcc dot gnu.org

--- Comment #12 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-08 
22:15:33 UTC ---
*** Bug 52535 has been marked as a duplicate of this bug. ***

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[fxcoudert at gcc dot gnu dot org]

--- 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 at all. On sh, we could use long double math calls.

I'm making this into an enhancement; it will probably be very painful, because
most of the front-end assumes FLOAT_TYPE_SIZE == 32 and DOUBLE_TYPE_SIZE == 64.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
 GCC target triplet|sh-unknown-elf  |sh, avr, bfin, h8300,
   ||picochip
   Priority|P3  |P5
   Last reconfirmed|2007-11-16 23:42:54 |2009-05-05 08:18:07
   date||
Summary|relation between kinds and C|Support for DOUBLE_TYPE_SIZE
   |types (for math builtins)   |!= 64 targets
   |shouldn't be hardcoded  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040