[Bug fortran/53732] New: "mismatching comparison operand types" on compile

[Bug fortran/53732] New: "mismatching comparison operand types" on compile

[minzastro at yandex dot ru]

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

             Bug #: 53732
           Summary: "mismatching comparison operand types" on compile
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: minzastro@yandex.ru


I have problems compiling my code on minGW gfortran 4.7.
This code does not compile:

program test
implicit none

real*8 arr(4, 4, 4, 4)

arr(:,:,:,:) = 1d0

arr(1, :, :, = sum(arr, dim=1, mask=(arr(:,:,:,:) > 0d0))

end program test

$gfortran test.f90
I get:
test.f90:1:0: ошибка: mismatching comparison operand types
real(kind=8)
integer(kind=4)
if (D.1895 > 0) goto <D.1896>; else goto <D.1897>;

(gfortran --version:
GNU Fortran (GCC) 4.7.0
Copyright (C) 2012 Free Software Foundation, Inc.)

There was also a report of the same problem with Mac OS X, version 10.7.4
(Lion)
and GNU Fortran (GCC) 4.8.0 20120603 (experimental)
Both Linux gfortran 4.7 & windows g95 are working ok.

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-06-20
                 CC|                            |mikael at gcc dot gnu.org
            Summary|"mismatching comparison     |[4.7/4.8 Regression]
                   |operand types" on compile   |"mismatching comparison
                   |                            |operand types" on compile
     Ever Confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-06-20 15:02:48 UTC ---
Revision 180652 (2011-10-29) is OK,
revision 180989 (2011-11-04) yields the ICE. Likely one of the many Mikael
Morin's patches that took place between 2011-11-03 and 2011-11-04.

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code,
                   |                            |wrong-code
                 CC|                            |burnus at gcc dot gnu.org
   Target Milestone|---                         |4.7.2

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-20 16:40:05 UTC ---
The problem is the following code in trans-array.c's gfc_add_loop_ss_code:

      switch (ss_info->type)
        {
        case GFC_SS_SCALAR:
...
          gfc_conv_expr (&se, expr);

Here, expr is "0.0d0", which is properly converted. However:

          if (expr->ts.type != BT_CHARACTER)
            {
              /* Move the evaluation of scalar expressions outside the
                 scalarization loop, except for WHERE assignments.  */
              if (subscript)
                se.expr = convert(gfc_array_index_type, se.expr);

As subscript is true, the "0.0d0" gets converted to the integer "0".

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-20 17:19:39 UTC ---
Looking a bit deeper at the issue, the conditional code makes sense, but it
does not make sense that "subscript" is true. The code seems to get set via an
(earlier) call to gfc_add_loop_ss_code which calls for expr == "arr":

        case GFC_SS_SECTION:
          /* Add the expressions for scalar and vector subscripts.  */
          for (n = 0; n < GFC_MAX_DIMENSIONS; n++)
            if (info->subscript[n])
              {
                gfc_add_loop_ss_code (loop, info->subscript[n], true, where);

That call properly setups everything for a GFC_SS_SCALAR, where the argument is
an integer(8) constant of value 1. I assume that part is okay. It then jumps to
the end of the function which contains:

  if (!skip_nested)
    for (nested_loop = loop->nested; nested_loop;
         nested_loop = nested_loop->next)
      gfc_add_loop_ss_code (nested_loop, nested_loop->ss, subscript, where);

That's the call which goes wrong as ss->info->expr is the 0.0d0 while the
"subcript == true" is passed on, which causes the problem ...


The two quoted code snippets have been added by Mikael in Rev. 180898
(2011-11-03), http://gcc.gnu.org/viewcvs?view=revision&revision=180898

    * trans-array.c (gfc_add_loop_ss_code): Skip non-nestedmost ss.
    Call recursively gfc_add_loop_ss_code for all the nested loops.
    (gfc_conv_ss_startstride): Only get the descriptor for the outermost
    ss. Call recursively gfc_conv_ss_startstride for all the nested loops.
    (set_loop_bounds): Call recursively for all the nested loops.
    (set_delta): Ditto.

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[mikael at gcc dot gnu.org]

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

--- Comment #4 from Mikael Morin <mikael at gcc dot gnu.org> 2012-06-20 20:41:24 UTC ---
(In reply to comment #3)

It seems you have pinpointed it.
Unfortunately, my computer is broken at the moment, so that I have no way to
test myself, let alone propose a patch.
The purpose of my change was to call gfc_add_loop_ss_code on the nested loop
(the sum one) exactly once. But I didn't think that the nested call could have
the wrong subscript flag.
I will think about the best way to tackle the problem. Maybe we could just
disable the nested call if subscript is true.

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[mikael at gcc dot gnu.org]

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

--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> 2012-06-21 12:48:51 UTC ---
Created attachment 27686
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27686
"shot in the dark" patch[*]

[*] Carefully crafted with love and patience, using the ancestral methods and
tools available to the windows users (i.e. Notepad.exe).
In other words, the patch may not apply cleanly.

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-06-21 15:07:58 UTC ---
> [*] Carefully crafted with love and patience, using the ancestral methods and
> tools available to the windows users (i.e. Notepad.exe).
> In other words, the patch may not apply cleanly.

Well, it did!-) The patch even fixed the PR (no regression with -m32, further
testing in progress).

I wonder if 

-  if (!skip_nested)
+  if (!subscript && !skip_nested)

would not be enough?

Note that there is a temporary that is not needed if I am not mistaken:

[macbook] f90/bug% gfc pr53732.f90 -Warray-temporaries
pr53732.f90:8.18:

arr(1, :, :, :) = sum(arr, dim=1, mask=(arr(:,:,:,:) > 0d0))
                  1
Warning: Creating array temporary at (1)

a(k)=sum(a) can be scalarized as

do i=lb,ub
if (i /= k) a(k) = a(k)+a(i)
end do

Thanks for the quick patch.

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-06-21 20:32:48 UTC ---
> Well, it did!-) The patch even fixed the PR (no regression with -m32, further
> testing in progress).

Testing finished without anything to report.

> I wonder if 
>
> -  if (!skip_nested)
> +  if (!subscript && !skip_nested)
>
> would not be enough?

Forget it! It does not work.

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #8 from Mikael Morin <mikael at gcc dot gnu.org> 2012-06-22 11:24:04 UTC ---
(In reply to comment #7)
> > Well, it did!-) The patch even fixed the PR (no regression with -m32, further
> > testing in progress).
> 
> Testing finished without anything to report.
> 
Thanks for testing Dominique.
I'll come back to it next Monday or so.

Alexey, if this bug is annoying to you, you can probably circumvent it by
replacing "dim=one" for "dim=1" in the sum call, where "one" is a variable of
value 1.

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[mikael at gcc dot gnu.org]

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

--- Comment #9 from Mikael Morin <mikael at gcc dot gnu.org> 2012-07-05 15:18:30 UTC ---
Author: mikael
Date: Thu Jul  5 15:18:26 2012
New Revision: 189292

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189292
Log:
fortran/
    PR fortran/53732
    * trans-array.c (gfc_add_loop_ss_code): Disable self recursive calls
    handling nested loop(s) if the subscript flag is true.

testsuite/
    PR fortran/53732
    * gfortran.dg/inline_sum_4.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/inline_sum_4.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[mikael at gcc dot gnu.org]

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

--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> 2012-07-06 19:51:18 UTC ---
Author: mikael
Date: Fri Jul  6 19:51:15 2012
New Revision: 189341

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189341
Log:
fortran/
    PR fortran/53732
    * trans-array.c (gfc_add_loop_ss_code): Disable self recursive calls
    handling nested loop(s) if the subscript flag is true.

testsuite/
    PR fortran/53732
    * gfortran.dg/inline_sum_4.f90: New test.


Added:
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/inline_sum_4.f90
Modified:
    branches/gcc-4_7-branch/gcc/fortran/ChangeLog
    branches/gcc-4_7-branch/gcc/fortran/trans-array.c
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

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

--- Comment #11 from Mikael Morin <mikael at gcc dot gnu.org> 2012-07-06 19:54:19 UTC ---
Fixed on the trunk (4.8.0) and the 4.7 branch (4.7.2).

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pmarguinaud at hotmail dot
                   |                            |com

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-12-18 16:39:51 UTC ---
*** Bug 55729 has been marked as a duplicate of this bug. ***