public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler
@ 2011-01-19 12:24 roger.ferrer at bsc dot es
2011-01-19 20:53 ` [Bug fortran/47359] " dominiq at lps dot ens.fr
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: roger.ferrer at bsc dot es @ 2011-01-19 12:24 UTC (permalink / raw)
To: gcc-bugs
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 :)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
2011-01-19 12:24 [Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler roger.ferrer at bsc dot es
@ 2011-01-19 20:53 ` dominiq at lps dot ens.fr
2011-05-23 10:39 ` dominiq at lps dot ens.fr
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-01-19 20:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
2011-01-19 12:24 [Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler roger.ferrer at bsc dot es
2011-01-19 20:53 ` [Bug fortran/47359] " dominiq at lps dot ens.fr
@ 2011-05-23 10:39 ` dominiq at lps dot ens.fr
2015-05-04 15:21 ` fxcoudert at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-05-23 10:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
2011-01-19 12:24 [Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler roger.ferrer at bsc dot es
2011-01-19 20:53 ` [Bug fortran/47359] " dominiq at lps dot ens.fr
2011-05-23 10:39 ` dominiq at lps dot ens.fr
@ 2015-05-04 15:21 ` fxcoudert at gcc dot gnu.org
2015-06-06 16:13 ` tkoenig at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-05-04 15:21 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
2011-01-19 12:24 [Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler roger.ferrer at bsc dot es
` (2 preceding siblings ...)
2015-05-04 15:21 ` fxcoudert at gcc dot gnu.org
@ 2015-06-06 16:13 ` tkoenig at gcc dot gnu.org
2015-06-06 16:16 ` tkoenig at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2015-06-06 16:13 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
2011-01-19 12:24 [Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler roger.ferrer at bsc dot es
` (3 preceding siblings ...)
2015-06-06 16:13 ` tkoenig at gcc dot gnu.org
@ 2015-06-06 16:16 ` tkoenig at gcc dot gnu.org
2015-06-06 18:23 ` tkoenig at gcc dot gnu.org
2022-05-16 20:38 ` anlauf at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2015-06-06 16:16 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
2011-01-19 12:24 [Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler roger.ferrer at bsc dot es
` (4 preceding siblings ...)
2015-06-06 16:16 ` tkoenig at gcc dot gnu.org
@ 2015-06-06 18:23 ` tkoenig at gcc dot gnu.org
2022-05-16 20:38 ` anlauf at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2015-06-06 18:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
2011-01-19 12:24 [Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler roger.ferrer at bsc dot es
` (5 preceding siblings ...)
2015-06-06 18:23 ` tkoenig at gcc dot gnu.org
@ 2022-05-16 20:38 ` anlauf at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-05-16 20:38 UTC (permalink / raw)
To: gcc-bugs
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 ***
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-05-16 20:38 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-19 12:24 [Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler roger.ferrer at bsc dot es
2011-01-19 20:53 ` [Bug fortran/47359] " dominiq at lps dot ens.fr
2011-05-23 10:39 ` dominiq at lps dot ens.fr
2015-05-04 15:21 ` fxcoudert at gcc dot gnu.org
2015-06-06 16:13 ` tkoenig at gcc dot gnu.org
2015-06-06 16:16 ` tkoenig at gcc dot gnu.org
2015-06-06 18:23 ` tkoenig at gcc dot gnu.org
2022-05-16 20:38 ` anlauf at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).