[Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler

[Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler

[roger.ferrer at bsc dot es]

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

           Summary: Recursive functions of intrinsic names generates
                    invalid assembler
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: roger.ferrer@bsc.es


I know this is sort of a contrived case but seems that gfortran is getting
confused in this case leading to syntactically invalid assembler.

RECURSIVE FUNCTION MAX(A, B) RESULT(K)
  IF (B >= 0) THEN
         K = MAX(A+1, B-1)
  ELSE
     K = A
  END IF
END

$ gfortran -c test.f90 -save-temps
test.s:11: Error: junk at end of line, first unrecognized character is `('
test.s:12: Error: unrecognized symbol type ""
test.s:12: Error: junk at end of line, first unrecognized character is `('
test.s:13: Error: Unrecognized opcode: `__(intrinsic)__max:'
test.s:73: Error: expected comma after name `__' in .size directive
$ cat -n test.s 
  ...
    11        .globl __(intrinsic)__max
    12        .type    __(intrinsic)__max, @function
    13    __(intrinsic)__max:
  ...
    73        .size    __(intrinsic)__max,.-__(intrinsic)__max


My guess is that gfortran is picking the intrinsic 'max' function symbol
instead of the one being currently defined (which is recursive and thus is
eligible to be called in its same body, isn't it?)

I don't know how much conformant this is to Fortran standard but Intel Fortran
and IBM XL Fortran did not complain and successfully generated an object file. 

If this is not valid Fortran, an error message is better than a cryptic
assembler syntax error :)

[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-01-19 20:44:27 UTC ---
> I know this is sort of a contrived case but seems that gfortran is getting
> confused in this case leading to syntactically invalid assembler.

I don't see the invalid assembler on x86_64-apple-darwin10 and
powerpc-apple-darwin9 for trunk (4.6), 4.50, and 4.4.4. However gfortran is
indeed confused by the code as shown by the following modification:

RECURSIVE FUNCTION MAX(A, B, i) RESULT(K)
  real i
  i = i + 1
  IF (B >= 0) THEN
         K = MAX(A+1, B-1, i)
  ELSE
     K = A
  END IF
END
RECURSIVE FUNCTION myMAX(A, B, i) RESULT(K)
  real i
  i = i + 1
  IF (B >= 0) THEN
         K = myMAX(A+1, B-1, i)
  ELSE
     K = A
  END IF
END
external max
a = 0
b = 0
i = max(3.2,0.2, a)
j = mymax(3.2,0.2, b)
print *, i, j, a, b
a = 0
b = 0
i = max(3.2,2.2, a)
j = mymax(3.2,2.2, b)
print *, i, j, a, b
end
[macbook] f90/bug% gfc pr47359_db_3.f90
[macbook] f90/bug% a.out
           4           4   1.0000000       2.0000000    
           4           6   1.0000000       4.0000000    

where I had to declare 'i' REAL in order to avoid a compilation error and
clearly the external MAX is called, but only once apparently because the call
to MAX in MAX is a call to the intrinsic. g95 gives

 4 4 2. 2.
 6 6 4. 4.

[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.05.23 09:58:19
     Ever Confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-05-23 09:58:19 UTC ---
The test in comment #1 is still nt working at revision 174047.

[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2011-05-23 09:58:19         |2015-5-4
                 CC|                            |fxcoudert at gcc dot gnu.org

--- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Still fails. Somewhat reduced/reworked testcase:

program test
  external max
  print *, max(42, 1)
end

recursive function max(a, b) result(k)
  integer a, b, k
  if (b > 0) then
    k = max(a, b-1)
  else
    k = 0
  end if
end function

where you can see that generated code for function "max" does not call itself,
as it should. The output of that program is "42", while it should be "0".

Providing an explicit interface for "max" is also not working:

program test
  interface
    recursive function max(a, b) result(k)
      integer a, b, k
    end function
  end interface
  print *, max(42, 1)
end

recursive function max(a, b) result(k)
  integer a, b, k
  if (b > 0) then
    k = max(a, b-1)
  else
    k = 0
  end if
end function

[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Author: tkoenig
Date: Sat Jun  6 16:12:39 2015
New Revision: 224190

URL: https://gcc.gnu.org/viewcvs?rev=224190&root=gcc&view=rev
Log:
2015-06-06  Thomas Koenig  <tkoenig@netcologne.de>

        PR fortran/47359
        * arith.c (eval_intrinsic_op): Set warn flag for
        gfc_type_convert_binary if -Wconversion or -Wconversion-extra
        are set.
        (wprecision_real_real): New function.
        (wprecision_int_real): New function.
        (gfc_int2int): If -fno-range-check and -Wconversion are specified
        and it is a narrowing conversion, warn.
        (gfc_int2real): If there is a change in value for the conversion,
        warn.
        (gfc_int2complex):  Likewise.
        (gfc_real2int): If there is a fractional part to the real number,
        warn with -Wconversion, otherwise warn with -Wconversion-extra.
        (gfc_real2real): Emit warning if the constant was changed by
        conversion with either -Wconversion or -Wconversion-extra.  With
        -Wconversion-extra, warn if no warning was issued earlier.
        (gfc_real2complex):  Likewise.
        (gfc_complex2int): For -Wconversion or -Wconversion-extra, if
        there was an imaginary part, warn; otherwise, warn for change in
        value.  Warn with -Wconversion-extra if no other warning was
        issued.
        (gfc_complex2real): For -Wconversion or -Wconversion-extra, if
        there was an imaginary part, warn; otherwise, warn for change in
        value. Warn with -Wconversion-extra if no other warning was
        issued.
        (gfc_complex2complex):  For -Wconversion, warn if the value of
        either the real or the imaginary part was changed.  Warn for
        -Wconversion-extra if no prior warning was issued.
        * expr.c (gfc_check_assign):  Remove check for change in value.
        * primary.c (match_real_constant): For -Wconversion-extra, check
        against a number in which the last non-zero digit has been
        replaced with a zero.  If the number compares equal, warn.
        * intrinsic.c (gfc_convert_type_warn):  Do not warn about constant
        conversions.

2015-06-06  Thomas Koenig  <tkoenig@netcologne.de>

        PR fortran/47359
        * gfortran.dg/array_constructor_type_17.f03: Adjust error message.
        * gfortran.dg/warn_conversion.f90: Add warning for change in value
        for assignment.
        * gfortran.dg/warn_conversion_3.f90: Add warnings.
        * gfortran.dg/warn_conversion_5.f90: New test.
        * gfortran.dg/warn_conversion_6.f90: New test.
        * gfortran.dg/warn_conversion_7.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/warn_conversion_5.f90
    trunk/gcc/testsuite/gfortran.dg/warn_conversion_6.f90
    trunk/gcc/testsuite/gfortran.dg/warn_conversion_7.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/arith.c
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/intrinsic.c
    trunk/gcc/fortran/primary.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/array_constructor_type_17.f03
    trunk/gcc/testsuite/gfortran.dg/warn_conversion.f90
    trunk/gcc/testsuite/gfortran.dg/warn_conversion_3.f90

[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Author: tkoenig
Date: Sat Jun  6 16:16:03 2015
New Revision: 224191

URL: https://gcc.gnu.org/viewcvs?rev=224191&root=gcc&view=rev
Log:
2015-06-06  Thomas Koenig  <tkoenig@netcologne.de>

        PR fortran/47359
        * ChangeLog: Correct PR number in previous commit.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #5)
> Author: tkoenig
> Date: Sat Jun  6 16:16:03 2015
> New Revision: 224191

Of course, this was a commit for PR 47659.

One day, I will get the PR numbers right... hopefully.

[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
                 CC|                            |anlauf at gcc dot gnu.org
             Status|NEW                         |RESOLVED

--- Comment #7 from anlauf at gcc dot gnu.org ---
The issue is resolved by the fix for pr105138.
Thus very likely a duplicate.

Closing.

*** This bug has been marked as a duplicate of bug 105138 ***