[Bug fortran/33062] New: ICE in emit_move_insn and expand_call with -fdefault-integer-8

[Bug fortran/33062] New: ICE in emit_move_insn and expand_call with -fdefault-integer-8

[michael dot a dot richmond at nasa dot gov]

gfortran produces an internal compiler error under the following conditions:

1. A logical function is being evaluated
2. The flag "-f-default-integer-8" is specified
3. The August 10 snapshot versions of gcc and gfortran are compiled under
HP-PA. I have not tested this snapshot with other architectures, nor have I
tested the HP-PA architecture with other versions of gcc.

Listed below are two examples:

LOGICAL FUNCTION x()
x = .FALSE.
END FUNCTION x

a.f90: In function 'x':
a.f90:1: internal compiler error: in emit_move_insn, at expr.c:3316
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

PROGRAM axis
LOGICAL :: x, y
y = x()
END PROGRAM axis

x.f90: In function 'MAIN__':
x.f90:3: internal compiler error: in expand_call, at calls.c:3022
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 
           Summary: ICE in emit_move_insn and expand_call with -fdefault-
                    integer-8
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug fortran/33062] ICE in emit_move_insn and expand_call with -fdefault-integer-8

[michael dot a dot richmond at nasa dot gov]

------- Comment #1 from michael dot a dot richmond at nasa dot gov  2007-08-13 16:36 -------
This bug does not exist in the i386 version of gfortran


-- 


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

[Bug fortran/33062] ICE in emit_move_insn and expand_call with -fdefault-integer-8

[fxcoudert at gcc dot gnu dot org]

------- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-08-14 14:28 -------
I'll try to deal with that one, it looks nasty (although target-specific).
Thanks for the bug-report.

  1. Can you report what HP-PA architecture this is happening on? And the OS?
(I have access to HP testdrive, if need arise I can try it there once I know
the answer to these questions.)

  2. It may or may not be of help, but I should note that there was a powerpc
back-end bug at some point that this behaviour: PR30406. Can you try compiling
the following code, without -fdefault-integer-8 (and, in case it does not fail,
with -fdefault-integer-8)?

    function f(l)
    logical(8) :: f
    logical(8) :: l
    f = .not.l
    end function f


  3. Actually, thinking about it more, the code in gcc/config/pa/pa.c looks
close to that in gcc/config/rs6000/rs6000.c where the problem was fixed. Could
you also try the following patch?

Index: gcc/config/pa/pa.c
===================================================================
--- gcc/config/pa/pa.c  (revision 127394)
+++ gcc/config/pa/pa.c  (working copy)
@@ -9075,7 +9075,7 @@ function_value (tree valtype, tree func
     }

   if ((INTEGRAL_TYPE_P (valtype)
-       && TYPE_PRECISION (valtype) < BITS_PER_WORD)
+       && GET_MODE_BITSIZE (TYPE_MODE (valtype)) < BITS_PER_WORD)
       || POINTER_TYPE_P (valtype))
     valmode = word_mode;
   else


  4. Do you have testresults on this platform, and does
gfortran.dg/logical_3.f90 PASS?


-- 

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|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-08-14 14:28:08
               date|                            |


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

[Bug fortran/33062] ICE in emit_move_insn and expand_call with -fdefault-integer-8

[michael dot a dot richmond at nasa dot gov]

------- Comment #3 from michael dot a dot richmond at nasa dot gov  2007-08-14 14:48 -------
I have an HP MODEL 9000/778/B180L. It uses a PA-RISC 1.1 processor. The OS is
Debian Linux 3.1.

I will try your patch.


-- 


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

[Bug fortran/33062] ICE in emit_move_insn and expand_call with -fdefault-integer-8

[michael dot a dot richmond at nasa dot gov]

------- Comment #4 from michael dot a dot richmond at nasa dot gov  2007-08-14 16:07 -------
Your patch fixed my test cases.

I do not have testresults on my HP workstation. I will try to find a copy of
gfortran.dg/logical_3.f90 and test it.


-- 


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

[Bug fortran/33062] ICE in emit_move_insn and expand_call with -fdefault-integer-8

[michael dot a dot richmond at nasa dot gov]

------- Comment #5 from michael dot a dot richmond at nasa dot gov  2007-08-14 16:16 -------
gfortran.dg/logical_3.f90 compiles without error


-- 


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

[Bug target/33062] ICE in emit_move_insn and expand_call with -fdefault-integer-8

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-08-14 21:14 -------
(In reply to comment #4)
> Your patch fixed my test cases.
> 
> I do not have testresults on my HP workstation. I will try to find a copy of
> gfortran.dg/logical_3.f90 and test it.

OK, so I'm CCing the hppa maintainers, Jeff Law and Dave Anglin, so that they
can review the problem and my proposed patch.

Jeff, Dave, as you can see in the above comments, I proposed this patch based
on a previous similar patch to powerpc, but I actually cannot judge its merit
as I know nothing of hppa. Would you please review it or suggest a more
appropriate fix?


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu dot
                   |                            |org, fxcoudert at gcc dot
                   |                            |gnu dot org, law at gcc dot
                   |                            |gnu dot org
         AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW
          Component|fortran                     |target
  GCC build triplet|                            |hppa-unknown-linux-gnu
   GCC host triplet|                            |hppa-unknown-linux-gnu
 GCC target triplet|                            |hppa-unknown-linux-gnu
           Keywords|                            |ice-on-valid-code, patch
      Known to fail|                            |4.3.0


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

[Bug target/33062] ICE in emit_move_insn and expand_call with -fdefault-integer-8

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2007-08-19 01:11 -------
Subject: Re:  ICE in emit_move_insn and expand_call with -fdefault-integer-8

> Jeff, Dave, as you can see in the above comments, I proposed this patch based
> on a previous similar patch to powerpc, but I actually cannot judge its merit
> as I know nothing of hppa. Would you please review it or suggest a more
> appropriate fix?

Based on comment #22 in PR 30406, I think the suggested change is correct.
However, this is old code and I don't understand the following:

1) The actual cause of the ICE.
2) The difference between precision and type bitsize in this situation.

We have to decide if the return value should be promoted to 32 bits,
64 bits or returned indirectly.  The runtime documentation isn't very
specific when it comes to fortran data types.

Dave


-- 


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

[Bug target/33062] ICE in emit_move_insn and expand_call with -fdefault-integer-8

[fxcoudert at gcc dot gnu dot org]

------- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-08-20 10:20 -------
(In reply to comment #7)
> 1) The actual cause of the ICE.

That point is unfortunately beyond my understanding.

> 2) The difference between precision and type bitsize in this situation.
> 
> We have to decide if the return value should be promoted to 32 bits,
> 64 bits or returned indirectly.  The runtime documentation isn't very
> specific when it comes to fortran data types.

The issue is with a logical type that has 64 bits size, but only limited
precision, being only a logical type (AFAIU). The Fortran rules, however, are
that it should be be passed in the exact same way as the integer kind of the
same bit size. That is why, I think, making the decision on bitsize is the
right thing to do: it doesn't change anything for integer types, but it does
for Fortran logical types.

Please let me know if you need more information about the Fortran side of the
problem.


-- 


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

[Bug target/33062] ICE in emit_move_insn and expand_call with -fdefault-integer-8

[danglin at gcc dot gnu dot org]

------- Comment #9 from danglin at gcc dot gnu dot org  2007-09-15 19:31 -------
Subject: Bug 33062

Author: danglin
Date: Sat Sep 15 19:30:50 2007
New Revision: 128516

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128516
Log:
        PR target/33062
        * pa.c (function_value): Use GET_MODE_BITSIZE instead of
TYPE_PRECISION.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/pa/pa.c


-- 


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

[Bug target/33062] ICE in emit_move_insn and expand_call with -fdefault-integer-8

[danglin at gcc dot gnu dot org]

------- Comment #10 from danglin at gcc dot gnu dot org  2007-09-15 19:44 -------
Fixed by change.


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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