User account creation filtered due to spam.

Bug 34040 - Support for DOUBLE_TYPE_SIZE != 64 targets
Summary: Support for DOUBLE_TYPE_SIZE != 64 targets
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P5 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: build, ice-on-valid-code
: 52535 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-09 10:42 UTC by Rask Ingemann Lambertsen
Modified: 2016-02-08 12:13 UTC (History)
8 users (show)

See Also:
Host:
Target: sh, avr, bfin, h8300, picochip
Build:
Known to work:
Known to fail: 4.3.0
Last reconfirmed: 2009-05-05 08:18:07


Attachments
test case (972 bytes, text/plain)
2007-11-09 10:45 UTC, Rask Ingemann Lambertsen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rask Ingemann Lambertsen 2007-11-09 10:42:06 UTC
Build failure in libgfortran with revision 129967 (128328 worked):

/home/rask/build/gcc-sh-unknown-elf/./gcc/gfortran -B/home/rask/build/gcc-sh-unknown-elf/./gcc/ -nostdinc -B/home/rask/build/gcc-sh-unknown-elf/sh-unknown-elf/m2e/newlib/ -isystem /home/rask/build/gcc-sh-unknown-elf/sh-unknown-elf/m2e/newlib/targ-include -isystem /n/12/rask/src/all/newlib/libc/include -B/usr/local/sh-unknown-elf/bin/ -B/usr/local/sh-unknown-elf/lib/ -isystem /usr/local/sh-unknown-elf/include -isystem /usr/local/sh-unknown-elf/sys-include -L/home/rask/build/gcc-sh-unknown-elf/./ld -m2e -DHAVE_CONFIG_H -I. -I/n/12/rask/src/all/libgfortran -I. -iquote/n/12/rask/src/all/libgfortran/io -I/n/12/rask/src/all/libgfortran/../gcc -I/n/12/rask/src/all/libgfortran/../gcc/config -I../../.././gcc -D_GNU_SOURCE -I . -Wall -fno-repack-arrays -fno-underscoring -fallow-leading-underscore -g -O2 -m2e -c /n/12/rask/src/all/libgfortran/generated/_sign_r8.F90 -o _sign_r8.o
/n/12/rask/src/all/libgfortran/generated/_sign_r8.F90: In function '_gfortran_specific__sign_r8':
/n/12/rask/src/all/libgfortran/generated/_sign_r8.F90:46: internal compiler error: in simplify_subreg, at simplify-rtx.c:4921

(gdb) call debug_rtx (target)
(reg:SF 159 [ D.489 ])
(gdb) frame 6
#6  0x000000000069c488 in expand_copysign (op0=0x2ae08e34bba0, op1=0x2ae08e34ba80, target=0x1ffffffff) at /n/12/rask/src/all/gcc/optabs.c:3621
3621              rtx targ_piece = operand_subword (target, i, 1, mode);
(gdb) call debug_rtx (op0)
(mem:DF (reg/v/f:SI 161 [ p1 ]) [2 (* p1) S8 A32])
(gdb) call debug_rtx (op1)
(mem:DF (reg/v/f:SI 162 [ p2 ]) [2 (* p2) S8 A32])
(gdb) print mode
$4 = DFmode

Notice the mismatching modes: mode = DFmode with SFmode target.

(gdb) frame 4
#4  0x000000000076a6c9 in simplify_subreg (outermode=SImode, op=0x2ae08e34dfa0, innermode=DFmode, byte=0) at /n/12/rask/src/all/gcc/simplify-rtx.c:4920
4920      gcc_assert (GET_MODE (op) == innermode
(gdb) call debug_rtx(op)
(reg:SF 159 [ D.489 ])

Command line:
./gcc/f951 _sign_r8.f95 -ffree-form -quiet -dumpbase _sign_r8.F90 -m2e -m2e -auxbase-strip _sign_r8.o -g -O2 -Wall -fno-repack-arrays -fno-underscoring -fallow-leading-underscore -I. -I/n/12/rask/src/all/libgfortran -I. -I/n/12/rask/src/all/libgfortran/../gcc -I/n/12/rask/src/all/libgfortran/../gcc/config -I../../.././gcc -I . -fpreprocessed -o /dev/null

Configure flags:
--target sh-unknown-elf --enable-checking=yes,rtl --with-newlib --enable-sim --disable-gdb --disable-nls
Comment 1 Rask Ingemann Lambertsen 2007-11-09 10:45:24 UTC
Created attachment 14513 [details]
test case
Comment 2 Eric Botcazou 2007-11-12 19:21:33 UTC
Confirmed with "-fallow-leading-underscore -O2 -m2e".
Comment 3 Eric Botcazou 2007-11-12 19:21:48 UTC
Investigating.
Comment 4 Eric Botcazou 2007-11-12 21:06:17 UTC
Nothing to do with optimization, it's a Fortran front-end problem:

(gdb) p debug_tree(from)
 <call_expr 0x2a95a3a060
    type <real_type 0x2a959ec680 SF
        size <integer_cst 0x2a959cd8d0 constant invariant 32>
        unit size <integer_cst 0x2a959cd540 constant invariant 4>
        align 32 symtab 0 alias set -1 canonical type 0x2a959ec680 precision 32
        pointer_to_this <pointer_type 0x2a959ec8f0>>

    fn <addr_expr 0x2a9556d300
        type <pointer_type 0x2a95a36a90 type <function_type 0x2a95a01a90>
            unsigned SI size <integer_cst 0x2a959cd8d0 32> unit size <integer_cst 0x2a959cd540 4>
            align 32 symtab 0 alias set -1 canonical type 0x2a95a36a90>
        readonly constant invariant
        arg 0 <function_decl 0x2a95a11700 __builtin_copysign type <function_type 0x2a95a01a90>
            readonly public external built-in SI file pr34040.f95 line 0
            align 16 built-in BUILT_IN_NORMAL:BUILT_IN_COPYSIGN
            (mem:SI (symbol_ref:SI ("copysign") [flags 0x41] <function_decl 0x2a95a11700 __builtin_copysign>) [0 S4 A32]) chain <function_decl 0x2a95a11600 __builtin_copysignl>>>
    arg 0 <indirect_ref 0x2a9556d200
        type <real_type 0x2a959ec750 real8 DF
            size <integer_cst 0x2a959cda80 constant invariant 64>
            unit size <integer_cst 0x2a959cdab0 constant invariant 8>
            align 32 symtab 0 alias set -1 canonical type 0x2a959ec750 precision 64
            pointer_to_this <pointer_type 0x2a959ec9c0> reference_to_this <reference_type 0x2a95a368f0>>

        arg 0 <parm_decl 0x2a959d2460 p1 type <reference_type 0x2a95a368f0>
            readonly used unsigned SI file pr34040.f95 line 1 size <integer_cst0x2a959cd8d0 32> unit size <integer_cst 0x2a959cd540 4>
            align 32 context <function_decl 0x2a95a37200 _gfortran_specific__sign_r8> initial <reference_type 0x2a95a368f0>
            (reg/v/f:SI 161 [ p1 ]) arg-type <reference_type 0x2a95a368f0>
            incoming-rtl (reg:SI 4 r4 [ p1 ]) chain <parm_decl 0x2a959d2500 p2>>>
    arg 1 <indirect_ref 0x2a9556d280 type <real_type 0x2a959ec750 real8>

        arg 0 <parm_decl 0x2a959d2500 p2 type <reference_type 0x2a95a368f0>
            readonly used unsigned SI file pr34040.f95 line 1 size <integer_cst0x2a959cd8d0 32> unit size <integer_cst 0x2a959cd540 4>
            align 32 context <function_decl 0x2a95a37200 _gfortran_specific__sign_r8> initial <reference_type 0x2a95a368f0>
            (reg/v/f:SI 162 [ p2 ]) arg-type <reference_type 0x2a95a368f0>
            incoming-rtl (reg:SI 5 r5 [ p2 ])>>
    pr34040.f95:4>

__builtin_copysign has got SFmode(*)(SFmode, SFmode) prototype and is invoked
on DFmode arguments.
Comment 5 Francois-Xavier Coudert 2007-11-13 12:28:38 UTC
(In reply to comment #4)
> __builtin_copysign has got SFmode(*)(SFmode, SFmode) prototype and is invoked
> on DFmode arguments.

copysign takes doubles and returns a double. Does the SH double have SF mode in the conditions of this PR? It is assumed, throughout the Fortran front-end, that SF mode corresponds to float, and DF corresponds to double. (This will be changed for 4.4, but not before... it's a most significant reworking.)
Comment 6 Kazumoto Kojima 2007-11-14 04:02:00 UTC
(In reply to comment #5)

> copysign takes doubles and returns a double. Does the SH double have SF mode in
> the conditions of this PR?

Yes.  When -m2e is specified on SH, DOUBLE_TYPE_SIZE is set to
32 and double_type_node has the SF type.
Perhaps all targets which set DOUBLE_TYPE_SIZE to other than 64
might have the same issue.

Comment 7 Francois-Xavier Coudert 2007-11-16 23:42:54 UTC
(In reply to comment #6)
> Yes.  When -m2e is specified on SH, DOUBLE_TYPE_SIZE is set to
> 32 and double_type_node has the SF type.
> Perhaps all targets which set DOUBLE_TYPE_SIZE to other than 64
> might have the same issue.

Certainly. I'm very surprised that we've never seen this before. I'm not sure a patch that large would be suitable at that stage, I'll ask the other maintainers. In any case, I think we should at least refuse to compile in that case, rather than emit code that's possibly wrong.
Comment 8 Francois-Xavier Coudert 2007-11-17 17:10:11 UTC
First, a question: what are the math functions that should be used for DFmode on sh with -m2e? For example, what function should we use for copysign(DFmode, DFmode): is that copysignl?  

After talking about it on IRC...
  - this is a 4.3 regression, but the underlying problem is present since gfortran was created
  - targets with DOUBLE_TYPE_SIZE != 64 aren't so common
  - even if we fix the front-end issue, we might have plenty of failures in the testsuite because the testsuite widely uses 64-bit floating-points types, for which we might not have math functions...
Comment 9 Kazumoto Kojima 2007-11-18 10:27:00 UTC
> is that copysignl? 

Since the size of long double is 8 for -m2e, copysignl would be.

I think that fortran has no real use on such "short double"
targets, though.  I'm inclined to make fortran unsupported
for SH targets like sh-elf.
Comment 10 Daniel Franke 2009-04-10 20:44:07 UTC
Is this still valid?
Is there a relation to PR21203?
Comment 11 Francois-Xavier Coudert 2009-05-05 08:18:07 UTC
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.
Comment 12 Kazumoto Kojima 2012-03-08 22:15:33 UTC
*** Bug 52535 has been marked as a duplicate of this bug. ***
Comment 13 Oleg Endo 2013-12-05 19:39:13 UTC
(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.
Comment 14 Oleg Endo 2015-09-05 04:05:14 UTC
(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
Comment 15 Oleg Endo 2016-02-08 12:13:30 UTC
(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