Bug 47359 - Recursive functions of intrinsic names generates invalid assembler
Recursive functions of intrinsic names generates invalid assembler
Status: NEW
Product: gcc
Classification: Unclassified
Component: fortran
unknown
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
: wrong-code
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2011-01-19 11:24 UTC by Roger Ferrer Ibanez
Modified: 2012-09-21 18:58 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.1.2, 4.2.1, 4.3.4, 4.4.0, 4.5.1, 4.6.0
Last reconfirmed: 2011-05-23 09:58:19


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roger Ferrer Ibanez 2011-01-19 11:24:20 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.

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 :)
Comment 1 Dominique d'Humieres 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.
Comment 2 Dominique d'Humieres 2011-05-23 09:58:19 UTC
The test in comment #1 is still nt working at revision 174047.