[Bug middle-end/34040] New: [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[Bug middle-end/34040] New: [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[rask at gcc dot gnu dot org]

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


-- 
           Summary: [4.3 Regression] ICE: in simplify_subreg, at simplify-
                    rtx.c:4921 building libgfortran
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code, build
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rask at gcc dot gnu dot org
GCC target triplet: sh-unknown-elf


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

[Bug middle-end/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[rask at gcc dot gnu dot org]

------- Comment #1 from rask at gcc dot gnu dot org  2007-11-09 10:45 -------
Created an attachment (id=14513)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14513&action=view)
test case


-- 


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

[Bug rtl-optimization/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
          Component|middle-end                  |rtl-optimization
   Target Milestone|---                         |4.3.0


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

[Bug rtl-optimization/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[ebotcazou at gcc dot gnu dot org]

------- Comment #3 from ebotcazou at gcc dot gnu dot org  2007-11-12 19:21 -------
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-11-12 19:21:33         |2007-11-12 19:21:48
               date|                            |


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

[Bug rtl-optimization/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[ebotcazou at gcc dot gnu dot org]

------- Comment #2 from ebotcazou at gcc dot gnu dot org  2007-11-12 19:21 -------
Confirmed with "-fallow-leading-underscore -O2 -m2e".


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-11-12 19:21:33
               date|                            |


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

[Bug fortran/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[ebotcazou at gcc dot gnu dot org]

------- Comment #4 from ebotcazou at gcc dot gnu dot org  2007-11-12 21:06 -------
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.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW
          Component|rtl-optimization            |fortran


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

[Bug fortran/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[fxcoudert at gcc dot gnu dot org]

------- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-11-13 12:28 -------
(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.)


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[kkojima at gcc dot gnu dot org]

------- Comment #6 from kkojima at gcc dot gnu dot org  2007-11-14 04:02 -------
(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.


-- 

kkojima at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kkojima at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[fxcoudert at gcc dot gnu dot org]

------- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-11-16 23:42 -------
(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.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-11-12 19:21:48         |2007-11-16 23:42:54
               date|                            |


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

[Bug fortran/34040] relation between kinds and C types (for math builtins) shouldn't be hardcoded

[fxcoudert at gcc dot gnu dot org]

------- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-11-17 17:10 -------
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...


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.3 Regression] ICE: in    |relation between kinds and C
                   |simplify_subreg, at         |types (for math builtins)
                   |simplify-rtx.c:4921 building|shouldn't be hardcoded
                   |libgfortran                 |
   Target Milestone|4.3.0                       |4.4.0


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

[Bug fortran/34040] relation between kinds and C types (for math builtins) shouldn't be hardcoded

[kkojima at gcc dot gnu dot org]

------- Comment #9 from kkojima at gcc dot gnu dot org  2007-11-18 10:27 -------
> 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.


-- 


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

[Bug fortran/34040] relation between kinds and C types (for math builtins) shouldn't be hardcoded

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.0                       |---


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

[Bug fortran/34040] relation between kinds and C types (for math builtins) shouldn't be hardcoded

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug fortran/34040] relation between kinds and C types (for math builtins) shouldn't be hardcoded

[dfranke at gcc dot gnu dot org]

------- Comment #10 from dfranke at gcc dot gnu dot org  2009-04-10 20:44 -------
Is this still valid?
Is there a relation to PR21203?


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


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

[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