[Bug fortran/93827] fails to initialize logical variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93827 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to dan hayes from comment #2) > u say "unlike C only occurs once..." Yea so what I know that and it's > not consistently doing that. This is not a recursive routine. What is your > point? > Please use English in your responses. Please find a reference on the Fortran program language. Mark's response is correct. If you use logical*1 :: fl=.false. in a function (or subroutine), then the first time that the function is called the variable 'fl is initialized to .false. When the function or subroutine returns, the variable 'fl' retains whatever its last value was. The next invocation of that function will used that *retained value*. This has nothing to do with recursion. It is the semantics of the language. If 'fl' needs to be .false. at the start of then function on every invocation, then you need to use an assignment.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 kargl at gcc dot gnu.org changed: What|Removed |Added CC|kargl at gcc dot gnu.org | --- Comment #44 from kargl at gcc dot gnu.org --- I have posted a large patch that fixes all problems that I am aware of. Feel free to use it or ignore. https://gcc.gnu.org/ml/fortran/2020-03/msg00024.html
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Priority|P3 |P2 Severity|normal |major --- Comment #26 from kargl at gcc dot gnu.org --- Any chance a libstdc++ person will commit the supplied patches?
[Bug fortran/94192] ICE on wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94192 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/94192] ICE on wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94192
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2020-03-16
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Quite silly to have an assert if compiler has already issued an error.
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c (revision 280157)
+++ gcc/fortran/simplify.c (working copy)
@@ -4154,12 +4189,6 @@ simplify_bound (gfc_expr *array, gfc_expr *dim, gfc_ex
|| (as->type == AS_ASSUMED_SHAPE && upper)))
return NULL;
- gcc_assert (!as
- || (as->type != AS_DEFERRED
- && array->expr_type == EXPR_VARIABLE
- && !gfc_expr_attr (array).allocatable
- && !gfc_expr_attr (array).pointer));
-
if (dim == NULL)
{
/* Multi-dimensional bounds. */
[Bug fortran/94228] Preprocessor inconsistency for macros when invoked from gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Mark Paris from comment #2) > (In reply to Andrew Pinski from comment #1) > > gfortran defaults to -traditional-cpp preprocessor mode. > > Thank you for your reply. If I may, I'd like to pose a question that I > cannot find the answer to from online sources: > > Is it possible to run the preprocessor in the ISO mode, not the traditional > mode, when invoked by gfortran? No. Newer C, as opposed to older C, uses // for a comment. Fortran uses // as the concatenation operator. Run this through a cpp pre-processor. character(len=80) :: name = 'john ' // 'Doe' print *, name end ~/work/bin/cpp a.F # 1 "a.F" # 1 "" # 1 "" # 1 "a.F" character(len=80) :: name = 'john ' print *, name end
[Bug fortran/94246] [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to David Binderman from comment #0) > I just tried a valgrind version of recent trunk gfortran over testsuite file > gfortran.dg/bessel_5.f90. > > I got > > $ /home/dcb/gcc/results.20200320.valgrind/bin/gfortran -c > ./gfortran.dg/bessel_5.f90 > ./gfortran.dg/bessel_5.f90:64:50: > >64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) > ])) & > | 1 > Error: Result of BESSEL_YN overflows its kind at (1) > ./gfortran.dg/bessel_5.f90:64:26: > >64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) > ])) & > | 1 > Error: Result of BESSEL_YN is -INF at (1) > ==1776287== Invalid read of size 8 > ==1776287==at 0x603913: reduce_binary_ac(arith (*)(gfc_expr*, gfc_expr*, > gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1325) > ==1776287==by 0x60397A: reduce_binary_ac(arith (*)(gfc_expr*, gfc_expr*, > gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1312) > ==1776287==by 0x603B34: reduce_binary(arith (*)(gfc_expr*, gfc_expr*, > gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1438) > ==1776287==by 0x603F72: eval_intrinsic(gfc_intrinsic_op, eval_f, > gfc_expr*, gfc_expr*) (arith.c:1613) > > Please note I didn't use the recommended testsuite flags of > -Wall -fno-range-check. > So, what happens if you do use the required -fno-range-check option?
[Bug fortran/94347] Assignment pointer at declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94347 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Known to work||10.0, 9.2.1 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Upgrade to a newer version. This will likely get closed as WONTFIX in a year or two.
[Bug fortran/94348] gfortran 8/9 reject module procedure definition in same module as function interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94348 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Don't understand what you consider the problem. You need to declare bar in the 'module procedure foo'. Isn't the interface-body a scoping unit? Isn't bar a local variable in that scoping unit?
[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to markeggleston from comment #3) > A patch from Steve Kargl was sent to the fortran mailing list, (see > https://gcc.gnu.org/pipermail/fortran/2020-March/054130.html) without > reference to any PR. > > It appeared to be related to this PR. I have verified the patch and also > checked it with the test case in the original report. Techinically, it is related to https://stackoverflow.com/questions/60846187/fortran-equivalence-statement-with-array-length-from-subroutine-input In the stackoverflow thread, someone mentioned this is a regression going back to at least 6.5.
[Bug fortran/94377] Won't compile when deallocating a parameterized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94377 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Either update to the most recent version of gfortran, or the code included in this bug report is not the code that demonstrates the problem. I get % gfortran -c a.f90 a.f90:8:14: type(av_t(:), allocatable :: av(:) 1 Error: Malformed type-spec at (1) a.f90:17:29: allocate ( av_t(k2) :: av(k3), stat=ista) ! For this ista not needed 1 Error: Allocate-object at (1) is neither a data pointer nor an allocatable variable a.f90:20:19: deallocate(av, stat=ista) 1 Error: Allocate-object at (1) is not a nonprocedure pointer nor an allocatable variable for 8.3.1, 9.2.1, and 10.0
[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Martin Liška from comment #1) > Confirmed, started with r10-7369-gc38daa7976886a59. Patch in the linked git revision appears to expose a latent bug in TYPE IS(). Two workarounds are to use either type is (real(4)) ! Bad, because of hard coded kind parameter or integer, parameter :: sp = kind(1.) ... type is (real(sp))
[Bug fortran/94408] Spurious error: ‘rw_nl_grid’ must be a module procedure or an external procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94408 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to michalak from comment #1) > Here is a slightly more simplified version of the test.F90 program that > still demonstrates the error with gcc 9.1.0 (below). The namelist_t type > from the previous reproducer code turns out not to be necessary and has been > removed from the example. Commenting out the indicated line causes the error > to go away. Thanks, -John > > === > > module mod_input > type config_t > integer :: domain_id > contains > procedure :: init => rw_config > procedure :: rw_nl_grid > end type config_t > interface > module subroutine rw_config (this,iunit) > implicit none > class (config_t) :: this > integer, intent(in), optional :: iunit > end subroutine rw_config > module subroutine rw_nl_grid ( this, iunit ) > implicit none > class (config_t) :: this > integer, optional, intent(in) :: iunit > end subroutine rw_nl_grid > end interface > contains > module subroutine rw_config (this,iunit) > implicit none > class (config_t) :: this > integer, intent(in), optional :: iunit > call this%rw_nl_grid ! comment this out to make error go away > end subroutine rw_config > module subroutine rw_nl_grid ( this, iunit ) > implicit none > class (config_t) :: this > integer, optional, intent(in) :: iunit > end subroutine rw_nl_grid > end module mod_input > > module neptune_write_native > contains > subroutine Run > use mod_input > type(config_t):: config > end subroutine Run > end module neptune_write_native Although your code is likely conforming (I don't know as I don't you the construct you're trying to exploit), if you remove the interface block (which is redundant as contained procedures within a module have explict interfaces) then the code compiles. Hopefully, someone who writes similar code will take an interest in this issue and submit a patch. Good luck.
[Bug fortran/94411] E0.d not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Bill Long from comment #0) > We have a customer who complained that the Fortran 2018 feature for > allowing w=0 in E-like format descriptors is not working with > gfortran version 9.2. I pointed them to the table at > https://gcc.gnu.org/wiki/Fortran2018Status and that the entry for > "d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors" was > marked "No" They pointed out that the other two compilers they > commonly use (Cray and Intel) both support this feature. So, I'm > submitting their "bug", but changing it to a RFE. With the hope that > their input might help influence the priority given for this feature. > > Example test program: > > > > program test > real(8) :: r > r = atan(1.0) > r = r * 65536 > write (*,'(e0.6)') r > end program test You need to update to top-of-tree. It will be available when 10.1 is released.
[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to Bill Seurer from comment #6) > git g:3fb7f2fbd5f109786922deb5af8fd8dd594a7ba6, r10-7443 > > make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr93600_1.f90 > # of expected passes 3 > > > git g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444 > > make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr93600_1.f90 > > # of unexpected failures 3 > FAIL: gfortran.dg/pr93600_1.f90 -O (test for errors, line 6) > FAIL: gfortran.dg/pr93600_1.f90 -O (test for errors, line 7) > FAIL: gfortran.dg/pr93600_1.f90 -O (test for excess errors) > > > These were both clean builds run on a powerpc64 power8 LE machine. The patch committed to fix(?) PR94246 reverted the code that fixed PR93665 and PR93600 without removing the now failing testcases and re-opening the now unfixed PR93665 and PR93600. %len and %kind need to be special cased. See, Oh, I don't know maybe the removed comments in the diff.
[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to markeggleston from comment #4) > The compilation error reported is due this change in PR93484: > > --- a/gcc/fortran/match.c > +++ b/gcc/fortran/match.c > @@ -,9 +,9 @@ gfc_match_type_spec (gfc_typespec *ts) > > found: > > - m = gfc_match_init_expr (&e); > + m = gfc_match_expr (&e); > > Changing it back causes test cases ISO_Fortran_binding_11.f90 and > pr78033.f90 to fail. > > If "kind=" is found gfc_match_init_expr (&e) should be used and when it is > not gfc_match_expr (&e). > > I'm checking a suitable test case and will have a patch ready soon. The patch in comment #3 likely is the correct patch. When in the specification part of a scoping unit, the above change is needed to distinguish REAL(kind(1.)) from REAL(1.1, kind(1.)). In the former, we have a type and kind(1.) must be an initialization expression (see comment 3 or 4 lines down). In the latter case, we have the intrinsic subprogram, and simply return MATCH_NO or MATCH_ERROR. -- steve
[Bug fortran/93762] Truncation of deferred-length string when passing as optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93762 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #1) > Unfortunately, the test case fails with different ways on > current trunk: > > $ gfortran -g a.f90 > $ ./a.out > at bot of deepest_call, str is "12345" > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > Backtrace for this error: > #0 0x7f0a66c3059f in ??? > at > /usr/src/debug/glibc-2.26-lp151.19.11.1.x86_64/signal/../sysdeps/unix/sysv/ > linux/x86_64/sigaction.c:0 > #1 0x400c65 in __interface_call_m_MOD_interface_call > at /tmp/a.f90:20 > #2 0x400d99 in MAIN__ > at /tmp/a.f90:32 > #3 0x400f0b in main > at /tmp/a.f90:25 > Speicherzugriffsfehler (Speicherabzug geschrieben) > > (gdb) r a.f90 > Starting program: /tmp/a.out a.f90 > at bot of deepest_call, str is "12345" > > Program received signal SIGSEGV, Segmentation fault. > _gfortran_string_len_trim (s=0x6068d0 "12345", len=) at > ../../../gcc/libgfortran/intrinsics/string_intrinsics_inc.c:231 > 231 if (*((unsigned long*) (s + i + 1)) != blank_longword) > (gdb) p s > $1 = 0x6068d0 "12345" > (gdb) p i > $2 = 564082115390472183 > > Seems like uninitialzed memory for i. > > Valgrind confirms this: > > $ valgrind ./a.out > ==5621== Memcheck, a memory error detector > ==5621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==5621== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info > ==5621== Command: ./a.out > ==5621== > at bot of deepest_call, str is "12345" > ==5621== Conditional jump or move depends on uninitialised value(s) > ==5621==at 0x50A29A5: _gfortran_string_len_trim > (string_intrinsics_inc.c:188) > ==5621==by 0x50A2A87: _gfortran_string_trim (string_intrinsics_inc.c:168) > ==5621==by 0x400C65: __interface_call_m_MOD_interface_call (a.f90:20) > ==5621==by 0x400D99: MAIN__ (a.f90:32) > ==5621==by 0x400F0B: main (a.f90:25) > > Not sure if this ever worked in a released version. I doubt it ever worked. It seems that the length is not getting set properly for the returning string. Should this be propagated up the call change in the hidden string length argument. Here's a modified testcase where I print out lengths of str. module deepest_call_m implicit none contains subroutine deepest_call(str) character(len=:), allocatable, optional :: str character(len=5) t t = '12345' if (present(str)) then str = t write(*,*) 'at bot of deepest_call, str is "'//trim(str)//'"' end if print *, 'len = ', len(str) print '(A)', 'Returning from deepest_call' end subroutine deepest_call end module deepest_call_m module interface_call_m implicit none contains subroutine interface_call(str) use deepest_call_m, only : deepest_call character(len=:), allocatable, optional :: str if (present(str)) then call deepest_call(str) print *, 'len = ', len(str) write(*,*) 'at bot of interface_call, str is "'//trim(str)//'"' end if end subroutine interface_call end module interface_call_m program main use interface_call_m, only : interface_call implicit none character(len=:), allocatable :: str call interface_call(str) write(*,*) 'at bot of main, str is "'//trim(str)//'"' end program main I get % gfcx -o z -g a.f90 && ./z at bot of deepest_call, str is "12345" len =5 Returning from deepest_call len =134516966 Segmentation fault (core dumped) len = 5 is in deepest_call and the correct value. len = 134516966 seems to be a bit too large.
[Bug fortran/94585] Automatic LHS reallocation issue with debug options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94585 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- The code compiles with 8.3.1, 9.2.1, and 10.0.0. Please to a newer version of gfortran. I believe the 7-branch has been clsed, so there is no chance that this will be fixed in 7.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- This appears to be a bogus report. (In reply to John David Anglin from comment #0) > libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc > -B/test/gnu/gcc/objdir/./gcc/ > -B/opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/bin/ > -B/opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/lib/ -isystem > /opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/include -isystem > /opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/sys-include -fchecking=1 > -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran > -iquote../../../gcc/libgfortran/io -I../../../gcc/libgfortran/../gcc > -I../../../gcc/libgfortran/../gcc/config > -I../../../gcc/libgfortran/../libquadmath -I../.././gcc > -I../../../gcc/libgfortran/../libgcc -I../libgcc > -I../../../gcc/libgfortran/../libbacktrace -I../libbacktrace > -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -Wextra -Wwrite-strings > -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules > -ffunction-sections -fdata-sections -g -O2 -MT trigd.lo -MD -MP -MF > .deps/trigd.Tpo -c ../../../gcc/libgfortran/intrinsics/trigd.c -DPIC -o > .libs/trigd.o > ../../../gcc/libgfortran/intrinsics/trigd.inc: In function 'sind_r4': > ../../../gcc/libgfortran/intrinsics/trigd_lib.inc:84:28: error: implicit > declaration of function 'fmaf' [-Werror=implicit-function-declaration] >84 | #define FMA(x,y,z) SUFFIX(fma)((x), (y), (z)) > |^~~ > Does math.h define fmaf? If yes, this this is bogus bug report. If no, please disable building gfortran on hppa64.
[Bug fortran/94660] Wrong subroutine called at runtime than the one called in the source code with deferred subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94660 kargl at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-04-19 CC||kargl at gcc dot gnu.org Status|UNCONFIRMED |NEW Known to work||4.8.5 Ever confirmed|0 |1 Known to fail||6.3.0, 7.3.0, 7.5.0, 8.2.0, ||8.4.0, 9.2.0
[Bug fortran/94737] BIND(C) names are not always treated as case sensitive. Versions < 8 are ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
Last reconfirmed||2020-04-23
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Known to fail||10.0, 8.1.0
--- Comment #1 from kargl at gcc dot gnu.org ---
This also fails with trunk as svn revision 280157. The following trivial patch
allows your code to compile.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -2517,8 +2517,14 @@ resolve_global_procedure (gfc_symbol *sym, locus *wher
gsym = gfc_get_gsymbol (sym->binding_label ? sym->binding_label : sym->name,
sym->binding_label != NULL);
- if ((gsym->type != GSYM_UNKNOWN && gsym->type != type))
-gfc_global_used (gsym, where);
+ if (gsym->type != GSYM_UNKNOWN && gsym->type != type)
+{
+ if (sym->binding_label && gsym->binding_label
+ && strcmp (sym->binding_label, gsym->binding_label) != 0)
+ ;
+ else
+ gfc_global_used (gsym, where);
+}
if ((sym->attr.if_source == IFSRC_UNKNOWN
|| sym->attr.if_source == IFSRC_IFBODY)
Passing the created *.mod file through gunzip shows
3 'func1' 'foo' 'c_func' 1 ((PROCEDURE UNKNOWN-INTENT EXTERNAL-PROC BODY
UNKNOWN 0 0 EXTERNAL FUNCTION IS_BIND_C IS_C_INTEROP
ARRAY_OUTER_DEPENDENCY) () (INTEGER 4 0 1 0 INTEGER ()) 4 0 (5) () 6 ()
() () 0 0)
11 'sub1' 'foo' 'c_Func' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC BODY
UNKNOWN 0 0 EXTERNAL SUBROUTINE IS_BIND_C IS_C_INTEROP
ARRAY_OUTER_DEPENDENCY) () (UNKNOWN 0 0 1 0 UNKNOWN ()) 12 0 (13 14) ()
so I suspect it works. Probably, need to expand the test to skip the
error path to do comparisons involving sym->name and gsym->name. Just
details for someone else to consider.
[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 kargl at gcc dot gnu.org changed: What|Removed |Added Keywords|rejects-valid | --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #2) > Correction, this is not a regression. > > F2018 has, in 19.2, paragraph 2 > > # The global identifier of an entity shall not be the same as the global > # identifier of any other entity. Furthermore, a binding label shall not > # be the same as the global identifier of any other global entity, > # ignoring differences in case. > > So, the error message is correct, and you need to change your > program accordingly. Good catch, Thomas! In hindsight, the restriction makes prefect sense given Fortran is a case insensitive language.
[Bug fortran/94769] Possible use of uninitialized variable num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Looks like a false positive. As you observe, num is set in a previous line code. You can set it to any value you want. A better option would be to have the option, which causes the false positive, fixed or removed from the command line.
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #21 from kargl at gcc dot gnu.org --- (In reply to Jürgen Reuter from comment #20) > Thanks a lot for reverting, Thomas, shall I further reduce the reproducer, > or can you work with it now? In comment #2 you mention a finalizer. There are 22 open bug reports about finalization. It is likely that Thomas's patch uncovered yet another finalization bug.
[Bug fortran/94931] request: print include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Ryo Furue from comment #0) > I'm not familiar with this bug tracker. I mean to submit a request, not a > bug report. > > Sorry if I missed anything, but it seems to me that there is no (official) > way to print the list of paths which gfortran searches for include files. If > that is correct, my request would be to provide a means to print the paths. > > The `--print-search-dirs` option indicates paths only for the installation, > executables, and libraries (It seems to me). > > This discussion applies to the INCLUDE statement of the Fortran language, > not the `#include` directive of the preprocessor. > > Off-topic: I wonder if there is a discussion available online about why > /usr/include or something like that is not searched by default? Is there a > common (more or less standard) place for gfortran to search? There isn't a list of paths. With the Fortran INCLUDE statement, by default gfortran looks in the current working directory. That is it. If you have files, which are INCLUDEd, into your program is different directories, you can create a list of paths with the -I option. gfortran also searches for its own INCLUDE files and intrinsic modules in a directory created during installation of the compiler. You can find the name of that directory by using the -v option during compilation. For example, on my OS, this command % gfcx -v -o z a.f90 | & grep -- -fin yields -fintrinsic-modules-path /usr/home/kargl/work/lib/gcc/i586-unknown-freebsd13.0/10.0.0/finclude It seems to me that an option to print the INCLUDE search path is not needed. The PR can probably be closed as RESOLVED WONTFIX, but I'll someone else make that decision.
[Bug fortran/94943] [10 Regression] A module does not export allocatable attribute of herein arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94943 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- There is very little we can do without a minimum example that shows the problem. What you have attached cannot be compiled by anyone as deallocate_vars.f90 contains a dozen or so USE statements and you haven't provided those modules. In addition, we don't do mpif90. What happens if you remove all of the unnecessary compiler options you use and use actually use gfortran.
[Bug fortran/95037] gfortran fails to compile a simple subroutine, issues an opaque message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95037
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC||kargl at gcc dot gnu.org
Last reconfirmed||2020-05-10
Status|UNCONFIRMED |NEW
Priority|P3 |P4
--- Comment #1 from kargl at gcc dot gnu.org ---
Do not dereference a NULL pointer. Patch against svn r280157.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 280157)
+++ gcc/fortran/check.c (working copy)
@@ -6600,10 +6600,10 @@ gfc_check_random_seed (gfc_expr *size, gfc_expr *put,
if (gfc_array_size (put, &put_size)
&& mpz_get_ui (put_size) < seed_size)
- gfc_error ("Size of %qs argument of %qs intrinsic at %L "
+ gfc_error ("Size of %qs argument of %qs intrinsic at %C "
"too small (%i/%i)",
gfc_current_intrinsic_arg[1]->name, gfc_current_intrinsic,
- where, (int) mpz_get_ui (put_size), seed_size);
+ (int) mpz_get_ui (put_size), seed_size);
}
if (get != NULL)
@@ -6632,10 +6632,10 @@ gfc_check_random_seed (gfc_expr *size, gfc_expr *put,
if (gfc_array_size (get, &get_size)
&& mpz_get_ui (get_size) < seed_size)
- gfc_error ("Size of %qs argument of %qs intrinsic at %L "
+ gfc_error ("Size of %qs argument of %qs intrinsic at %C "
"too small (%i/%i)",
gfc_current_intrinsic_arg[2]->name, gfc_current_intrinsic,
- where, (int) mpz_get_ui (get_size), seed_size);
+ (int) mpz_get_ui (get_size), seed_size);
}
/* RANDOM_SEED may not have more than one non-optional argument. */
[Bug fortran/95038] Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC||kargl at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Priority|P3 |P4
Last reconfirmed||2020-05-10
--- Comment #2 from kargl at gcc dot gnu.org ---
This patch allows test.f90 to compile. test1.f90 and test2.f90 compile for me.
The question on whether IMPORT is needed or not is for someone else to ponder.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 280157)
+++ gcc/fortran/check.c (working copy)
@@ -3375,7 +3375,8 @@ gfc_check_kind (gfc_expr *x)
gfc_current_intrinsic, &x->where);
return false;
}
- if (x->ts.type == BT_PROCEDURE)
+ if (x->ts.type == BT_PROCEDURE
+ && !(x->symtree && x->symtree->n.sym->attr.function))
{
gfc_error ("%qs argument of %qs intrinsic at %L must be a data entity",
gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c (revision 280157)
+++ gcc/fortran/simplify.c (working copy)
@@ -3969,7 +3969,11 @@ gfc_simplify_ishftc (gfc_expr *e, gfc_expr *s, gfc_exp
gfc_expr *
gfc_simplify_kind (gfc_expr *e)
{
- return gfc_get_int_expr (gfc_default_integer_kind, NULL, e->ts.kind);
+ int knd = e->ts.kind;
+ if (e->ts.type == BT_PROCEDURE
+ && e->symtree && e->symtree->n.sym->attr.function)
+knd = e->symtree->n.sym->ts.kind;
+ return gfc_get_int_expr (gfc_default_integer_kind, NULL, knd);
}
[Bug fortran/33056] [Meta-bug] Data - statement related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056 Bug 33056 depends on bug 50410, which changed state. Bug 50410 Summary: [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 kargl at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||kargl at gcc dot gnu.org Resolution|FIXED |--- Target Milestone|8.5 |11.0 --- Comment #39 from kargl at gcc dot gnu.org --- The bug is not fixed. The code from comment #3 % cat a.f90 type t integer g end type type(t) :: u=t(1) data u%g /2/ end troutmask:sgk[205] gfcx -c a.f90 a.f90:1:0: 1 | type t | internal compiler error: Segmentation fault 0xdf6e3a crash_signal ../../gccx/gcc/toplev.c:328 0x8acbae gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gccx/gcc/fortran/trans-expr.c:8528 0x8c1f37 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gccx/gcc/fortran/trans-expr.c:7679 0x8a0020 gfc_get_symbol_decl(gfc_symbol*) ../../gccx/gcc/fortran/trans-decl.c:1892 0x8a33e5 generate_local_decl ../../gccx/gcc/fortran/trans-decl.c:5894 0x85a0e2 do_traverse_symtree ../../gccx/gcc/fortran/symbol.c:4165 0x8a454c generate_local_vars ../../gccx/gcc/fortran/trans-decl.c:6100 0x8a454c gfc_generate_function_code(gfc_namespace*) ../../gccx/gcc/fortran/trans-decl.c:6758 0x81e516 translate_all_program_units ../../gccx/gcc/fortran/parse.c:6302 0x81e516 gfc_parse_file() ../../gccx/gcc/fortran/parse.c:6541 0x871858 gfc_be_parse_file ../../gccx/gcc/fortran/f95-lang.c:210 The code in the first example in comment #9 also causes an ICE. Codes z1.f90, z2.f90, and z3.f90 in comment #23 cause ICEs.
[Bug fortran/95064] [11 regression] ICEs in fortran compiler starting with r11-255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95064 kargl at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE CC||kargl at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from kargl at gcc dot gnu.org --- See PR 95053. *** This bug has been marked as a duplicate of bug 95053 ***
[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 kargl at gcc dot gnu.org changed: What|Removed |Added CC||seurer at linux dot vnet.ibm.com --- Comment #5 from kargl at gcc dot gnu.org --- *** Bug 95064 has been marked as a duplicate of this bug. ***
[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #6)
> It gets actually really weird during parsing.
Nah. gfortran runs a sequence of matchers, and queues
errors as it runs. If a matcher is not found, then
(normally only) the last queued error message is emitted.
If a matcher is found, the error message queue is cleaned
up.
> The following (invalid) code shows that the parser is still in an
> early phase where it has not yet decided that it is a FORMAT statement,
> but rather could be something else:
>
> format('x') = x
> end
>
> This gives:
>
> 1 | format('x') = x
> | 1
> Error: The function result on the lhs of the assignment at (1) must have the
> pointer attribute.
>
> while e.g. Intel detects:
>
> foo.f90(1): error #6072: A dummy argument of a statement function must be a
> scalar identifier. ['x']
> format('x') = x
> -^
gfortran and ifort are simply trying different sequences of
matchers.
> The simplest solution is to defer error detection and recovery by restoring
> the previous behavior when the basic type of operand 2 to gfc_divide is
> non-numeric:
>
> diff --git a/gcc/fortran/arith.c b/gcc/fortran/arith.c
> index 1cd0867a941..dd72f44d377 100644
> --- a/gcc/fortran/arith.c
> +++ b/gcc/fortran/arith.c
> @@ -1828,7 +1828,8 @@ gfc_divide (gfc_expr *op1, gfc_expr *op2)
> rc = ARITH_DIV0;
> break;
> default:
> - gfc_internal_error ("gfc_divide(): Bad basic type");
> + /* basic type is non-numeric, handle this elsewhere. */
> + break;
> }
>if (rc == ARITH_DIV0)
> {
>From my long forgotten days of working in arith.c, it is almost
always wrong to emit a gfc_internal_error. Typical an error
message is generated during simplification or resolution that
catches a problems.
[Bug fortran/95104] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-13 Ever confirmed|0 |1 CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- 0x284321d9 in _gfortran_st_wait_async (wtp=0xffbfe488) at ../../../gcc/libgfortran/io/transfer.c:4495 4495 if (ASYNC_IO && u->au) (gdb) p u $1 = (gfc_unit *) 0x0
[Bug fortran/95104] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Bill Long from comment #3)
> A comment from the original user: gfortran 8.3.0 appears to do the right
> thing. So perhaps a regression somewhere in the 9.x line?
A note of the gfortran wiki says full asynchronous support became
available in 9.1. SO, likely a bug introduced in 9. This fixes
the segfault as it is never correct to dereference a NULL pointer.
Index: libgfortran/io/transfer.c
===
--- libgfortran/io/transfer.c (revision 280157)
+++ libgfortran/io/transfer.c (working copy)
@@ -4492,7 +4492,7 @@ void
st_wait_async (st_parameter_wait *wtp)
{
gfc_unit *u = find_unit (wtp->common.unit);
- if (ASYNC_IO && u->au)
+ if (ASYNC_IO && u && u->au)
{
if (wtp->common.flags & IOPARM_WAIT_HAS_ID)
async_wait_id (&(wtp->common), u->au, *wtp->id);
With this patch, your program prints '0'. Don't know if this
is the only thing that needs fixing. Thanks for the bug report.
[Bug fortran/95104] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/95165] Since 9.1 we do have ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95165 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Last reconfirmed||2020-05-16 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|web |fortran CC||kargl at gcc dot gnu.org
[Bug libfortran/95177] error: array subscript has type char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Why cast to unsigned char? The prototypes for tolower(), toupper(), isdigit(), etc show that the type of the argument is int. Also, why are errors being issued? None of the places where you have inserted an (unsigned char) cast is a subscripts.
[Bug libfortran/95293] Fortran not passing array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to David Sagan from comment #0) > The test program is: > > program test > implicit none > > type cb_struct > real :: cbar = 0 > end type > > type scratch_struct > type (cb_struct) :: cc(10) > real :: zz(10) = 0 > end type > > type (scratch_struct), target :: s1 > > ! > > s1%cc(2)%cbar = 7 > call sub2(s1%cc%cbar) > print *, 'Sub2 result:', s1%cc(2)%cbar, ' ! Wrong. Should be 10' > > s1%zz(2) = 7 > call sub3(s1%zz) > print *, 'Sub3 result:', s1%zz(2) > > !-- > contains > > subroutine sub2(vec) > real, target, intent(inout) :: vec(:) > real, pointer :: ptr > ptr => vec(1) > print *, 'In sub2:', associated(ptr, s1%cc(1)%cbar), vec(2) > vec(2) = 23 > s1%cc(2)%cbar = 10 > end subroutine sub2 > > subroutine sub3(vec) > real, target, intent(inout) :: vec(:) > real, pointer :: ptr > ptr => vec(1) > print *, 'In sub3:', associated(ptr, s1%zz(1)), vec(2) > vec(2) = 23 > s1%zz(2) = 10 > end subroutine sub3 > > end program > > > Running gives: > > > gfortran test.f90 > > ./a.out > In sub2: F 7. > Sub2 result: 23.000 ! Wrong. Should be 10 > In sub3: T 7. > Sub3 result: 10.000 > > I get the same result on Linux and Mac with gcc 8.3.1 and gcc 9.3. % gfcx -Warray-temporaries -o z b.f90 b.f90:18:10: 18 | call sub2(s1%cc%cbar) | 1 Warning: Creating array temporary at (1) [-Warray-temporaries]
[Bug fortran/95342] [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #1)
> Related :
>
>
> $ cat z2.f90
> module m
>interface
> module function f()
> end
>end interface
>interface
> function f() bind(c)
> end
>end interface
> end
>
>
> $ gfortran-11-20200524 -c z2.f90
> f951: internal compiler error: Segmentation fault
> 0xbc0f6f crash_signal
> ../../gcc/toplev.c:328
> 0x643eeb gfc_match_function_decl()
> ../../gcc/fortran/decl.c:7398
> 0x6a82ca decode_statement
> ../../gcc/fortran/parse.c:343
> 0x6a9e1a next_free
> ../../gcc/fortran/parse.c:1279
> 0x6a9e1a next_statement
> ../../gcc/fortran/parse.c:1511
> 0x6aba5c parse_interface
> ../../gcc/fortran/parse.c:3519
> 0x6aba5c parse_spec
> ../../gcc/fortran/parse.c:3875
> 0x6af43e parse_module
> ../../gcc/fortran/parse.c:6115
> 0x6af787 gfc_parse_file()
> ../../gcc/fortran/parse.c:6428
> 0x6fb9af gfc_be_parse_file
> ../../gcc/fortran/f95-lang.c:210
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -7325,7 +7325,8 @@ gfc_match_function_decl (void)
procedure interface body. */
if (sym->attr.is_bind_c && sym->attr.module_procedure && sym->old_symbol
&& strcmp (sym->name, sym->old_symbol->name) == 0
- && strcmp (sym->binding_label, sym->old_symbol->binding_label) != 0)
+ && (!sym->old_symbol->binding_label
+ || strcmp (sym->binding_label, sym->old_symbol->binding_label) !=
0))
{
const char *null = "NULL", *s1, *s2;
s1 = sym->binding_label;
[Bug fortran/95342] [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> (In reply to G. Steinmetz from comment #1)
> > Related :
> >
> >
> > $ cat z2.f90
> > module m
> >interface
> > module function f()
> > end
> >end interface
> >interface
> > function f() bind(c)
> > end
> >end interface
> > end
> >
> >
> > $ gfortran-11-20200524 -c z2.f90
> > f951: internal compiler error: Segmentation fault
> > 0xbc0f6f crash_signal
> > ../../gcc/toplev.c:328
> > 0x643eeb gfc_match_function_decl()
> > ../../gcc/fortran/decl.c:7398
> > 0x6a82ca decode_statement
> > ../../gcc/fortran/parse.c:343
> > 0x6a9e1a next_free
> > ../../gcc/fortran/parse.c:1279
> > 0x6a9e1a next_statement
> > ../../gcc/fortran/parse.c:1511
> > 0x6aba5c parse_interface
> > ../../gcc/fortran/parse.c:3519
> > 0x6aba5c parse_spec
> > ../../gcc/fortran/parse.c:3875
> > 0x6af43e parse_module
> > ../../gcc/fortran/parse.c:6115
> > 0x6af787 gfc_parse_file()
> > ../../gcc/fortran/parse.c:6428
> > 0x6fb9af gfc_be_parse_file
> > ../../gcc/fortran/f95-lang.c:210
>
> Index: gcc/fortran/decl.c
> ===
> --- gcc/fortran/decl.c(revision 280157)
> +++ gcc/fortran/decl.c(working copy)
> @@ -7325,7 +7325,8 @@ gfc_match_function_decl (void)
> procedure interface body. */
> if (sym->attr.is_bind_c && sym->attr.module_procedure && sym->old_symbol
> && strcmp (sym->name, sym->old_symbol->name) == 0
> - && strcmp (sym->binding_label, sym->old_symbol->binding_label) != 0)
> + && (!sym->old_symbol->binding_label
> + || strcmp (sym->binding_label, sym->old_symbol->binding_label) !=
> 0))
>{
> const char *null = "NULL", *s1, *s2;
> s1 = sym->binding_label;
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -7325,7 +7325,8 @@ gfc_match_function_decl (void)
procedure interface body. */
if (sym->attr.is_bind_c && sym->attr.module_procedure && sym->old_symbol
&& strcmp (sym->name, sym->old_symbol->name) == 0
- && strcmp (sym->binding_label, sym->old_symbol->binding_label) != 0)
+ && (!sym->old_symbol->binding_label
+ || strcmp (sym->binding_label, sym->old_symbol->binding_label) !=
0))
{
const char *null = "NULL", *s1, *s2;
s1 = sym->binding_label;
@@ -7840,7 +7841,8 @@ gfc_match_subroutine (void)
procedure interface body. */
if (sym->attr.module_procedure && sym->old_symbol
&& strcmp (sym->name, sym->old_symbol->name) == 0
- && strcmp (sym->binding_label, sym->old_symbol->binding_label) != 0)
+ && (!sym->old_symbol->binding_label
+ || strcmp (sym->binding_label, sym->old_symbol->binding_label) !=
0))
{
const char *null = "NULL", *s1, *s2;
s1 = sym->binding_label;
[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to José Rui Faustino de Sousa from comment #1)
> On further investigation the ICE is not generated by the extra parenthesis,
> but by the use of the lbound intrinsic.
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c (revision 280157)
+++ gcc/fortran/simplify.c (working copy)
@@ -4019,7 +4023,7 @@ simplify_bound_dim (gfc_expr *array, gfc_expr *kind, i
|| (coarray && d == as->rank + as->corank
&& (!upper || flag_coarray == GFC_FCOARRAY_SINGLE)))
{
- if (as->lower[d-1]->expr_type == EXPR_CONSTANT)
+ if (as->lower[d-1] && as->lower[d-1]->expr_type == EXPR_CONSTANT)
{
gfc_free_expr (result);
return gfc_copy_expr (as->lower[d-1]);
[Bug fortran/95340] [10/11 Regression] ICE in gfc_match_select_rank, at fortran/match.c:6690
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95340
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 280157)
+++ gcc/fortran/match.c (working copy)
@@ -6639,7 +6639,10 @@ gfc_match_select_rank (void)
if (expr1->symtree)
{
sym = expr1->symtree->n.sym;
- as = sym->ts.type == BT_CLASS ? CLASS_DATA (sym)->as : sym->as;
+ if (sym->ts.type == BT_CLASS && CLASS_DATA (sym))
+ as = CLASS_DATA (sym)->as;
+ else
+ as = sym->as;
}
if (expr1->expr_type != EXPR_VARIABLE
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Keywords|ice-on-valid-code |
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
Removed keyword. It is an ICE-on-invalid with -std=f95;
code is valid for F2003 and newer.
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (revision 280157)
+++ gcc/fortran/primary.c (working copy)
@@ -2242,7 +2242,12 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag,
sym = NULL;
if (sep == '%' && primary->ts.type != BT_UNKNOWN)
- intrinsic = true;
+ {
+ if (!gfc_notify_std (GFC_STD_F2003,
+ "Invalid type parameter inquiry at %C"))
+ return MATCH_ERROR;
+ intrinsic = true;
+ }
}
else
inquiry = false;
[Bug fortran/95398] New: ICE on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95398 Bug ID: 95398 Summary: ICE on invalid code Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: --- Code posted at https://groups.google.com/forum/#!topic/comp.lang.fortran/mW1gV6tyxXk leads to % gfcx -c a.f90 a.f90:32:16: 32 | foo => array1(2,U) |1 Error: Pointer assignment target is neither TARGET nor POINTER at (1) a.f90:34:16: 34 | foo => array2(2,U) |1 Error: Pointer assignment target is neither TARGET nor POINTER at (1) f951: internal compiler error: Segmentation fault 0xdf6e3a crash_signal ../../gccx/gcc/toplev.c:328 0x83fb5c resolve_select_type ../../gccx/gcc/fortran/resolve.c:9169 0x83c9a4 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gccx/gcc/fortran/resolve.c:11908 0x840f78 resolve_codes ../../gccx/gcc/fortran/resolve.c:17197 0x82ba33 gfc_resolve(gfc_namespace*) ../../gccx/gcc/fortran/resolve.c:17232 0x82ba33 gfc_resolve(gfc_namespace*) ../../gccx/gcc/fortran/resolve.c:17211 0x81de68 resolve_all_program_units ../../gccx/gcc/fortran/parse.c:6241 0x81de68 gfc_parse_file() ../../gccx/gcc/fortran/parse.c:6488 0x871858 gfc_be_parse_file ../../gccx/gcc/fortran/f95-lang.c:210 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. This patch fixes the ICE. Do with it what you want. Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 280157) +++ gcc/fortran/resolve.c (working copy) s@@ -9166,7 +9172,9 @@ resolve_select_type (gfc_code *code, gfc_namespace *ol selector_type = CLASS_DATA (code->expr2)->ts.u.derived; } - if (code->expr2->rank && CLASS_DATA (code->expr1)->as) + if (code->expr2->rank + && code->expr1->ts.type == BT_CLASS + && CLASS_DATA (code->expr1)->as) CLASS_DATA (code->expr1)->as->rank = code->expr2->rank; /* F2008: C803 The selector expression must not be coindexed. */
[Bug fortran/95446] False positive for optional arguments of elemental procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95446
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -2275,11 +2275,27 @@ resolve_elemental_actual (gfc_expr *expr, gfc_code *c)
&& (set_by_optional || arg->expr->rank != rank)
&& !(isym && isym->id == GFC_ISYM_CONVERSION))
{
- gfc_warning (OPT_Wpedantic,
- "%qs at %L is an array and OPTIONAL; IF IT IS "
- "MISSING, it cannot be the actual argument of an "
- "ELEMENTAL procedure unless there is a non-optional "
- "argument with the same rank (12.4.1.5)",
+ bool t = false;
+ gfc_actual_arglist *a;
+
+ /* Scan the argument list for a non-optional argument with the
+same rank as arg. */
+ for (a = arg0; a; a = a->next)
+if (a != arg
+ && a->expr->rank == arg->expr->rank
+ && !a->expr->symtree->n.sym->attr.optional)
+ {
+ t = true;
+ break;
+ }
+
+ if (!t)
+ gfc_warning (OPT_Wpedantic,
+ "%qs at %L is an array with an OPTIONAL attribute; "
+ "If it is not present, than it cannot be the actual "
+ "argument of an ELEMENTAL procedure unless there is "
+ "a non-optional argument with the same rank "
+ "(Fortran 2018, 15.5.2.12)",
arg->expr->symtree->n.sym->name, &arg->expr->where);
}
}
[Bug fortran/95500] Segfault compiling extra interface on intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95500 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Last reconfirmed||2020-06-03 CC||kargl at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 280157) +++ gcc/fortran/trans-expr.c(working copy) @@ -8789,6 +8789,7 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr, if (expr->expr_type == EXPR_FUNCTION && ((expr->value.function.esym + && expr->value.function.esym->result && expr->value.function.esym->result->attr.pointer && !expr->value.function.esym->result->attr.dimension) || (!expr->value.function.esym && !expr->ref
[Bug fortran/95502] ICE in gfc_check_do_variable, at fortran/parse.c:4446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95502
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Last reconfirmed||2020-06-03
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from kargl at gcc dot gnu.org ---
Fixes z1.f90. May fix others.
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (revision 280157)
+++ gcc/fortran/parse.c (working copy)
@@ -4440,6 +4440,9 @@ gfc_check_do_variable (gfc_symtree *st)
{
gfc_state_data *s;
+ if (!st)
+return 0;
+
for (s=gfc_state_stack; s; s = s->previous)
if (s->do_variable == st)
{
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 280157)
+++ gcc/fortran/expr.c (working copy)
@@ -3784,6 +3784,9 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *
int proc_pointer;
bool same_rank;
+ if (!lvalue->symtree)
+return false;
+
lhs_attr = gfc_expr_attr (lvalue);
if (lvalue->ts.type == BT_UNKNOWN && !lhs_attr.proc_pointer)
{
[Bug fortran/95501] ICE in gfc_match_pointer_assignment, at fortran/match.c:1422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95501
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-06-03
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Fixes z1.f90 and z2.90.
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 280157)
+++ gcc/fortran/match.c (working copy)
@@ -1394,7 +1394,7 @@ gfc_match_pointer_assignment (void)
gfc_matching_procptr_assignment = 0;
m = gfc_match (" %v =>", &lvalue);
- if (m != MATCH_YES)
+ if (m != MATCH_YES || !lvalue->symtree)
{
m = MATCH_NO;
goto cleanup;
[Bug fortran/95544] ICE in gfc_can_put_var_on_stack, at fortran/trans-decl.c:494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95544
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
Last reconfirmed||2020-06-04
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from kargl at gcc dot gnu.org ---
There may be a better (or more restrictive) test, but this cures the issues.
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c (revision 280157)
+++ gcc/fortran/intrinsic.c (working copy)
@@ -4428,6 +4428,19 @@ check_arglist (gfc_actual_arglist **ap, gfc_intrinsic_
return false;
}
+ /* F2018, p. 328: An argument to an intrinsic procedure other than
+ASSOCIATED, NULL, or PRESENT shall be a data object. A EXPR_NULL
+is not a data object. */
+ if (actual->expr->expr_type == EXPR_NULL
+ && !(strcmp(gfc_current_intrinsic, "associated") == 0
+ || strcmp(gfc_current_intrinsic, "null") == 0
+ || strcmp(gfc_current_intrinsic, "present") == 0))
+ {
+ gfc_error ("NULL() at %L cannot appear as an actual argument in %qs",
+&actual->expr->where, gfc_current_intrinsic);
+ return false;
+ }
+
/* If the formal argument is INTENT([IN]OUT), check for definability.
*/
if (formal->intent == INTENT_INOUT || formal->intent == INTENT_OUT)
{
[Bug fortran/95544] ICE in gfc_can_put_var_on_stack, at fortran/trans-decl.c:494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95544
--- Comment #3 from kargl at gcc dot gnu.org ---
Updated patch to deal with comments #1.
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c (revision 280157)
+++ gcc/fortran/intrinsic.c (working copy)
@@ -4428,6 +4428,19 @@ check_arglist (gfc_actual_arglist **ap, gfc_intrinsic_
return false;
}
+ /* F2018, p. 328: An argument to an intrinsic procedure other than
+ASSOCIATED, NULL, or PRESENT shall be a data object. A EXPR_NULL
+is not a data object. */
+ if (actual->expr->expr_type == EXPR_NULL
+ && !(strcmp(gfc_current_intrinsic, "associated") == 0
+ || strcmp(gfc_current_intrinsic, "null") == 0
+ || strcmp(gfc_current_intrinsic, "present") == 0))
+ {
+ gfc_error ("NULL() at %L cannot appear as an actual argument in %qs",
+&actual->expr->where, gfc_current_intrinsic);
+ return false;
+ }
+
/* If the formal argument is INTENT([IN]OUT), check for definability.
*/
if (formal->intent == INTENT_INOUT || formal->intent == INTENT_OUT)
{
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 280157)
+++ gcc/fortran/check.c (working copy)
@@ -3444,8 +3444,16 @@ gfc_check_len_lentrim (gfc_expr *s, gfc_expr *kind)
if (!type_check (s, 0, BT_CHARACTER))
return false;
+ if (s->expr_type == EXPR_NULL)
+{
+ gfc_error ("Intrinsic function NULL at %L cannot be an actual "
+"argument to %qs", &s->where, gfc_current_intrinsic);
+ return false;
+}
+
if (!kind_check (kind, 1, BT_INTEGER))
return false;
+
if (kind && !gfc_notify_std (GFC_STD_F2003, "%qs intrinsic "
"with KIND argument at %L",
gfc_current_intrinsic, &kind->where))
@@ -6377,6 +6385,13 @@ gfc_check_trim (gfc_expr *x)
{
if (!type_check (x, 0, BT_CHARACTER))
return false;
+
+ if (x->expr_type == EXPR_NULL)
+{
+ gfc_error ("Intrinsic function NULL at %L cannot be an actual "
+"argument to %qs", &x->where, gfc_current_intrinsic);
+ return false;
+}
if (!scalar_check (x, 0))
return false;
[Bug fortran/95546] Random Fortran test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95546 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to H.J. Lu from comment #1) > It happens with "make -jN check". The Fortran code is correct. If 'make -jN check' is trying to build and execute multiple versions of eof_4.f90 in parallel, then that won't work. Looks like you have a race condition with parallel make.
[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-06-05
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Priority|P3 |P4
--- Comment #1 from kargl at gcc dot gnu.org ---
This allows the code to compile and print 1.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 280157)
+++ gcc/fortran/expr.c (working copy)
@@ -1684,7 +1684,13 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
}
cons = gfc_constructor_lookup (base, limit);
- gcc_assert (cons);
+
+ if (!cons)
+ {
+ t = false;
+ goto cleanup;
+ }
+
gfc_constructor_append_expr (&expr->value.constructor,
gfc_copy_expr (cons->expr), NULL);
}
[Bug fortran/95543] [PDT] ICE in is_CFI_desc, at fortran/expr.c:1080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543 kargl at gcc dot gnu.org changed: What|Removed |Added Summary|ICE in is_CFI_desc, at |[PDT] ICE in is_CFI_desc, |fortran/expr.c:1080 |at fortran/expr.c:1080 Last reconfirmed||2020-06-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Yet, another PDT bug.
[Bug fortran/95543] [PDT] ICE in is_CFI_desc, at fortran/expr.c:1080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543
kargl at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #2 from kargl at gcc dot gnu.org ---
This cures the ICE, which then I believe leads to wrong-code.
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 280157)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -708,7 +708,7 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
are SAVE_NONE but have an initializer. Otherwise explicitly
initialized variables are SAVE_IMPLICIT and explicitly saved are
SAVE_EXPLICIT. */
- if (!sym->attr.use_assoc
+ if (!sym->attr.use_assoc && !sym->attr.pdt_kind && !sym->attr.pdt_len
&& (sym->attr.save != SAVE_NONE || sym->attr.data
|| (sym->value && sym->ns->proc_name->attr.is_main_program)
|| (flag_coarray == GFC_FCOARRAY_LIB
@@ -1554,7 +1554,9 @@ gfc_get_symbol_decl (gfc_symbol * sym)
fun_or_res = byref && (sym->attr.result
|| (sym->attr.function && sym->ts.deferred));
- if ((sym->attr.dummy && ! sym->attr.function) || fun_or_res)
+ if (((sym->attr.dummy && !sym->attr.function)
+ && !(sym->attr.pdt_kind || sym->attr.pdt_len))
+ || fun_or_res)
{
/* Return via extra parameter. */
if (sym->attr.result && byref
[Bug fortran/95585] ICE in gfc_check_reshape, at fortran/check.c:4751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95585
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
Priority|P3 |P4
Last reconfirmed||2020-06-08
Status|UNCONFIRMED |NEW
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 280157)
@@ -4720,7 +4728,8 @@ gfc_check_reshape (gfc_expr *source, gfc_expr *shape,
&& shape->ref->u.ar.as->lower[0]->ts.type == BT_INTEGER
&& shape->ref->u.ar.as->upper[0]->expr_type == EXPR_CONSTANT
&& shape->ref->u.ar.as->upper[0]->ts.type == BT_INTEGER
- && shape->symtree->n.sym->attr.flavor == FL_PARAMETER)
+ && shape->symtree->n.sym->attr.flavor == FL_PARAMETER
+ && shape->symtree->n.sym->value)
{
int i, extent;
gfc_expr *e, *v;
[Bug fortran/95584] ICE in generic_correspondence, at fortran/interface.c:1260
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95584
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 280157)
+++ gcc/fortran/interface.c (working copy)
@@ -1257,7 +1257,7 @@ generic_correspondence (gfc_formal_arglist *f1, gfc_fo
while (f1)
{
- if (f1->sym->attr.optional)
+ if (!f1->sym || f1->sym->attr.optional)
goto next;
if (p1 && strcmp (f1->sym->name, p1) == 0)
[Bug fortran/95586] ICE in gfc_validate_kind, at fortran/trans-types.c:773
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95586
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -4764,7 +4764,7 @@ gfc_match_implicit (void)
/* Last chance -- check (). */
if (ts.type == BT_CHARACTER)
m = gfc_match_char_spec (&ts);
- else
+ else if (ts.type != BT_DERIVED)
{
m = gfc_match_kind_spec (&ts, false);
if (m == MATCH_NO)
[Bug fortran/95611] ICE in access_attr_decl, at fortran/decl.c:9075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95611
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
CC||kargl at gcc dot gnu.org
Last reconfirmed||2020-06-09
Ever confirmed|0 |1
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -8998,7 +8998,7 @@ access_attr_decl (gfc_statement st)
else
{
gfc_error ("Access specification of the .%s. operator at %C "
-"has already been specified", sym->name);
+"has already been specified", uop->name);
goto done;
}
[Bug fortran/95612] [9/10/11 Regression] ICE in gfc_check_pointer_assign, at fortran/expr.c:4274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95612
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 280157)
+++ gcc/fortran/expr.c (working copy)
@@ -4256,7 +4262,20 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *
gfc_symbol *sym;
bool target;
- gcc_assert (rvalue->symtree);
+ if (gfc_is_size_zero_array (rvalue))
+ {
+ gfc_error ("Zero-sized array detected at %L where an entity with "
+"the TARGET attribute is expected", &rvalue->where);
+ return false;
+ }
+ else if (!rvalue->symtree)
+ {
+ gfc_error ("Pointer assignment target in initialization expression "
+"does not have the TARGET attribute at %L",
+&rvalue->where);
+ return false;
+ }
+
sym = rvalue->symtree->n.sym;
if (sym->ts.type == BT_CLASS && sym->attr.class_ok)
[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -5924,7 +5924,7 @@ get_bind_c_idents (void)
found_id = MATCH_YES;
gfc_get_ha_symbol (name, &tmp_sym);
}
- else if (match_common_name (name) == MATCH_YES)
+ else if (gfc_match_common_name (name) == MATCH_YES)
{
found_id = MATCH_YES;
com_block = gfc_get_common (name, 0);
@@ -5969,7 +5969,7 @@ get_bind_c_idents (void)
found_id = MATCH_YES;
gfc_get_ha_symbol (name, &tmp_sym);
}
- else if (match_common_name (name) == MATCH_YES)
+ else if (gfc_match_common_name (name) == MATCH_YES)
{
found_id = MATCH_YES;
com_block = gfc_get_common (name, 0);
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 280157)
+++ gcc/fortran/match.c (working copy)
@@ -5122,7 +5122,8 @@ gfc_get_common (const char *name, int from_module)
/* Match a common block name. */
-match match_common_name (char *name)
+match
+gfc_match_common_name (char *name)
{
match m;
@@ -5174,7 +5175,7 @@ gfc_match_common (void)
for (;;)
{
- m = match_common_name (name);
+ m = gfc_match_common_name (name);
if (m == MATCH_ERROR)
goto cleanup;
Index: gcc/fortran/match.h
===
--- gcc/fortran/match.h (revision 280157)
+++ gcc/fortran/match.h (working copy)
@@ -103,11 +103,8 @@ match gfc_match_call (void);
/* We want to use this function to check for a common-block-name
that can exist in a bind statement, so removed the "static"
- declaration of the function in match.c.
-
- TODO: should probably rename this now that it'll be globally seen to
- gfc_match_common_name. */
-match match_common_name (char *name);
+ declaration of the function in match.c. */
+match gfc_match_common_name (char *name);
match gfc_match_common (void);
match gfc_match_block_data (void);
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -936,9 +936,16 @@ static void
resolve_common_vars (gfc_common_head *common_block, bool named_common)
{
gfc_symbol *csym = common_block->head;
+ gfc_gsymbol *gsym;
for (; csym; csym = csym->common_next)
{
+ gsym = gfc_find_gsymbol (gfc_gsym_root, csym->name);
+ if (gsym && gsym->type != GSYM_UNKNOWN)
+ gfc_error_now ("Global entity %qs at %L cannot appear in a "
+ "COMMON block at %L", gsym->name,
+ &gsym->where, &csym->common_block->where);
+
/* gfc_add_in_common may have been called before, but the reported
errors
have been ignored to continue parsing.
We do the checks again here. */
[Bug fortran/95613] ICE in main_block_label, at tree-cfg.c:1455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95613
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #2 from kargl at gcc dot gnu.org ---
Fortran 66 has not been the standard for 54 years. Time to enforce numbered
constraints in the Fortran 2018 (and older) standard.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -10193,12 +10200,16 @@ resolve_branch (gfc_st_label *label, gfc_code *code)
return;
}
- /* The label is not in an enclosing block, so illegal. This was
- allowed in Fortran 66, so we allow it as extension. No
- further checks are necessary in this case. */
- gfc_notify_std (GFC_STD_LEGACY, "Label at %L is not in the same block "
- "as the GOTO statement at %L", &label->where,
- &code->loc);
+ /* F2018: C1169 (R1157) The label shall be the statement label of a
+ branch target statement that appears in the same inclusive scope
+ as the goto-stmt.
+
+ F2018: C1170 (R1158) Each label in label-list shall be the statement
+ label of a branch target statement that appears in the same inclusive
+ scope as the computed-goto-stmt. */
+
+ gfc_error ("Label at %L is not in the same block as the GOTO statement "
+"at %L", &label->where, &code->loc);
return;
}
[Bug fortran/95631] Unable to redefine a literal with `-std=legacy'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95631 kargl at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |INVALID CC||kargl at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #4 from kargl at gcc dot gnu.org --- I think Eric Korpela may not know the Fortran standards. Yes, old compiler did dumb things, because it was/is difficult to detect this violation of the Fortran standards. Note, these prohibitions are on the programmer. F66 8.4.2 If an actual argument corresponds to a dummy argument that is defined or redefined in the referenced subprogram, the actual argument must be a variable name, an array element name, or an array name. F77 15.9.2 Actual arguments may be constants, symbolic names of constants, function references, expressions involving operators, and expressions enclosed in parentheses if and only if the associated dummy argument is a variable that is not defined during execution of the referenced external procedure.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Depends on||69101 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Bill Long from comment #0) > > cat test.f90 > Gfortran: > > > module swap PrgEnv-intel PrgEnv-gnu > > gfortran test.f90 > > ./a.out > selected_real_kind(16) = 10 > ieee_selected_real_kind(16) = 10 > > The output from gfortran is problematic because ieee_selected_real_kind > should not return 10. If the users want KIND=10 (i.e. the > Intel-proprietary 80-bit x87 floats), then they need to use > selected_real_kind and not the IEEE version. IEEE-754 permits the extended double type (See 3.7 Extended and extendable precisions). I do not see in the Fortran standard that the output from ieee_seleted_real_kind must select binary32, binary64, or binary128. That said, ieee_selected_real_kind is completely broken. See PR69101. I used to have patch that fixed this PR, but never got around to committing it. The patch attached in 69101 is not correct. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101 [Bug 69101] [F03] IEEE_SELECTED_REAL_KIND is not generic
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Thanks for the testcase. gfortran converts the old school .eq. to ==, and then tracks the ==. The module starts with == and so it does not properly overload the .eq. This fixes the issue. Index: libgfortran/ieee/ieee_arithmetic.F90 === --- libgfortran/ieee/ieee_arithmetic.F90(revision 280157) +++ libgfortran/ieee/ieee_arithmetic.F90(working copy) @@ -77,15 +77,16 @@ module IEEE_ARITHMETIC ! Equality operators on the derived types - interface operator (==) + ! Note, the FE overloads .eq. to == and .ne. to /= + interface operator (.eq.) module procedure IEEE_CLASS_TYPE_EQ, IEEE_ROUND_TYPE_EQ end interface - public :: operator(==) + public :: operator(.eq.) - interface operator (/=) + interface operator (.ne.) module procedure IEEE_CLASS_TYPE_NE, IEEE_ROUND_TYPE_NE end interface - public :: operator (/=) + public :: operator (.ne.) ! IEEE_IS_FINITE
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #10 from kargl at gcc dot gnu.org --- (In reply to Steve Kargl from comment #9) > On Thu, Jun 11, 2020 at 10:14:21AM -0700, Steve Kargl wrote: > > > > IEEE-754 calls binary32, 64, 128 the basic formats (Sec. 3, p. 6): > > > > Five basic formats are defined in this clause: > > Three binary formats, with encodings in lengths of 32, 64, and 128 bits. > > Two decimal formats, with encodings in lengths of 64 and 128 bits. > > > > Additional arithmetic formats are recommended for extending these basic > > formats (see 3.7). > > > > If J3 really intended that IEEE_SELECTED_REAL_KIND return a kind for one of > > IEEE-754 basic formats, then it ought to say that. Looks like a defect > > in the Fortran standard. > > > > If one looks into 3.7 (p. 14), it further recommends > > > > Language standards should define mechanisms supporting extendable > > precision for each supported radix. > > > > I have asked on the J3 mailing list if Section 17 should > be restricted to the basic formats. https://mailman.j3-fortran.org/pipermail/j3/2020-June/012148.html Bill, is Malcolm's feedback sufficient? This may fall under some processors may not support the Intel-80 floating point format under Section 17 of the Standard. I'll leave the bug report open for others to chime in. Perhaps, others would rather not have a difference between gfortran and Cray and Intel compilers.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #12 from kargl at gcc dot gnu.org --- (In reply to Bill Long from comment #11) > I checked with the Intel docs and the ia64 version of the compiler (what HPC > users use) does not support x87. > > Is there a gfortran compiler option to disable x87 use (i.e. REAL(10) is an > error), to match the other compilers? The types are set up in trans-type.c(gfc_init_kinds). I do not see an option that would disable querying for long_double_type_node. In principle, one might be able to define an option that prevents gfortran from see a long_double_type_node. This should then disable REAL(10). Looking at configure options, there is a --with-long-double-128 option but I've never used it. Don't know if it will disable REAL(10). It appears linux specific.
[Bug fortran/95708] [9/10/11 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95708
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2020-06-16
Status|UNCONFIRMED |NEW
--- Comment #1 from kargl at gcc dot gnu.org ---
Built and tested against submitted code. Not regression tested.
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c (revision 280157)
+++ gcc/fortran/intrinsic.c (working copy)
@@ -2733,7 +2733,8 @@ add_functions (void)
make_generic ("null", GFC_ISYM_NULL, GFC_STD_F95);
- add_sym_2 ("num_images", GFC_ISYM_NUM_IMAGES, CLASS_INQUIRY, ACTUAL_NO,
+ add_sym_2 ("num_images", GFC_ISYM_NUM_IMAGES, CLASS_TRANSFORMATIONAL,
+ACTUAL_NO,
BT_INTEGER, di, GFC_STD_F2008,
gfc_check_num_images, gfc_simplify_num_images, NULL,
dist, BT_INTEGER, di, OPTIONAL,
@@ -3174,7 +3175,7 @@ add_functions (void)
make_generic ("tanh", GFC_ISYM_TANH, GFC_STD_F77);
add_sym_1 ("team_number", GFC_ISYM_TEAM_NUMBER, CLASS_TRANSFORMATIONAL,
-ACTUAL_YES, BT_INTEGER, di, GFC_STD_F2018,
+ACTUAL_NO, BT_INTEGER, di, GFC_STD_F2018,
gfc_check_team_number, NULL, gfc_resolve_team_number,
team, BT_DERIVED, di, OPTIONAL);
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -12937,6 +12937,7 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
{
if (arg->sym
&& arg->sym->ts.type == BT_DERIVED
+ && arg->sym->ts.u.derived
&& !arg->sym->ts.u.derived->attr.use_assoc
&& !gfc_check_symbol_access (arg->sym->ts.u.derived)
&& !gfc_notify_std (GFC_STD_F2003, "%qs is of a PRIVATE type "
[Bug fortran/95718] [8/9/10/11 Regression] Wrong pointer associated status without initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95718 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- 16.5.2.2 Pointer association status A pointer may have a pointer association status of associated, disassociated, or undefined. Its association status may change during execution of a program. Unless a pointer is initialized (explicitly or by default), it has an initial association status of undefined. A pointer may be initialized to have an association status of disassociated or associated. 13.7.16 ASSOCIATED (POINTER [, TARGET]) POINTER shall be a pointer. It may be of any type or may be a procedure pointer. Its pointer association status shall not be undefined. Your program is invalid.
[Bug fortran/95709] [9/10/11 Regression] ICE in gfc_resolve_code, at fortran/resolve.c:11807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95709
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -11740,7 +11740,8 @@ start:
case EXEC_GOTO:
if (code->expr1 != NULL)
{
- if (code->expr1->ts.type != BT_INTEGER)
+ if (code->expr1->expr_type == EXPR_CONSTANT
+ || code->expr1->ts.type != BT_INTEGER)
gfc_error ("ASSIGNED GOTO statement at %L requires an "
"INTEGER variable", &code->expr1->where);
else if (code->expr1->symtree->n.sym->attr.assign != 1)
[Bug fortran/95710] ICE in gfc_type_is_extensible, at fortran/resolve.c:8848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95710
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
Tested against z1.f90. Untested otherwise. I don't use CLASSes.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -8798,6 +8798,9 @@ resolve_select (gfc_code *code, bool select_type)
bool
gfc_type_is_extensible (gfc_symbol *sym)
{
+ if (!sym)
+return false;
+
return !(sym->attr.is_bind_c || sym->attr.sequence
|| (sym->attr.is_class
&& sym->components->ts.u.derived->attr.unlimited_polymorphic));
@@ -12595,9 +12599,13 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag)
&& !UNLIMITED_POLY (sym)
&& !gfc_type_is_extensible (CLASS_DATA (sym)->ts.u.derived))
{
- gfc_error ("Type %qs of CLASS variable %qs at %L is not extensible",
-CLASS_DATA (sym)->ts.u.derived->name, sym->name,
-&sym->declared_at);
+ if (CLASS_DATA (sym)->ts.u.derived)
+ gfc_error ("Type %qs of CLASS variable %qs at %L is not
extensible",
+CLASS_DATA (sym)->ts.u.derived->name,
+ sym->name, &sym->declared_at);
+ else
+ gfc_error ("CLASS variable %qs at %L is not extensible",
+ sym->name, &sym->declared_at);
return false;
}
[Bug fortran/30372] various intrinsics do not diagnose invalid argument kinds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #10 from kargl at gcc dot gnu.org --- The non-standard SLEEP intrinsic subroutine is documented as taking a default integer argument. This patch enforces this restriction. Index: gcc/fortran/check.c === --- gcc/fortran/check.c (revision 280157) +++ gcc/fortran/check.c (working copy) @@ -5588,6 +5588,9 @@ gfc_check_sleep_sub (gfc_expr *seconds) if (!scalar_check (seconds, 0)) return false; + if (!kind_value_check (seconds, 0, gfc_default_integer_kind)) + return false; + return true; }
[Bug fortran/30372] various intrinsics do not diagnose invalid argument kinds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #10)
> The non-standard SLEEP intrinsic subroutine is documented as taking a
> default integer argument. This patch enforces this restriction.
>
> Index: gcc/fortran/check.c
> ===
> --- gcc/fortran/check.c (revision 280157)
> +++ gcc/fortran/check.c (working copy)
> @@ -5588,6 +5588,9 @@ gfc_check_sleep_sub (gfc_expr *seconds)
>if (!scalar_check (seconds, 0))
> return false;
>
> + if (!kind_value_check (seconds, 0, gfc_default_integer_kind))
> + return false;
> +
>return true;
> }
Perhaps, a better patch. This effectively makes SLEEP a generic
procedure by converting the SECONDS argument to default integer
kind.
Index: gcc/fortran/iresolve.c
===
--- gcc/fortran/iresolve.c (revision 280157)
+++ gcc/fortran/iresolve.c (working copy)
@@ -3699,14 +3699,19 @@ void
gfc_resolve_sleep_sub (gfc_code *c)
{
const char *name;
- int kind;
+ gfc_typespec ts;
+ gfc_expr *n;
+ gfc_clear_ts (&ts);
- if (c->ext.actual->expr != NULL)
-kind = c->ext.actual->expr->ts.kind;
- else
-kind = gfc_default_integer_kind;
+ /* The argument to SLEEP has to be of default kind. If it is not,
+ we convert it. */
+ ts.type = BT_INTEGER;
+ ts.kind = gfc_default_integer_kind;
+ n = c->ext.actual->expr;
+ if (n != NULL && n->ts.kind != ts.kind)
+gfc_convert_type (n, &ts, 2);
- name = gfc_get_string (PREFIX ("sleep_i%d_sub"), kind);
+ name = gfc_get_string (PREFIX ("sleep_i%d_sub"), ts.kind);
c->resolved_sym = gfc_get_intrinsic_sub_symbol (name);
}
Index: gcc/fortran/intrinsic.texi
===
--- gcc/fortran/intrinsic.texi (revision 280157)
+++ gcc/fortran/intrinsic.texi (working copy)
@@ -13557,7 +13557,8 @@ Subroutine
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
-@item @var{SECONDS} @tab The type shall be of default @code{INTEGER}.
+@item @var{SECONDS} @tab @var{SECONDS} shall be scalar with an
+@code{INTEGER} type.
@end multitable
@item @emph{Example}:
[Bug fortran/30372] various intrinsics do not diagnose invalid argument kinds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
--- Comment #12 from kargl at gcc dot gnu.org ---
This makes the UMASK intrinsic function generic by converting the input
argument to default integer kind and calling the relevant libgfortran function.
Index: gcc/fortran/iresolve.c
===
--- gcc/fortran/iresolve.c (revision 280157)
+++ gcc/fortran/iresolve.c (working copy)
@@ -3314,6 +3314,14 @@ gfc_resolve_ucobound (gfc_expr *f, gfc_expr *array, gf
void
gfc_resolve_umask (gfc_expr *f, gfc_expr *n)
{
+ if (n->ts.kind != gfc_default_integer_kind)
+{
+ gfc_typespec ts;
+ ts.type = BT_INTEGER;
+ ts.kind = gfc_default_integer_kind;
+ gfc_convert_type (n, &ts, 2);
+}
+
f->ts.type = BT_INTEGER;
f->ts.kind = n->ts.kind;
f->value.function.name = gfc_get_string (PREFIX ("umask_i%d"), n->ts.kind);
The UMASK subroutine is completely broken and requires a much different
approach to fix the problem. Namely, the subroutine has an optional
intent(out) argument. This needs to be dealt with in trans-intrinsic.c
[Bug fortran/30372] various intrinsics do not diagnose invalid argument kinds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
--- Comment #13 from kargl at gcc dot gnu.org ---
This patch makes the UMASK subroutine a generic subprogram. This is
accomplished by converting its arguments to INTEGER(4), call
_gfortran_umask_i4_sub, and converting the OLD argument back to an appropriate
integer kind. Don't know if it works with -fdefault-real-8, but who cares.
That option should be removed from gfortran.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 280157)
+++ gcc/fortran/check.c (working copy)
@@ -7236,6 +7236,14 @@ gfc_check_umask_sub (gfc_expr *mask, gfc_expr *old)
if (!type_check (old, 1, BT_INTEGER))
return false;
+ if (old->expr_type != EXPR_VARIABLE
+ || (old->symtree && old->symtree->n.sym
+ && old->symtree->n.sym->attr.intent == INTENT_IN))
+{
+ gfc_error ("OLD at %L shall be an INTENT(OUT) variable", &old->where);
+ return false;
+}
+
return true;
}
Index: gcc/fortran/intrinsic.texi
===
--- gcc/fortran/intrinsic.texi (revision 280157)
+++ gcc/fortran/intrinsic.texi (working copy)
@@ -14795,9 +14795,10 @@ corresponding to the lower cobound of the array along
@table @asis
@item @emph{Description}:
-Sets the file creation mask to @var{MASK}. If called as a function, it
-returns the old value. If called as a subroutine and argument @var{OLD}
-if it is supplied, it is set to the old value. See @code{umask(2)}.
+Sets the file creation mask to @var{MASK}.
+If called as a function, it returns the old value.
+If called as a subroutine, and @var{OLD} is present,
+it sets @var{OLD} to the previous value.
@item @emph{Standard}:
GNU extension
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 280157)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -212,12 +212,13 @@ tree gfor_fndecl_convert_char4_to_char1;
/* Other misc. runtime library functions. */
-tree gfor_fndecl_size0;
-tree gfor_fndecl_size1;
tree gfor_fndecl_iargc;
+tree gfor_fndecl_is_contiguous0;
tree gfor_fndecl_kill;
tree gfor_fndecl_kill_sub;
-tree gfor_fndecl_is_contiguous0;
+tree gfor_fndecl_size0;
+tree gfor_fndecl_size1;
+tree gfor_fndecl_umask_sub;
/* Intrinsic functions implemented in Fortran. */
@@ -3635,6 +3636,10 @@ gfc_build_intrinsic_function_decls (void)
gfor_fndecl_iargc = gfc_build_library_function_decl (
get_identifier (PREFIX ("iargc")), gfc_int4_type_node, 0);
TREE_NOTHROW (gfor_fndecl_iargc) = 1;
+
+ gfor_fndecl_umask_sub = gfc_build_library_function_decl (
+ get_identifier (PREFIX ("umask_i4_sub")), void_type_node,
+ 2, gfc_pint4_type_node, gfc_pint4_type_node);
gfor_fndecl_kill_sub = gfc_build_library_function_decl (
get_identifier (PREFIX ("kill_sub")), void_type_node,
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (revision 280157)
+++ gcc/fortran/trans-intrinsic.c (working copy)
@@ -9138,7 +9138,51 @@ conv_intrinsic_kill_sub (gfc_code *code)
}
+/* Translate a call to the UMASK subroutine. */
+static tree
+conv_intrinsic_umask_sub (gfc_code *code)
+{
+ stmtblock_t block;
+ gfc_se se, se_old;
+ tree int4_type_node = gfc_get_int_type (4);
+ tree mask;
+ tree oldp = NULL_TREE;
+ tree tmp;
+
+ /* Make the function call. */
+ gfc_init_block (&block);
+ gfc_init_se (&se, NULL);
+
+ /* Convert mask to an INTEGER(4) entity. */
+ gfc_conv_expr (&se, code->ext.actual->expr);
+ gfc_add_block_to_block (&block, &se.pre);
+ mask = fold_convert (int4_type_node, gfc_evaluate_now (se.expr, &block));
+ gfc_add_block_to_block (&block, &se.post);
+
+ /* Deal with an optional OLD. */
+ if (code->ext.actual->next->expr)
+{
+ gfc_init_se (&se_old, NULL);
+ gfc_conv_expr (&se_old, code->ext.actual->next->expr);
+ oldp = gfc_create_var (int4_type_node, "_oldp");
+}
+
+ tmp = build_call_expr_loc (input_location, gfor_fndecl_umask_sub, 2,
+gfc_build_addr_expr (NULL_TREE, mask),
+oldp ? gfc_build_addr_expr (NULL_TREE, oldp)
+ : null_pointer_node);
+
+ gfc_add_expr_to_block (&block, tmp);
+
+ if (oldp && oldp != se_old.expr)
+gfc_add_modify (&block, se_old.expr,
+ fold_convert (TREE_TYPE (se_old.expr), oldp));
+
+ return gfc_finish_block (&block);
+}
+
+
/* The loc intrinsic returns the address of its argument as
gfc_index_integer_kind integer. */
@@ -11899,6 +11943,10 @@ gfc_conv_intrinsic_subroutine (gfc_code *code)
case GFC_ISYM_KI
[Bug fortran/95829] Bogus error with additional blanks in type(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95829
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
Last reconfirmed||2020-06-22
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -4069,7 +4069,7 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int implic
gfc_gobble_whitespace ();
if (gfc_peek_ascii_char () == '*')
{
- if ((m = gfc_match ("*)")) != MATCH_YES)
+ if ((m = gfc_match ("* ) ")) != MATCH_YES)
return m;
if (gfc_comp_struct (gfc_current_state ()))
{
[Bug fortran/95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95837 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > The problem seems more serious. > > type t > character(len=:, kind=4), pointer :: str2 > end type t > type(t) :: var > character(len=:, kind=4), pointer :: str > > print *, kind(str), kind(var%str2) > str(1:1) = 4_"a" > end > > result > > % ./a.out >4 4 Yes, there is a serious problem with the Fortran code! str is an undefined pointer. The line 'str(1:1) = 4_"a"' is invalid.
[Bug fortran/95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95837 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #2) > (In reply to Dominique d'Humieres from comment #1) > > The problem seems more serious. > > > > type t > > character(len=:, kind=4), pointer :: str2 > > end type t > > type(t) :: var > > character(len=:, kind=4), pointer :: str > > > > print *, kind(str), kind(var%str2) > > str(1:1) = 4_"a" > > end > > > > result > > > > % ./a.out > >4 4 > > Yes, there is a serious problem with the Fortran code! > > str is an undefined pointer. The line 'str(1:1) = 4_"a"' > is invalid. In fact, after a quick scan of the Fortran 2018 standard. The PR is likely invalid. Allocation on assignment applies to ALLOCATABLE variables not undefined or disassociated pointers. Yep. Definitely invalid. Fortran 2018, 10.2.1.2 Intrinsic assignment statement p. 160 If the variable is a pointer, it shall be associated with a definable target such that the type, type parameters, and shape of the target and expr conform.
[Bug fortran/95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95837 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Keywords|wrong-code | --- Comment #4 from kargl at gcc dot gnu.org --- Remove "wrong-code" keyword.
[Bug fortran/95880] [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95880 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > This is due to a change in GCC11 that have been back ported to GCC9 and 10 > (pr94397?). It is NOT pr94397.
[Bug middle-end/95939] [11 Regression] ice with -O3 in compute_live_loop_exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95939 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Component|fortran |middle-end --- Comment #3 from kargl at gcc dot gnu.org --- Change component as this appears to not be Fortran specific.
[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #2 from kargl at gcc dot gnu.org ---
Patch is against svn r280156.
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 280157)
+++ gcc/fortran/match.c (working copy)
@@ -6174,7 +6174,10 @@ build_class_sym:
{
/* The correct class container has to be available. */
assoc_sym->ts.type = BT_CLASS;
- assoc_sym->ts.u.derived = CLASS_DATA (selector)->ts.u.derived;
+ if (CLASS_DATA (selector)->ts.u.derived != NULL)
+assoc_sym->ts.u.derived = CLASS_DATA (selector)->ts.u.derived;
+ else
+assoc_sym->ts.u.derived = selector->ts.u.derived;
assoc_sym->attr.pointer = 1;
gfc_build_class_symbol (&assoc_sym->ts, &assoc_sym->attr,
&assoc_sym->as);
}
[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 kargl at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-06-29
[Bug fortran/95981] ICE in gfc_find_array_ref(): No ref found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95981
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-06-29
Priority|P3 |P4
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Patch is against svn revision 280156.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 280157)
+++ gcc/fortran/check.c (working copy)
@@ -1137,7 +1137,9 @@ dim_rank_check (gfc_expr *dim, gfc_expr *array, int al
if (array->expr_type == EXPR_VARIABLE)
{
- ar = gfc_find_array_ref (array);
+ ar = gfc_find_array_ref (array, true);
+ if (!ar)
+ return false;
if (ar->as->type == AS_ASSUMED_SIZE
&& !allow_assumed
&& ar->type != AR_ELEMENT
[Bug fortran/96011] ICE in check_function_name, at fortran/decl.c:2429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96011 kargl at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||kargl at gcc dot gnu.org Last reconfirmed||2020-06-30 --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #0) > Seems to be an old issue : > > > $ cat z1.f90 > program p > contains >type(t) function f() > external f.n >end > end With svn r 2810156, I get the following: mobile:kargl[243] gfcx -c -std=f2018 z1.f90 a.f90:3:3: 3 |type(t) function f() | 1 4 | external f.n | 2 Error: RESULT variable 'f' at (1) prohibits FUNCTION name 'f' at (2) from appearing in a specification statement z1.f90:3:21: 3 |type(t) function f() | 1 Error: Bad kind expression for function 'f' at (1) f951: internal compiler error: Segmentation fault 0x89dfbbc crash_signal ../../gcc/gcc/toplev.c:328 0x8428132 resolve_symbol ../../gcc/gcc/fortran/resolve.c:15382 0x8452c4f do_traverse_symtree ../../gcc/gcc/fortran/symbol.c:4165
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- I'm not sure that this is valid code. The result variable 't' is neither declared nor set in the function. A type cannot not be a result variable.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-06-30
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #3 from kargl at gcc dot gnu.org ---
The code is invalid. Patch against svn revision 280156.
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 280157)
+++ gcc/fortran/module.c(working copy)
@@ -5738,7 +5738,11 @@ write_symbol (int n, gfc_symbol *sym)
const char *label;
if (sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
-gfc_internal_error ("write_symbol(): bad module symbol %qs", sym->name);
+{
+ gfc_error ("Invalid symbol %qs at %L", sym->name,
+&sym->declared_at);
+ return;
+}
mio_integer (&n);
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #3)
> The code is invalid. Patch against svn revision 280156.
>
> Index: gcc/fortran/module.c
> ===
> --- gcc/fortran/module.c (revision 280157)
> +++ gcc/fortran/module.c (working copy)
> @@ -5738,7 +5738,11 @@ write_symbol (int n, gfc_symbol *sym)
>const char *label;
>
>if (sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
> -gfc_internal_error ("write_symbol(): bad module symbol %qs", sym->name);
> +{
> + gfc_error ("Invalid symbol %qs at %L", sym->name,
> + &sym->declared_at);
> + return;
> +}
>
>mio_integer (&n);
The patch is wrong and Gerhard is sort of correct. z1.f90 is
invalid as the result variable is never set. But, an internal
error should not be signaled. Fortran 2018 has
19.5.1.4 Host association
A name that appears in the scoping unit as
...
(12) a result-name in a function-stmt or in an entry-stmt,
...
is a local identifier in the scoping unit and any entity of the host
that has this as its nongeneric name is inaccessible by that name by
host association.
So, the type 't' is inaccessible in the local scope of f(). The code
is a good example for the requirement of 'implicit none'.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> (In reply to kargl from comment #3)
> > The code is invalid. Patch against svn revision 280156.
> >
> > Index: gcc/fortran/module.c
> > ===
> > --- gcc/fortran/module.c(revision 280157)
> > +++ gcc/fortran/module.c(working copy)
> > @@ -5738,7 +5738,11 @@ write_symbol (int n, gfc_symbol *sym)
> >const char *label;
> >
> >if (sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
> > -gfc_internal_error ("write_symbol(): bad module symbol %qs",
> > sym->name);
> > +{
> > + gfc_error ("Invalid symbol %qs at %L", sym->name,
> > +&sym->declared_at);
> > + return;
> > +}
> >
> >mio_integer (&n);
>
> The patch is wrong and Gerhard is sort of correct. z1.f90 is
> invalid as the result variable is never set. But, an internal
> error should not be signaled. Fortran 2018 has
>
> 19.5.1.4 Host association
>
> A name that appears in the scoping unit as
> ...
> (12) a result-name in a function-stmt or in an entry-stmt,
> ...
> is a local identifier in the scoping unit and any entity of the host
> that has this as its nongeneric name is inaccessible by that name by
> host association.
>
> So, the type 't' is inaccessible in the local scope of f(). The code
> is a good example for the requirement of 'implicit none'.
Note, if 't' is actually set to a value, then the code compiles
module m
type t
end type
contains
function f() result(t)
character(3) :: c
c = 'abc'
t = 1
end
end
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013
--- Comment #6 from kargl at gcc dot gnu.org ---
With this patch the code compiles:
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 280157)
+++ gcc/fortran/module.c(working copy)
@@ -5737,8 +5737,13 @@ write_symbol (int n, gfc_symbol *sym)
{
const char *label;
- if (sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
-gfc_internal_error ("write_symbol(): bad module symbol %qs", sym->name);
+ if ((sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
+ && !(sym->ts.type != BT_UNKNOWN && sym->attr.result))
+{
+ gfc_error ("Invalid symbol %qs at %L", sym->name,
+&sym->declared_at);
+ return;
+}
mio_integer (&n);
As far as setting 't', one can get a warning with -Wall.
gfcx -Wall -c a.f90
a.f90:5:25:
5 |function f() result(t)
| 1
Warning: Return value 't' of function 'f' declared at (1) not set
[-Wreturn-typ]
Not sure why this isn't an error (perhaps, false-positives?).
[Bug fortran/96025] [9/10/11 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/96025] [9/10/11 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
This fixes the ICE. Patch is against svn revision 280156.
e-ts.u.cl is a garbage pointer.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 280157)
+++ gcc/fortran/expr.c (working copy)
@@ -3447,6 +3447,7 @@ gfc_specification_expr (gfc_expr *e)
{
gfc_error ("Expression at %L must be of INTEGER type, found %s",
&e->where, gfc_basic_typename (e->ts.type));
+ gfc_clear_ts (&e->ts);
return false;
}
[Bug fortran/96024] [9/10/11 Regression] ICE in mio_name_expr_t, at fortran/module.c:2159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- The patch in PR 95025 fixes this issue.
[Bug fortran/96024] [9/10/11 Regression] ICE in mio_name_expr_t, at fortran/module.c:2159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/52279] Fortran translation issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to CVS Commits from comment #1)
> The master branch has been updated by Mark Eggleston
> :
>
> https://gcc.gnu.org/g:0a7183f6d173cbd69025a3deb30d16f91e6392b2
>
> commit r11-1764-g0a7183f6d173cbd69025a3deb30d16f91e6392b2
> Author: Mark Eggleston
> Date: Tue Jun 2 08:38:01 2020 +0100
>
> Fortran : Fortran translation issues PR52279
>
> Mark strings for translation by enclosing in G_() and _().
>
> 2020-06-24 Mark Eggleston
>
> gcc/fortran/
>
> PR fortran/52279
> * arith.c (reduce_binary_aa): Mark for translation the string
> parameter to gfc_check_conformance with G_().
> * check.c (gfc_invalid_boz): Mark hint for translation using
> _(). (gfc_check_achar): Mark for translation the message
> parameter to gfc_invalid_boz using G_(). (gfc_check_char):
> Mark for translation the message parameter to gfc_invalid_boz
> using G_(). (gfc_check_complex): Mark for translation the
> message parameter to gfc_invalid_boz using G_().
> (gfc_check_float): Mark for translation the message
> parameter to gfc_invalid_boz using G_(). (check_rest): Mark
> for translation the string parameter to gfc_check_conformance
> with _(). (gfc_check_minloc_maxloc): Mark for translation
> the string parameter to gfc_check_conformance with _().
> (gfc_check_findloc): Mark for translation the string parameter
> to gfc_check_conformance with _(). (check_reduction): Mark
> for translation the string parameter to gfc_check_conformance
> with _(). (gfc_check_pack): Mark for translation the string
> parameter to gfc_check_conformance with _().
> * decl.c (match_old_style_init): Mark for translation the
> message parameter to gfc_invalid_boz using G_().
> * expr.c (gfc_check_assign): Mark for translation the string
> parameter to gfc_check_conformance with _().
> * intrinsic.c (check_specific): Mark for translation the string
> parameter to gfc_check_conformance with _().
> (gfc_check_intrinsic_standard): Mark symstd_msg strings for
> translation using G_(). No need to mark symstd_msg for
> translation in call to gfc_warning or when setting symstd.
> * io.c (check_open_constraints): Mark strings for translation
> using G_() in all calls to warn_or_error. (match_io_element):
> Mark for translation the message parameter to gfc_invalid_boz
> using G_().
> * primary.c (match_boz_constant): Mark for translation the
> message parameter to gfc_invalid_boz using G_().
> * resolve.c (resolve_elemental_actual): Mark for translation
> the string parameter to gfc_check_conformance with _().
> (resolve_operator): Mark for translation the string parameter
> to gfc_check_conformance with _(). Mark translation strings
> assigned to msg using G_() for use in a call to cfg_warning.
I believe that this is wrong
@@ -67,7 +67,7 @@ gfc_invalid_boz (const char *msg, locus *loc)
return false;
}
- const char hint[] = " [see %<-fno-allow-invalid-boz%>]";
+ const char hint[] = _(" [see %<-fno-allow-invalid-boz%>]");
fortan/lang.opt RejectNegative for allow-invalid-boz. There
is no option -fno-allow-invalid-boz.
% gfcx -fno-allow-invalid-boz -c a.f90
gfortran: error: unrecognized command-line option '-fno-allow-invalid-boz'; did
you mean '-fallow-invalid-boz'?
[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Sylvain Korzennik from comment #2) > Merci Dominique. > > Will transmit info to MVAPICH2 ppl. > > The configuration script needs to be changed, this is not "faulty code", it > is a test code part of the package configuration specifically to test if the > "Fortran compiler gfortran will compile files that call the same routine > with arguments of different types". It is faulty code according to the Fortran standard. It's been faulty code since it was written. Fortran 66 8.3.2 Referencing External Functions. An external function is referenced by using its reference (5.2) as a primary in an arithmetic or logical expression. The actual arguments, which constitute the argument list, must agree in order, number, and type with the corresponding dummy argumets in the defining program unit. 8.4.2 Referencing Subroutines. A subroutine is referenced by a CALL statement (7.1.2.4). The actual arguments, which constitute the argument list, must agree in order, number, and type with the corresponding dummy arguments in the defining subprogram. Modern Fortran allows a programmer to write a generic interfaces, which allows one to handle this situation in a standard conforming way. > Backward compatibility of gfortran is dismal (legacy code that builds fine > w/ plethora of other fortran compiler fails to build w/ gfortran - ppl were > writing fortran code for quite a wile, like one big scientific package > started 60+ years ago, yet gfortran is the one that can't handle it - ifort > and pgfortran do fine, it was written/developed on a VAX/VMS back when - > author have long retired - desn't make the code obsolete, tho). URLs to the actual code, please. All that unnamed legacy code violates the Fortran standard in one or more ways. gfortran, unlikely the plethora of compilers, is not a garbage disposal.
[Bug fortran/52279] Fortran translation issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to markeggleston from comment #5) > (In reply to markeggleston from comment #4) > > Regarding comment 2. > > > > Using -fallow-invalid-boz results in an ICE. I'll create a new PR. > > Not true, tried it on the wrong file and jumped to the wrong conclusion. This is wrong. index 26ea01f..8ecf4ff 100644 (file) --- a/gcc/fortran/check.c +++ b/gcc/fortran/check.c @@ -67,7 +67,7 @@ gfc_invalid_boz (const char *msg, locus *loc) return false; } - const char hint[] = " [see %<-fno-allow-invalid-boz%>]"; + const char *hint = " [see %<-fno-allow-invalid-boz%>]"; size_t len = strlen (msg) + strlen (hint) + 1; char *msg2 = (char *) alloca (len); strcpy (msg2, msg); There is no -fno-allow-invalid-boz option. The option is -fallow-invalid-boz. fortan/lang.opt defines the options with the RejectNegative annotation.
[Bug fortran/96038] New: Confirming implicitly type parameter causes an invalid error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96038
Bug ID: 96038
Summary: Confirming implicitly type parameter causes an invalid
error
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: kargl at gcc dot gnu.org
Target Milestone: ---
Consider the following fixed-form source code:
function ifoo()
parameter (n = 50)
integer n
ifoo = n
end
Everything is implicitly type. Gfortran gives
function ifoo()
parameter (n = 50)
integer n
ifoo = n
end
% gfortran -c a.f
a.f:3:15:
3 | integer n
| 1
Error: PARAMETER at (1) is missing an initializer
which is wrong. The code should compile as an implicitly type
entity can appear in a declaration statement if that declaration
statement confirms the implicit type.
The patch is straight forward. This is against svn revision 280156.
The patch has not been regression tested.
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -1864,13 +1864,16 @@ add_init_expr_to_sym (const char *name, gfc_expr **ini
/* If this symbol is confirming an implicit parameter type,
then an initialization expression is not allowed. */
- if (attr.flavor == FL_PARAMETER
- && sym->value != NULL
- && *initp != NULL)
+ if (attr.flavor == FL_PARAMETER && sym->value != NULL)
{
- gfc_error ("Initializer not allowed for PARAMETER %qs at %C",
-sym->name);
- return false;
+ if (*initp != NULL)
+ {
+ gfc_error ("Initializer not allowed for PARAMETER %qs at %C",
+sym->name);
+ return false;
+ }
+ else
+ return true;
}
if (init == NULL)
[Bug fortran/96038] Confirming implicitly type parameter causes an invalid error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96038 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2020-07-02 Ever confirmed|0 |1
[Bug fortran/96102] ICE in check_host_association, at fortran/resolve.c:5994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96102
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
Priority|P3 |P4
Last reconfirmed||2020-07-07
Status|UNCONFIRMED |NEW
--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -5899,6 +5899,15 @@ check_host_association (gfc_expr *e)
&& sym->attr.flavor == FL_PROCEDURE
&& sym->attr.contained)
{
+
+ if (old_sym->attr.flavor == FL_VARIABLE
+ && sym->attr.proc == PROC_INTERNAL)
+ {
+ gfc_error ("Internal procedure %qs at %L has already been "
+"used as a variable", sym->name, &sym->declared_at);
+ return false;
+ }
+
/* Clear the shape, since it might not be valid. */
gfc_free_shape (&e->shape, e->rank);
