[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #5) > (In reply to anlauf from comment #3) > > The same text existed in F2018, so it is not new: F2018:C7103 and Note 1. > > > > Either every compiler developer team misunderstood that clause, or we > > need an interp, based on the example, to be able to convince all of them. > > > > (I know of developers who do overwrite default constructors, and it > > currently > > works "everywhere", so clarification is important.) > > > > What do you think? > > I sent an email to the J3 mailing list > > https://mailman.j3-fortran.org/pipermail/j3/2024-March/014649.html > > I included a question whether keywords can be used. See mailing list for response. gfortran's current behavior appears corrects with the possible exception that gfortran does not detect and report the violation of a numbered constraint. Perhaps, a warning should be emitted under -Wall or -Wsurprising.
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #3) > The same text existed in F2018, so it is not new: F2018:C7103 and Note 1. > > Either every compiler developer team misunderstood that clause, or we > need an interp, based on the example, to be able to convince all of them. > > (I know of developers who do overwrite default constructors, and it currently > works "everywhere", so clarification is important.) > > What do you think? I sent an email to the J3 mailing list https://mailman.j3-fortran.org/pipermail/j3/2024-March/014649.html I included a question whether keywords can be used.
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #3) > The same text existed in F2018, so it is not new: F2018:C7103 and Note 1. > > Either every compiler developer team misunderstood that clause, or we > need an interp, based on the example, to be able to convince all of them. > > (I know of developers who do overwrite default constructors, and it currently > works "everywhere", so clarification is important.) > > What do you think? I don't have other compilers to check, but I think my interpretation of F2023:C7108 was intended to prevent ambiguity. Note, F2003:C489 is nearly verbatim with F2023:c7108. So, this goes back years as a constraint. I forgot to mention that I found this at https://fortran-lang.discourse.group/t/type-mismatch-in-literal-constant-constructor-for-derived-type-allowed/7669
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #1) > Can you be a little more explicit? > > If I extend the program as follows: > > type(params) :: p > p = params( 0.1, 2.0 ) > write(*,*) p > p = params( 0.1, 2 ) > write(*,*) p > > I get with all compilers I have access to (Intel, NAG, Nvidia, flang, > gfortran) > > Not the structure constructor > 0.10001 4. > 0.10001 2. > > This is what I would have naively expected in accordance with "Note 1": > > The form ’name(...)’ is interpreted as a generic function-reference if > possible; it is interpreted as a structure-constructor only if it cannot > be interpreted as a generic function-reference. > > which gives a precedence to function-reference over structure-constructor, > making it possible to override the default constructor. > > Are you saying that one cannot override the default constructor? I thought C7108 was clear. C7108 (R756) If derived-type-spec is a type name that is the same as a generic name, the component-spec-list shall not be a valid actual-arg-spec-list for a function reference that is resolvable as a generic reference to that name (15.5.5.2). The derived-type-spec is 'params'. The generic name is 'params'. The component-spec-list for the derived type in 'p = params(3.0,2.0)' has types of 'real' and 'real'. The generic reference is 'p = params(3.0,2.0)', which resolves to 'default_params'. 'default_params' has an actual-arg-spec-list with types of 'real' and 'real'. Thus, 'params(real,real)' is ambiguous. Is it the structure constructor or a generic function reference? Note, you cannot use keywords as the components of the derive type 'params' are 'x' and 'y', and the dummy arguments for 'default_params' are also 'x' and 'y'. Finally, 'p = params(3,2.0)' is a structure constructor, because the generic interface does not include a function with types of 'integer' and 'real'. Thus, here, this is not a function reference. It must be a structure constructor. The rules of intrinsic assignment are now in play, and 'params(3,2.0)' is treated as 'params(3.0,2.0)' after type conversion. Of course, I could be wrong.
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/114438] New: Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 Bug ID: 114438 Summary: Missed constraint F2023:c7108 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: --- Created attachment 57785 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57785=edit Fortran 2023:C7108 violation Gfortran does not diagnosis F2023:C7108. C7108 (R756) If derived-type-spec is a type name that is the same as a generic name, the component-spec-list shall not be a valid actual-arg-spec-list for a function reference that is resolvable as a generic reference to that name (15.5.5.2). The attached program compiles and execute where the generic function is resolved to a function.
[Bug fortran/105547] No further "Unclassifiable statement" after the first one if multiple syntax errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Mikael Morin from comment #2) > Created attachment 57739 [details] > Patch fixing the problem > > This small patch fixes the problem. > Unfortunately allowing more errors seems counter-productive here. > As seen in the testsuite changes, the additional errors have little value, > and add more noise than anything else. > I'm tempted to close this as WONTFIX. I like your approach to limit the run-on errors. I am, however, of the mind that if gfortran gets to the "Unclassifiable error" message, that perhaps, this should be a fatal error.
[Bug fortran/114188] Overloading assignment does not invalidate intrinsic assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114188 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Priority|P3 |P4 Last reconfirmed||2024-03-01 Keywords||accepts-invalid, wrong-code Ever confirmed|0 |1 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to ba...@lrz.de from comment #2) > You note that > > > Unfortunately, the five requirements in 10.2.1.4 for defined assignment > > do not say anything about argument association. > > Hmm, one could see this as "intentionally" instead of "unfortunately": If > the requirements in 10.2.1.4 are fulfilled, then a defined assignment exists. >> > The consequences are: > > (1) the intrinsic assignment becomes unavailable (because the last sentence > in > 10.2.1.1 establishes a mutual exclusion). > > (2) Any further details on how the subroutine is set up must be appropriately > handled by the programmer (e.g., supplying POINTER objects in my > example's > LHS) - this is what is meant by "The interpretation of a defined > assignment is > provided by the subroutine that defines it". The NOTE appearing later to me does not seem germane to the question at hand. > > While my starting assumption may be wrong, the other compilers' behaviour is > consistent with it. > I wasn't assuming that you were wrong and I've read enough of your posts in J3 mailing list to trust your interpretation. You've confirmed a few of my suspicions on how you were reading the standard. Hopefully, the clarity will help whomever jumps down the rabbit hole to fix the bug.
[Bug fortran/114188] Overloading assignment does not invalidate intrinsic assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114188 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 ba...@lrz.de from comment #0) > Created attachment 57583 [details] > test case for invalid use of assignment overloading > > The attached reproducer overloads the assignment operator with a version > that requires the left hand side to be a pointer. > > The overload conforms to the requirements for defining the assignment > according to 10.2.1.4 of the Fortran standard. Therefore, the intrinsic > assignment should become unavailable (last sentence of 10.2.1.1). > > However, gfortran accepts invocations that use nonpointer arguments. > > (NAG Fortran, Intel Fortran and NVidia Fortran issue appropriate error > messages). Can you provide a bit more detail in your interpretation of F2023? The last sentence in 10.2.1.1 is 1 An assignment-stmt shall meet the requirements of either a defined assignment statement or an intrinsic assignment statement. If I comment out your 'interface assignment(=)' block, then 'b = a' is an intrinsic assignment. If I replace 'b = a' with the direct call to 'ass', I see a.f90:26:12: 26 |call ass(b, a) |1 Error: Actual argument for ‘to’ at (1) must be a pointer or a valid target for the dummy pointer in a pointer assignment statement which seems to be the error that you want. The question is then if the source of this error can be interpreted such that 'b = a' in your original code is in fact not a defined assignment, and therefore, it is an intrinsic assignment (last sentence in 10.2.1.1). 10.2.1.5 has 1 The interpretation of a defined assignment is provided by the subroutine that defines it. and the NOTE in this section contains The rules of defined assignment (15.4.3.4.3), ... 15.4.3.4.3 goes into some detail about argument association. These rules seem to be the source of the above error when 'ass' is called directed. Unfortunately, the five requirements in 10.2.1.4 for defined assignment do not say anything about argument association.
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P4 |P5 Severity|normal |enhancement --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to Mikael Morin from comment #4) > (In reply to kargl from comment #3) > > Yep, agreed. I went back an re-read the section about ASSOCIATE. > > Not sure how I convinced myself that a constant expression, which > > reduces to a constant is okay. > > > Not sure how you convinced yourself it isn't. ;-) x => log(cmplx(-1,0)) R1104 association is associate-name => selector R1105 selector is expr or variable R902 variable is designator or function-reference R901 designatoris object-name or array-element or array-section or coindexed-named-object or complex-part-designator or structure-component or substring log(cmplx(-1,0)) is certainly not a designator. log(cmplx(-1,0)) is a function-reference. But this then leads to C902 (R902) function-reference shall have a data pointer result. log(cmplx(-1,0)) violates C902, so this then means that it must be an expr. One now needs R915 complex-part-designator is designator % RE or designator % IM C922 (R915) The designator shall be of complex type. which shows that expr%im is invalid; even though log(cmplx(-1,0)) reduces to a constant (i.e., it's not a named constant. This is likely the error [pun intended] in my ways.). Sometimes the trees get in the way of seeing the forest. Arguably, the error message is wrong gfortran13 -c a.f90 a.f90:6:13: 6 | y = x%im | 1 Error: Symbol 'x' at (1) has no IMPLICIT type 'x' has the type of COMPLEX. The version of the code where Jerry wraps log(cmplx(-1,0)) in parentheses. Generates a better error message $ gfc pr114141.f90 pr114141.f90:6:14: 6 | y = x%im | 1 Error: The RE or IM part_ref at (1) must be applied to a COMPLEX expression but this is still wrong in that RE and IM are applied to a designator. I'll leave the PR open has an enhancement request.
[Bug fortran/114146] REPEATABLE argument of RANDOM_INIT and repeated execution of the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114146 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Last reconfirmed||2024-02-28 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Severity|normal |minor CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- gfortran's implementation matches the wording of the Fortran 2023 standard. Case (i): CALL RANDOM_INIT (REPEATABLE=true, IMAGE_DISTINCT=true) is equivalent to invoking RANDOM_SEED with a processor-dependent value for PUT that is different on every invoking image. In each execution of the program with the same execution environment, if the invoking image index value in the initial team is the same, the value for PUT shall be the same. Looks like someone needs to update the gfortran manual.
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #2) > It looks like the 'selector' in this case is an expr. > > The expr must be a pointer object or a 'designator' > > A designator must be: > > R901 > designator > > object-name > array-element > array-section > coindexed-named-object > complex-part-designator > structure-component > substring > > I am not seeing the expr in the example as one of these listed. ??? Yep, agreed. I went back an re-read the section about ASSOCIATE. Not sure how I convinced myself that a constant expression, which reduces to a constant is okay. I suppose the question is "do we generate a better error message or simply close the PR?"
[Bug fortran/99837] ICE in parse_associate, at fortran/parse.c:4780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99837 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #1) > Similar cases with "select type" instead : > > $ cat z3.f90 > program p >type t > integer, allocatable :: a(:) >end type >class(t) :: x[:] >select type (y => x) >end select > end > > $ cat z4.f90 > program p >type t > integer, allocatable :: a(:) >end type >class(t) :: x[*] >select type (y => x) >end select > end These test still fail.
[Bug fortran/99837] ICE in parse_associate, at fortran/parse.c:4780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99837 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING CC||kargl at gcc dot gnu.org Last reconfirmed||2024-02-28 Ever confirmed|0 |1 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #0) > Follow-up of pr88357, affects versions down to at least r5. > With a missing attribute allocatable or pointer : > > $ cat z1.f90 > program p >type t > integer, allocatable :: a(:) >end type >class(t) :: x[:] >associate (y => x) >end associate > end This now gives % gfcx -o z -fcoarray=single a.f90 a.f90:6:19: 6 |class(t) :: x[:] | 1 Error: Coarray variable 'x' at (1) shall not have codimensions with deferred shape > $ cat z2.f90 > program p >type t > integer, allocatable :: a(:) >end type >class(t) :: x[*] >associate (y => x) >end associate > end This gives % gfcx -o z -fcoarray=single a.f90 a.f90:6:19: 6 |class(t) :: x[*] | 1 Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer
[Bug fortran/114141] New: ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
Bug ID: 114141
Summary: ASSOCIATE and complex part ref when associate target
is a function
Product: gcc
Version: 14.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: ---
Created attachment 57556
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57556=edit
patch
gfortran rejects the following code with an invalid error message.
The problem is that the target is not resolved to have type
COMPLEX. The attach patch rectifies the issue. It has been regtested
on x86_64-*-freebsd.
! { dg-do run }
program foo
implicit none
real y
associate (x => log(cmplx(-1,0)))
y = x%im
if (int(100*y)-314 /= 0) stop 1
end associate
end program
gfortran13 -c a.f90
a.f90:6:13:
6 | y = x%im
| 1
Error: Symbol 'x' at (1) has no IMPLICIT type
troutmask:sgk[244]
[Bug fortran/77504] [11/12/13/14 Regression] "is used uninitialized" with allocatable string and array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Depends on||106089 --- Comment #32 from kargl at gcc dot gnu.org --- (In reply to Walter Spector from comment #31) > Super simple test case: > > wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran --version > GNU Fortran (GCC) 14.0.1 20240115 (experimental) > Copyright (C) 2024 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > wws@w6ws-4:~/computer/fortran/tests$ cat a.f90 > program catenate_test > implicit none > > integer, allocatable :: a(:) > > a = (/ 1, 3, 5 /) > > print *, 'size(a) =', size (a) > print *, 'a =', a > > end program > wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran -o a a.f90 > wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran -Wall -o a a.f90 > a.f90:6:19: > > 6 | a = (/ 1, 3, 5 /) > | ^ > Warning: ‘a.offset’ is used uninitialized [-Wuninitialized] > a.f90:4:30: > > 4 | integer, allocatable :: a(:) > | ^ > note: ‘a’ declared here > a.f90:6:19: > > 6 | a = (/ 1, 3, 5 /) > | ^ > Warning: ‘a.dim[0].lbound’ is used uninitialized [-Wuninitialized] > a.f90:4:30: > > 4 | integer, allocatable :: a(:) > | ^ > note: ‘a’ declared here > a.f90:6:19: > > 6 | a = (/ 1, 3, 5 /) > | ^ > Warning: ‘a.dim[0].ubound’ is used uninitialized [-Wuninitialized] > a.f90:4:30: > > 4 | integer, allocatable :: a(:) > | ^ > note: ‘a’ declared here > a.f90:6:19: > > 6 | a = (/ 1, 3, 5 /) > | ^ > Warning: ‘a.dim[0].lbound’ may be used uninitialized [-Wmaybe-uninitialized] > a.f90:4:30: > > 4 | integer, allocatable :: a(:) > | ^ > note: ‘a’ declared here > a.f90:6:19: > > 6 | a = (/ 1, 3, 5 /) > | ^ > Warning: ‘a.dim[0].ubound’ may be used uninitialized [-Wmaybe-uninitialized] > a.f90:4:30: > > 4 | integer, allocatable :: a(:) > | ^ > note: ‘a’ declared here > wws@w6ws-4:~/computer/fortran/tests$ ./a > size(a) = 3 > a = 1 3 5 > wws@w6ws-4:~/computer/fortran/tests$ See ttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089 [Bug 106089] false positives with -Wuninitialized for allocation on assignment
[Bug fortran/114023] complex part%ref of complex named constant array cannot be used in an initialization expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114023 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #1 from kargl at gcc dot gnu.org --- This one is a bit uglier. For the testcase, program foo implicit none complex(kind=8), parameter :: cmp1(3) = [(1,2),(3,4),(5,6)] real :: rr(3) = cmp1%re if (any(int(rr) /= [1,3,5])) then print '(3(F4.1))', rr stop 1 end if end one gets an ICE % gfcx -o z a.f90 && ./z a.f90:5:11: 5 | program foo | 1 internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.cc:6662 0x6eb2cf gfc_conv_array_initializer(tree_node*, gfc_expr*) ../../gccx/gcc/fortran/trans-array.cc:6662 This caused by the insertion of a conversion function __convert_r8_r4() into the initializer where gfc_conv_array_initializer() is not prepared to hand it. Now, if the type declaration of rr is changed to 'real(8)', then a conversion function is not inserted but wrong code is generated. I suspect that we need to go code spelunking in resolve.cc.
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 --- Comment #3 from kargl at gcc dot gnu.org --- Created attachment 57482 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57482=edit patch The attached patch fixes this PR. It includes a new testcase and passes regression testing.
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #2 from kargl at gcc dot gnu.org ---
This is ugly. Essentially, the translation of an allocate statement is
mot prepared to have a complex-part-ref as the source expression. For this
code
program foo
implicit none
complex :: cmp(3)
real, allocatable :: xx(:), yy(:), zz(:)
cmp = (3.45,6.78)
allocate (xx, source = cmp%re) ! ICE
allocate (yy, source = cmp(1:3)%re) ! ICE
allocate (zz, source = (cmp%re))
print *, xx
print *, yy
print *, zz
end
The lines marked with ICE will cause gfortran to, well, ICE. The
following patch cures the issues by impose a set of parentheses
about the source expression. There is likely a better way.
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 5247d3d39d7..6ff3f12d7ed 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6355,8 +6355,24 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist
*omp_allocate)
vtab_needed = (al->expr->ts.type == BT_CLASS);
gfc_init_se (, NULL);
- /* When expr3 is a variable, i.e., a very simple expression,
-then convert it once here. */
+
+ /* When expr3 is a variable, i.e., a very simple expression, then
+convert it once here. Note, if one has source = z%re or z%im,
+then things can go sideways with the complex-part-ref, so wrap
+the entity in parentheses to force evaluation of an expression.
+That is, the else-branch of the ensuing if-else-stmt is entered. */
+
+ if (code->expr3->ref
+ && ((code->expr3->ref->u.i == INQUIRY_RE
+ || code->expr3->ref->u.i == INQUIRY_IM)
+ || (code->expr3->ref->type == REF_ARRAY
+ && code->expr3->ref->u.ar.type == AR_SECTION)))
+ {
+ gfc_expr *etmp = gfc_get_parentheses (code->expr3);
+ code->expr3 = gfc_copy_expr (etmp);
+ gfc_free_expr (etmp);
+ }
+
if (code->expr3->expr_type == EXPR_VARIABLE
|| code->expr3->expr_type == EXPR_ARRAY
|| code->expr3->expr_type == EXPR_CONSTANT)
[Bug fortran/114024] New: ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 Bug ID: 114024 Summary: ICE allocate statement with source=cmp%re and z an array Product: gcc Version: 14.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: --- Found with the Fujitsu testsuite. The complex part%ref is a rank-1 array with dimension=3. xx should be allocated and assigned [3.45,3.45, 3.45] ! ! https://github.com/fujitsu/compiler-test-suite ! Modified from Fortran/0093/0093_0130.f90 ! implicit none complex:: cmp(3) real, allocatable::xx(:) cmp = (3.45,6.78) allocate (xx, source = cmp%re) end gfcx -c 0093/0093_0130.f90 0093/0093_0130.f90:10:36: 10 | allocate (xx, source = cmp(1:3)%re) |1 internal compiler error: in retrieve_last_ref, at fortran/trans-array.cc:6197 0x6e889a retrieve_last_ref(gfc_ref**, gfc_ref**) ../../gccx/gcc/fortran/trans-array.cc:6197 0xa34c20 gfc_array_allocate(gfc_se*, gfc_expr*, tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, tree_node**, gfc_expr*, tree_node*, bool, gfc_omp_namelist*) ../../gccx/gcc/fortran/trans-array.cc:6290 0xacce0b gfc_trans_allocate(gfc_code*, gfc_omp_namelist*) ../../gccx/gcc/fortran/trans-stmt.cc:6850 0xa25b49 trans_code ../../gccx/gcc/fortran/trans.cc:2535 0xa5ca15 gfc_generate_function_code(gfc_namespace*) ../../gccx/gcc/fortran/trans-decl.cc:7875 0x9cc496 translate_all_program_units ../../gccx/gcc/fortran/parse.cc:7073 0x9cc496 gfc_parse_file()
[Bug fortran/114023] New: complex part%ref of complex named constant array cannot be used in an initialization expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114023 Bug ID: 114023 Summary: complex part%ref of complex named constant array cannot be used in an initialization expression. Product: gcc Version: 14.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: --- Found with the Fujitsu testsuite. The original code led to an ICE, but the modified version here compiles and executes. It is however wrong-code as the testcase stops at STOP 1. ! ! https://github.com/fujitsu/compiler-test-suite ! Modified from Fortran/0093/0093_0025.f90 ! complex(kind=8), parameter :: cmp1(3) = [(1,2),(3,4),(5,6)] complex(kind=16), parameter :: cmp2(3) = [(1,2),(3,4),(5,6)] real(8) :: rr(3) = cmp1%re real(8) :: qq(3) = cmp1%im real(16) :: rr2(3) = cmp2%re real(16) :: qq2(3) = cmp2%im if (any(int(rr) /= [1,3,5])) stop 1 if (any(int(qq) /= [2,4,6])) stop 2 if (any(int(rr2) /= [1,3,5])) stop 3 if (any(int(qq2) /= [2,4,6])) stop 4 end Modifying the code to output rr shows % gfcx -o z 0093/0093_0036.f90 && ./z 1.2.0.
[Bug fortran/114022] New: ICE with a complex part%ref and nested structure constructor of complex array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114022 Bug ID: 114022 Summary: ICE with a complex part%ref and nested structure constructor of complex array. Product: gcc Version: 14.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: --- Found with the Fujitsu testsuite. The complex part%ref in the first if-stmt leads to an ICE. Likely, the nested structure constructor is not setting the value of zz correctly. ! ! https://github.com/fujitsu/compiler-test-suite ! Reduced from Fortran/0093/0093_0025.f90 ! module m1 type ty complex :: cmp1(2) end type ty type tt type(ty) :: obj end type tt type(tt), parameter :: obj2 = tt(ty([(2,3),(3,5)])) end module m1 use m1, only : obj2 real :: rr(2) = obj2%obj%cmp1%re if (rr(1) .ne. 2) stop 1 if (rr(2) .ne. 3) stop 2 end % gfcx -c 0093/0093_0025.f90 0093/0093_0025.f90:15:22: 15 |use m1, only : obj2 | 1 internal compiler error: Segmentation fault 0x109b292 crash_signal ../../gccx/gcc/toplev.cc:317 0x248c5f37f handle_signal /usr/src/lib/libthr/thread/thr_sig.c:301 0x248c5e9b7 thr_sighandler /usr/src/lib/libthr/thread/thr_sig.c:244 0xa74904 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gccx/gcc/fortran/trans-expr.cc:9634 0xa45a6d gfc_conv_array_initializer(tree_node*, gfc_expr*) ../../gccx/gcc/fortran/trans-array.cc:6546 0xa745ab gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool)
[Bug fortran/114021] New: ICE with allocation of scalar pointer entity where SOURCE=f() with f() returning a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114021 Bug ID: 114021 Summary: ICE with allocation of scalar pointer entity where SOURCE=f() with f() returning a pointer Product: gcc Version: 14.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: --- Note sure if this is legal Fortran, but it leads to an ICE. Reduced testcase from Fujitsu testsuite. ! ! https://github.com/fujitsu/compiler-test-suite ! Reduced from 0077/0077_0005.f90 ! module m1 type y integer, allocatable:: x1(:) end type type(y), target :: w integer :: c = 0 contains function f() type(y), pointer :: f f => w c = c + 1 end function end subroutine s2 use m1 ! type(y), allocate :: x ! This ICEs as well type(y), pointer :: x allocate(x, source = f()) end use m1 call s2 if (c /= 1) stop end % gfcx -o z 0077/0077_0005.f90 0077/0077_0005.f90:21:28: 21 |allocate(x, source = f()) |1 internal compiler error: Segmentation fault 0x109b292 crash_signal ../../gccx/gcc/toplev.cc:317 0x2470c137f handle_signal /usr/src/lib/libthr/thread/thr_sig.c:301 0x2470c09b7 thr_sighandler /usr/src/lib/libthr/thread/thr_sig.c:244 0xacea7d tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gccx/gcc/tree.h:3611 0xacea7d gfc_trans_allocate(gfc_code*, gfc_omp_namelist*) ../../gccx/gcc/fortran/trans-stmt.cc:6672
[Bug fortran/114020] New: ENTRY and procedure pointer leads to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114020 Bug ID: 114020 Summary: ENTRY and procedure pointer leads to ICE Product: gcc Version: 14.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: --- Found with the Fujitsu testsuite. Reduced testcase. Note, if the use of ENTRY is replace with an actual function, ie., 'function kmr_fixfun() result(zz)" the code compiles and executes correctly. ! ! https://github.com/fujitsu/compiler-test-suite ! Reduced from Fortran/0071/0071_0018.f90 ! module xxxf contains subroutine sub end subroutine function kmr_fixfun2() result(zz) entry kmr_fixfun() result(zz) procedure(sub), pointer :: zz zz => null() end function integer function foo() result(zz) procedure(sub), pointer :: fp fp => kmr_fixfun() zz = 0 end function foo end module xxxf use xxxf if (foo() /= 0) stop end % gfcx -o z 0071/0071_0018.f90 0071/0071_0018.f90:8:3: 8 |function kmr_fixfun2() result(zz) | ^ internal compiler error: in fold_convert_loc, at fold-const.cc:2633 0x741511 fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gccx/gcc/fold-const.cc:2633 0xd650c9 gimplify_modify_expr ../../gccx/gcc/gimplify.cc:6356 0xd4e52c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int)
[Bug fortran/114019] New: allocation with source of deferred character length entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114019 Bug ID: 114019 Summary: allocation with source of deferred character length entity Product: gcc Version: 14.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: --- Found this issues with the Fujitsu testsuite. The code is reduced to the minimum required. If I had to guess, gfc_charlen for source= is not set correctly. ! ! https://github.com/fujitsu/compiler-test-suite ! Reduced from Fortran/0069/0069_0037.f90 ! implicit none character(:), pointer :: chr_pointer00 character(5), pointer :: chr_pointer01 character(1) :: w_character01 = "4" allocate(chr_pointer00, source="123"//w_character01//"56") allocate(chr_pointer01, source="123"//w_character01//"5") print *,'pass' end % gfcx -c 0069/0069_0037.f90 0069/0069_0037.f90:9:60: 9 | allocate(chr_pointer00, source="123"//w_character01//"56") |^ Error: size of variable 'source.2' is too large 0069/0069_0037.f90:10:59: 10 | allocate(chr_pointer01, source="123"//w_character01//"5") | ^ Error: size of variable 'source.5' is too large during RTL pass: expand 0069/0069_0037.f90:9:60: 9 | allocate(chr_pointer00, source="123"//w_character01//"56") |^ internal compiler error: in lhd_incomplete_type_error, at langhooks.cc:208 0x77ff6f lhd_incomplete_type_error(unsigned int, tree_node const*, tree_node const ../../gccx/gcc/langhooks.cc:208 0x13c00aa size_in_bytes_loc(unsigned int, tree_node const*) ../../gccx/gcc/tree.cc:3601 0x13c00aa size_in_bytes_loc(unsigned int, tree_node const*) ../../gccx/gcc/tree.cc:3589
[Bug fortran/113997] Bogus 'Warning: Interface mismatch in global procedure' with C binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997 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 --- Can you provide a complete minimum example? It seems that your description conflicts with Fortran 2023, 19.2 Global identifiers. 1 ... entities with binding labels ... are global entities of a program. ... The name of ... external procedure with no binding label ... is a global identifier. ... A binding label of an entity of the program is a global identifier. 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.
[Bug fortran/113883] allocatable length parameter used but is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883 kargl at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-12 Status|UNCONFIRMED |NEW Priority|P3 |P4
[Bug fortran/113883] allocatable length parameter used but is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883 --- Comment #1 from kargl at gcc dot gnu.org --- Created attachment 57389 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57389=edit patch to fix bug This is the patch and testcase. I have successfully bootstrapped and run the Fortran regression tests without issues.
[Bug fortran/113883] New: allocatable length parameter used but is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883
Bug ID: 113883
Summary: allocatable length parameter used but is undefined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: kargl at gcc dot gnu.org
Target Milestone: ---
All,
I stumbled across the following issue with my code. Consider,
! { dg-do compile }
! { dg-options "-Werror -Wall" }
module foo
contains
subroutine bar
character(len=:), allocatable :: s(:)
call bah(s)
end subroutine bar
end module foo
Currently, if this compiled with '-Werror -Wall' the result is
% gfcx -Wall -Werror -c gcc/testsuite/gfortran.dg/allocatable_length.f90
gcc/testsuite/gfortran.dg/allocatable_length.f90:6:46:
6 | character(len=:), allocatable :: s(:)
| ^
Error: '.s' is used uninitialized [-Werror=uninitialized]
gcc/testsuite/gfortran.dg/allocatable_length.f90:5:20:
5 | subroutine bar
|^
note: '.s' was declared here
f951: all warnings being treated as errors
I tracked down the location where the issue occurs and Mikael suggested
the patch that ultimately fixes the issue. I'll attach it in a follow-up.
[Bug sanitizer/113881] New: Multiple testsuite failures with gfortran on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113881 Bug ID: 113881 Summary: Multiple testsuite failures with gfortran on FreeBSD Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- % gmake bootstrap % cd gcc % gmake check-fortran ... Inspection of testsuite/gfortran/gfortran.sum on x86_64-*-freebsd shows PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O0 (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O0 execution test PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O1 (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O1 execution test PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O2 (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O2 execution test PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O3 -g (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O3 -g execution test PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -Os (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -Os execution test PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O0 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O0 execution test PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O1 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O1 execution test PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O2 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O2 execution test PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O3 -g (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O3 -g execution test PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -Os (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -Os execution test PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O0 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O0 execution test PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O1 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O1 execution test PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O2 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O2 execution test PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O3 -g (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O3 -g execution test PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -Os (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -Os execution test Digging into testsuite/gfortran/gfortran.log the failure are all of the form spawn -ignore SIGHUP /usr/home/kargl/gcc/obj/gcc/testsuite/gfortran/../../gfortran -B/usr/home/kargl/gcc/obj/gcc/testsuite/gfortran/../../ -B/usr/home/kargl/gcc/obj/x86_64-unknown-freebsd15.0/./libgfortran/ /home/kargl/gcc/gcc/gcc/testsuite/gfortran.dg/asan/pointer_assign_16.f90 -fdiagnostics-plain-output -B/usr/home/kargl/gcc/obj/x86_64-unknown-freebsd15.0/./libsanitizer/ -B/usr/home/kargl/gcc/obj/x86_64-unknown-freebsd15.0/./libsanitizer/asan/ -B/usr/home/kargl/gcc/obj/x86_64-unknown-freebsd15.0/./libsanitizer/asan/.libs -B/usr/home/kargl/gcc/obj/x86_64-unknown-freebsd15.0/./libstdc++-v3/src/.libs -fsanitize=address -g
[Bug fortran/113866] ice in generic_simplify_COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866 kargl at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-02-10 Ever confirmed|0 |1 Priority|P3 |P4 Status|UNCONFIRMED |NEW CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Reduced testcase. module bindcchar contains subroutine bindc_optional(c1, c3) bind(c) character(*), optional :: c1, c3(100) print *, c1(1:3), c3(5)(1:3) end subroutine subroutine not_bindc_optional(c1, c3) character(*), optional :: c1, c3(100) call bindc_optional(c1, c3) end subroutine end module Note, the OPTIONAL attribute is required to cause the ICE. Note, -Wall generates a few warnings. Perhaps, these should be errors. % gfcx -c -Wall fr.f90 fr.f90:5:34: 5 | subroutine bindc_optional(c1, c3) bind(c) | 1 Warning: Variable ‘c1’ at (1) is a dummy argument of the BIND(C) procedure ‘bindc_optional’ but may not be C interoperable [-Wc-binding-type] fr.f90:5:38: 5 | subroutine bindc_optional(c1, c3) bind(c) | 1 Warning: Variable ‘c3’ at (1) is a dummy argument of the BIND(C) procedure ‘bindc_optional’ but may not be C interoperable [-Wc-binding-type] fr.f90:12:36: 12 | call bindc_optional(c1, c3) |1
[Bug fortran/113845] ice in gfc_get_array_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113845 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #2) > (In reply to kargl from comment #1) > > Thanks. Reduce test case. > > > > subroutine test_adjustl(x) > > character(*) :: x(100) > > call bar(adjustl(x)) > > end subroutine > > Forcing gfc_simplify_adjustl to return NULL fixes this issue. > Likely, simplification trashes the stack because ubound is > unknown. Whoops, after compiling I ran the wrong test code through gfortran. This appears to be a red-herring. :(
[Bug fortran/113845] ice in gfc_get_array_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113845 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #1) > Thanks. Reduce test case. > > subroutine test_adjustl(x) > character(*) :: x(100) > call bar(adjustl(x)) > end subroutine Forcing gfc_simplify_adjustl to return NULL fixes this issue. Likely, simplification trashes the stack because ubound is unknown.
[Bug fortran/113845] ice in gfc_get_array_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113845 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-09 Ever confirmed|0 |1 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Thanks. Reduce test case. subroutine test_adjustl(x) character(*) :: x(100) call bar(adjustl(x)) end subroutine subroutine test_adjustr(x) character(*) :: x(100) call bar(adjustr(x)) end subroutine On FreeBSD either subroutine causes % gfcx -c rt.f90 pid 50109 comm f951 has trashed its stack, killing gfortran: internal compiler error: Illegal instruction signal terminated program f951 Please submit a full bug report, with preprocessed source (by using -freport-bug Note, I have % limits | grep stack stacksize 524288 kB
[Bug fortran/113823] ice in gfc_get_element_type, at fortran/trans-types.cc:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to David Binderman from comment #2) > (In reply to kargl from comment #1) > > (In reply to David Binderman from comment #0) > > > > > > This is the second ice from the flang test suite. > > > > If you're keep score > > https://discourse.llvm.org/t/proposal-rename-flang-new-to-flang/69462/57 > > Interesting. Thanks. > > 32 more ice to be reported. There are probably some duplicates > amongst that group. > > Hopefully I can report most or all of these before the next release. If you do post the others, is it possible to include a URL to LLVM repository? This will allow us to give proper credit for the code.
[Bug fortran/113823] ice in gfc_get_element_type, at fortran/trans-types.cc:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823 kargl at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-08 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to David Binderman from comment #0) > > This is the second ice from the flang test suite. If you're keep score https://discourse.llvm.org/t/proposal-rename-flang-new-to-flang/69462/57 Confirmed.
[Bug fortran/113671] Passing allocatable character(:) slices with negative stride: invalid memory access / segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113671 kargl at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 CC||kargl at gcc dot gnu.org Last reconfirmed||2024-01-30 Status|UNCONFIRMED |NEW Priority|P3 |P4 --- Comment #1 from kargl at gcc dot gnu.org --- Reduced testcase. program arrays10 implicit none character(:), allocatable :: b(:) allocate(character(len=1) :: b(1)) ! <- remove a bunch of uninitialized ! <-1 -Wall warnings. b = [ character(5) :: "one", "two", "three"] call test03(b(size(b):1:-1)) contains subroutine test03(a) character(*), intent(in) :: a(*) print *, "testing: ", rank(a), size(a(:3)), len(a(1)) end subroutine test03 end program arrays10
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #15 from kargl at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #14)
> On Sun, Jan 21, 2024 at 09:52:39PM +, anlauf at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
> >
> > I think that you cannot do
> >
> > + if (MPFR_HALF_CYCLE)
> >
> > you really must use
> >
> > #if MPFR_HALF_CYCLE
> >
>
...
> Breakpoint 1, gfc_simplify_cospi (x=0x803e24b60)
> at ../../gcc/gcc/fortran/simplify.cc:2085
> 2085 result = gfc_get_constant_expr (x->ts.type, x->ts.kind, >where);
> (gdb) n
> 2101 mpfr_inits2 (2 * mpfr_get_prec (x->value.real), cs, n, r,
> NULL);
Good news is that your testing forced me to look at the
else-{} branch again, and it exposed a shortcoming. I'm
looking at a fix. So an updated patch will be necessary.
[Bug fortran/57360] Implement a warning for implied save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360
--- Comment #7 from kargl at gcc dot gnu.org ---
Upon some additional thinking, I wonder how useful this will be compared
to the possible volume of warning messages from modern Fortran. Consider
this code:
module foo
integer :: j = 2
type a
integer :: k = 3
end type
type(a) :: b = a(4)
integer, target :: n
integer, pointer :: m => n
end module foo
subroutine t()
integer :: i=1
write(6,*) i
i=i+1
end subroutine t
call t()
call t()
end
with the patch at the end of this email, I see
% gfcx -c -Wsurprising -Wall a.f90
a.f90:2:14:
2 |integer :: j = 2
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:6:14:
6 |type(a) :: b = a(4)
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:7:22:
7 |integer, target :: n
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:8:23:
8 |integer, pointer :: m => n
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:12:13:
12 | integer :: i=1
| 1
Warning: ‘i’ at (1) has an implicit SAVE attribute [-Wsurprising]
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 503ecb8d9b5..d6ef37e51f2 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2278,7 +2278,12 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
sym->value = init;
if (sym->attr.save == SAVE_NONE)
- sym->attr.save = SAVE_IMPLICIT;
+ {
+ sym->attr.save = SAVE_IMPLICIT;
+ if (warn_surprising)
+ gfc_warning (OPT_Wsurprising, "%qs at %L has an implicit SAVE "
+ "attribute", sym->name, >declared_at);
+ }
*initp = NULL;
}
@@ -5868,7 +5873,12 @@ match_attr_spec (void)
|| gfc_current_state () == COMP_SUBMODULE)
&& !current_attr.save
&& (gfc_option.allow_std & GFC_STD_F2008) != 0)
-current_attr.save = SAVE_IMPLICIT;
+{
+ current_attr.save = SAVE_IMPLICIT;
+ if (warn_surprising)
+ gfc_warning (OPT_Wsurprising, "Entity at %C has an implicit SAVE "
+"attribute");
+}
colon_seen = 1;
return MATCH_YES;
[Bug fortran/57360] Implement a warning for implied save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #6 from kargl at gcc dot gnu.org ---
With this patch,
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 503ecb8d9b5..abb3579893f 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2278,7 +2278,12 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
sym->value = init;
if (sym->attr.save == SAVE_NONE)
- sym->attr.save = SAVE_IMPLICIT;
+ {
+ sym->attr.save = SAVE_IMPLICIT;
+ if (warn_surprising)
+ gfc_warning (OPT_Wsurprising, "Entity %qs at %L has an implicit "
+ "SAVE attribute", sym->name, >declared_at);
+ }
*initp = NULL;
}
I see
% gfcx -o z a.f90 -Wsurprising && ./z
a.f90:2:13:
2 | integer :: i=1
| 1
Warning: Entity ‘i’ at (1) has an implicit SAVE attribute [-Wsurprising]
1
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 kargl at gcc dot gnu.org changed: What|Removed |Added Attachment #56949|0 |1 is obsolete|| Attachment #56950|0 |1 is obsolete|| Attachment #56951|0 |1 is obsolete|| Attachment #56952|0 |1 is obsolete|| Attachment #56956|0 |1 is obsolete|| --- Comment #12 from kargl at gcc dot gnu.org --- Created attachment 57179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57179=edit Patch Here is a new patch. It includes an implementation for the half-cycle trigonometric functions as well as fixes for PR113412 -- better error message for atan(y,x) PR113413 -- implement atand(y,x) Here's text that may be suitable formatted for a ChangeLog. gfortran: * gfortran.h (gfc_isym_id): Add GFC_ISYM_ACOSPI, GFC_ISYM_ASINPI, GFC_ISYM_ATANPI, GFC_ISYM_ATAN2PI, GFC_ISYM_COSPI, GFC_ISYM_SINPI, and GFC_ISYM_TANPI * intrinsic.cc (do_check): Whitespace and typo in comments. (add_functions): Add two-argument form of ATAND. Add half-cycle trigonometric functions ACOSPI, ASINPI, ATANPI, ATAN2PI, COSPI, SINPI, and TANPI. (sort_actual): Generate sensible error messages for two argument versions of ATAN, ATAND, and ATANPI. * intrinsic.h: New prototypes for gfc_simplify_acospi, gfc_simplify_asinpi, gfc_simplify_atanpi, gfc_simplify_atan2pi, gfc_simplify_cospi, gfc_simplify_sinpi, gfc_simplify_tanpi, gfc_resolve_acospi, gfc_resolve_asinpi, gfc_resolve_atanpi, gfc_resolve_atan2pi, gfc_resolve_cospi, gfc_resolve_sinpi, and gfc_resolve_tanpi * intrinsic.texi: Document new functions ACOSPI, ASINPI, ATANPI, ATAN2PI, COSPI, SINPI, and TANPI. Put the ATAN* family of functions in lexigraphical order. * iresolve.cc (gfc_resolve_acospi, gfc_resolve_asinpi, gfc_resolve_atanpi, gfc_resolve_atan2pi, gfc_resolve_cospi, gfc_resolve_sinpi, gfc_resolve_tanpi): New functions. * simplify.cc (gfc_simplify_acospi, gfc_simplify_asinpi, gfc_simplify_atanpi, gfc_simplify_atan2pi, gfc_simplify_cospi, gfc_simplify_sinpi, gfc_simplify_tanpi): New functions. Introduce MPFR_HALF_CYCLE macros to use MPFR half-cycle functions if available. * trans-intrinsic.cc: Declare asinpi, acospi, atanpi, atan2pi, sinpi, cospi, and tanpi as LIB_FUNCTION's. libgfortran *Makefile.am: New files trigpi.c, trigpi_fallback1.c, and trigpi_fallback2.F90 * configure.ac: Check libm for float, double, and long double functions for asinpi, acospi, atanpi, atan2pi, sinpi, cospi, and tanpi * Makefile.in: Regenerated. * config.h.in: Ditto. * configure: Ditto. * gfortran.map: Add GFORTRAN_14 section to expose the library symbols. * trigpi.c: Fallback implementations of the half-cycle trigonometric functions. * trigpi_fallback1.c: Fallback functions for float, double, and long double routines if libm does provide them. * trigpi_fallback2.F90: REAL(16)/REAL(17) fallback implementations of the half-cycle trigonometric functions.
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412 --- Comment #3 from kargl at gcc dot gnu.org --- Created attachment 57109 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57109=edit patch The attached patch has been regtested. There were no regression.
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #2 from kargl at gcc dot gnu.org ---
With the patch at the end of this message and this source code,
program foo
integer(8) x
real(8) y, z
x = 1
y = x
z = atan(y,x)
print *, z
end
I get
% gfcx -c a.f90
a.f90:6:14:
6 |z = atan(y,x)
| 1
Error: 'x' argument of 'atan' intrinsic at (1) must be the same type and kind
as 'x'
which is almost correct (one of 'x' should be 'y').
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index c35f2bdd183..c30165dacef 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -4371,7 +4371,10 @@ sort_actual (const char *name, gfc_actual_arglist **ap,
goto do_sort;
whoops:
- gfc_error ("Too many arguments in call to %qs at %L", name, where);
+ if (strncmp(name, "atan", 4) == 0)
+gfc_check_atan_2 ((*ap)->expr, (*ap)->next->expr);
+ else
+gfc_error ("Too many arguments in call to %qs at %L", name, where);
return false;
keywords:
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #1 from kargl at gcc dot gnu.org ---
Ugh. This seems to be by design.
The error message
Error: Too many arguments in call to ‘atan’ at (1)
is queued by intrinsic.cc(sort_actual) and appears to take
precedence over an error queued by check.cc(gfc_check_atan2).
For a robust error message, if looks like we'll need to
special case the one versus to argument atan(), atand(),
and atanpi() cases intrinsic.cc(sort_actual). In pseudocode,
change
whoops:
gfc_error ("Too many arguments in call to %qs at %L", name, where);
return false;
to
whoops:
if (name == "atan")
check for two arguments and issue error
else
above gfc_error()
return false;
[Bug fortran/113413] ATAND(Y,X) is unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113413 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-16 Priority|P3 |P4
[Bug fortran/113413] New: ATAND(Y,X) is unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113413 Bug ID: 113413 Summary: ATAND(Y,X) is unsupported Product: gcc Version: 13.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: --- Fortran 2023 added ATAND(X) and ATAND(Y,X). The former is supported. The latter is unsupported. Consider. program main real(4) x, y x = 1. y = x print*, atand(y,x), atan2d(y,x) end % gfcx -o z a.f90 a.f90:5:10: 5 |print*, atand(y,x), atan2d(y,x) | 1 Error: Too many arguments in call to ‘atand’ at (1)
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-16 Priority|P3 |P4
[Bug fortran/113412] New: ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412 Bug ID: 113412 Summary: ATAN(Y,X) does not check arguments and generates wrong error message. Product: gcc Version: 13.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: --- Fortran 2008 added the misguided form ATAN(Y,X) where Y could be missing. However, if Y is present, then X is required to have the same type and kind as Y. Consider, % cat a.f90 program main real(4) x real(8) y x = 1. y = x print*, atan(y,x), atan2(y,x) end % gfcx -o z a.f90 a.f90:6:10: 6 |print*, atan(y,x), atan2(y,x) | 1 Error: Too many arguments in call to ‘atan’ at (1) a.f90:6:30: 6 |print*, atan(y,x), atan2(y,x) | 1 Error: ‘x’ argument of ‘atan2’ intrinsic at (1) must be the same type and kind as ‘y’ The error message for atan(y,x) is wrong.
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #4) > I just started looking at this today. I will give the patch a spin in the > next few days and if tests OK I can commit. > > John, are you able tp apply Steve's patch and try it? If not would you like > to learn how? I can show people the ropes. We have a MatterMost workspace > you can join and I can linkup with you there. (I will send you an invite, > just let me know.) Jerry, there are 2 paths through the function execute_command_line() in execute_command_line.c One is for synchronous execution and one is for asynchronous. For async, exitstat is untouched. For synchronous, exitstat is set. EXITSTAT (optional) shall be a scalar of type integer with a decimal exponent range of at least nine. It is an INTENT(INOUT) argument. If the command is executed synchronously, it is assigned the value of the processor-dependent exit status. Otherwise, the value of EXITSTAT is unchanged. If I read the code correctly, it tries to save a copy of the input value of exitstat, and then uses that to compare to the returned value. if exitstat is present, then is should simply be set to the return value.
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313 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 --- Created attachment 57034 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57034=edit patch to execute_command_line.c Code compiles and runs on FreeBSD. That said, I see % gfcx -o z a.f90 -g && ./z I am john F I am JOHN F % valgrind ./z ==18812== Memcheck, a memory error detector ==18812== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==18812== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==18812== Command: ./z ==18812== ==18812== Conditional jump or move depends on uninitialised value(s) ==18812==at 0x4B0AD79: _gfortran_execute_command_line_i4 (execute_command_line.c:203) ==18812==by 0x400B2A: iam.0 (a.f90:15) ==18812==by 0x400BE1: MAIN__ (a.f90:5) ==18812==by 0x400CEF: main (a.f90:6) ==18812== I am john F ==18812== Conditional jump or move depends on uninitialised value(s) ==18812==at 0x4B0AD79: _gfortran_execute_command_line_i4 (execute_command_line.c:203) ==18812==by 0x400B2A: iam.0 (a.f90:15) ==18812==by 0x400C8B: MAIN__ (a.f90:6) ==18812==by 0x400CEF: main (a.f90:6) ==18812== I am JOHN F ==18812== ==18812== HEAP SUMMARY: ==18812== in use at exit: 0 bytes in 0 blocks ==18812== total heap usage: 26 allocs, 26 frees, 9,873 bytes allocated Looking at the code around line 203 suggests that there may be some confusion with setting the error status. The attached patch allows the code to run without the valgrind warnings.
[Bug fortran/113305] ICE with do concurrent and ivdep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113305
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 Richard Biener from comment #1)
> Confirmed.
>
> f951: internal compiler error: Segmentation fault
> 0x17cf885 crash_signal
> /space/rguenther/src/gcc/gcc/toplev.cc:316
> 0xe79b99 resolve_forall_iterators
> /space/rguenther/src/gcc/gcc/fortran/resolve.cc:7620
No idea what ivdep is suppose to do, but it is certainly messing up gfortran.
(gdb) b resolve.cc:7620
Breakpoint 1 at 0x9e076d: file ../../gccx/gcc/fortran/resolve.cc, line 7620.
(gdb) run a.f90
Breakpoint 1, resolve_forall_iterators (it=0x203c6d360)
at ../../gccx/gcc/fortran/resolve.cc:7620
7620 if (gfc_resolve_expr (iter->var)
(gdb) p *it
$5 = {var = 0x203c250a0, start = 0x203c25180, end = 0x203c25260,
stride = 0x203c25340, next = 0x1}
it->next is set to an invalid address, so the for loop is not
exited. If I remove the '!GCC ivdep' directive, then one see
(gdb) p *it->next
Cannot access memory at address 0x0
the expected result. I think that this is not a Fortran bug, and the
component should be changed to middle-end.
[Bug fortran/113254] Option -fallow-invalid-boz does not help with sample code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113254 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to mecej4 from comment #2) > Created attachment 57001 [details] > Program source that is handled correctly when -fallow-invalid-boz is > specified Correctly? It is not the same as the initial case. For [B'0111',B'1011', ...], each of the BOZ is an ac-value. See the Fortran standards for the constraints that I already cited. A BOZ cannot be an ac-value. It is typeless. Should gfortran convert B'0111' to 127 or 1.77964905E-43? Remember a BOZ is typeless, and prior to F2023, the RHS is evaluated without regard to the type and kind of the LHS. For the new case of [char(B'0111'),char(B'1011'), ...], the BOZ are actual arguments to some intrinsic subprogram. These BOZ are not ac-values. The error message(s) actually tells you that this is invalid. Gfortran accepts these actual-argument BOZ with the -fallow-invalid-boz, because older versions of gfortran would convert a BOZ to an integer upon reading the BOZ from the source code. The actual argument of char() happens to be of type integer, so you got lucky! Consider the equally egregious example: program bozz implicit none real, parameter :: x = sin(B'0111') print *, x end program % gfcx -o z a.f90 a.f90:4:28: 4 |real, parameter :: x=sin(B'0111') |1 Error: A BOZ literal constant at (1) cannot appear as an actual argument in a function reference % gfcx -o z a.f90 -fallow-invalid-boz a.f90:4:28: 4 |real, parameter :: x=sin(B'0111') |1 Error: A BOZ literal constant at (1) cannot appear as an actual argument in a function reference [integer :: B'0111',B'1011', ...] is F2023 standard conforming. gfortran does not currently support this new feature of F2023. It should not be too hard to support F2023, but that would require someone to either provide a patch or provide funding for someone else to provide the patch.
[Bug fortran/113254] Option -fallow-invalid-boz does not help with sample code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113254 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 --- -fallow-invalid-boz is not a panacea for invalid Fortran. F2018 has F2018:C7110 (R770) If type-spec is omitted, each ac-value expression in the array-constructor shall have the same declared type and kind type parameters. F2018:C7111 (R770) If type-spec specifies an intrinsic type, each ac-value expression in the array-constructor shall be of an intrinsic type that is in type conformance with a variable of type type-spec as specified in Table 10.8. As a BOZ is typeless, it therefore cannot be in an array constructor. Even if you had added a type-spec such as '[integer :: ...]'. F2023 does allow a BOZ in an array constructor, with the following constraints: F2023:C7126 If an ac-value is a boz-literal-constant, type-spec shall appear and shall specify type integer or real. F2023:C7127 If an ac-value is a boz-literal-constant and type-spec specifies type real, the boz-literal-constant shall be a valid internal representation for the specified kind of real. Your code lacks a type-spec, so C7126 kicks in. Even with a type-spec, as this is a new F2023 feature, gfortran does not currently support a BOZ in an array-constructor. Adding this capability would be a good introduction to contributing to gfortran development.
[Bug libfortran/113223] NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #3) > Created attachment 56990 [details] > Suggested patch including affected test cases > > Regression tested OK. Three test cases affected. > Thanks, and whoops, sorry about the lack of regtesting. The change looks simple enough that if you what to backport, then go for it
[Bug libfortran/113223] NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223 kargl at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Jerry can you take a look at this issue.
[Bug libfortran/113223] NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug libfortran/113223] New: NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223
Bug ID: 113223
Summary: NAMELIST internal write missing leading blank
character
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: kargl at gcc dot gnu.org
Target Milestone: ---
Found at https://github.com/llvm/llvm-project/issues/76798
Program test_namelist_blank
Integer :: i,j
Character(300) ::s
Namelist /nml1/i,j
i = 99
j = 42
Write (s,NML=nml1)
Write (*,'("Internal ",A)') Merge('ok ','bug',s(1:1)==' ')
Write (*,NML=nml1)
End Program test_namelist_blank
F2018
13.11.4.3 Namelist output records
...
Except for new records created by explicit formatting within a defined
output procedure or by continuation of delimited character sequences,
each output record begins with a blank character.
Patch
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index f94e180ba33..a7cf5d9b233 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -2466,6 +2466,8 @@ namelist_write (st_parameter_dt *dtp)
dtp->u.p.nml_delim = '\0';
}
+ if (is_internal_unit (dtp))
+write_character (dtp, " ", 1, 1, NODELIM);
write_character (dtp, "&", 1, 1, NODELIM);
/* Write namelist name in upper case - f95 std. */
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 --- Comment #9 from kargl at gcc dot gnu.org --- Current patch is incomplete as it fails to scalarize. It seems I need to remember how to register the new intrinsic subprograms in trans-intrinsics.cc.
[Bug fortran/113165] Code containing more than one type declaration for a variable results in confusing error messages from compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113165
--- Comment #2 from kargl at gcc dot gnu.org ---
With the attached example code and the patch at the end of this
message, gfortran can be changes to identify both lines of code.
Fixing the run-on errors when -fimplicit-none is used is left as
an exercise for a new contributor or will be ignored until such
time as someone closes this bug report.
% gfcx -c e.f90
e.f90:3:30:
3 | double precision a,b,c,d,f,g
| 1
4 | integer i,j,k,l
5 | double precision d,q,r ! 'd' was already declared as double
prec.
|2
Error: Symbol ‘d’ declared at (1) already has basic type of REAL and cannot
appear in the declaration at (2)
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index a6078bc608a..7fa1839323b 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -2015,8 +2015,9 @@ gfc_add_type (gfc_symbol *sym, gfc_typespec *ts, locus
*where)
gfc_error ("Symbol %qs at %L already has basic type of %s",
sym->ns->proc_name->name, where, gfc_basic_typename (type));
else
- gfc_error ("Symbol %qs at %L already has basic type of %s", sym->name,
- where, gfc_basic_typename (type));
+ gfc_error ("Symbol %qs declared at %L already has basic type of %s "
+ "and cannot appear in the declaration at %L", sym->name,
+ >declared_at, gfc_basic_typename (type), where);
return false;
}
[Bug fortran/113165] Code containing more than one type declaration for a variable results in confusing error messages from compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113165 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||kargl at gcc dot gnu.org Severity|normal |enhancement --- Comment #1 from kargl at gcc dot gnu.org --- You are hitting a run-on error caused by the first reported error. If you are compiling old code or code you are currently writing or code with a questionable pedigree, use the -fmax-errors=1 option. For the record, your bug report is confusing ;-) Because it includes error messages associated with your attached example: program multDecls double precision a,b,c,d,f,g integer i,j,k,l double precision d,q,r ! 'd' was already declared as double prec. d = 65536.0d0 r = sqrt(d) print *,' r = ',r,' p = ',p end program but you refer to netlib code with a duplicate 't' declaration. Due to the first error about 'd', the rest of the declaration is discarded. The result is that 'q,r' have not been declared and so have implicit types. The option '-fimplicit-none' is telling you about this problem. Fix the first error and the run-on errors go away. Note, "Error: Symbol 'd' at (1) already has basic type of REAL" simply means that 'd' has been typed as a REAL entity irrespective of the kind. It does not mean that 'd' has been given a single precision type of REAL(4). I suppose someone could change the error message to a more generic "Error: Symbol 'd' at (1) has already been declared." or some such wording.
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 --- Comment #8 from kargl at gcc dot gnu.org --- Created attachment 56956 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56956=edit git diff cannot find trigpi.c (updated file) The new file tries to deal with a system with REAL(4), REAL(8), and REAL(16). The various files and patch have been tested on AMD64 where gfortran has REAL(4), REAL(8), REAL(10), and REAL(16).
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 --- Comment #7 from kargl at gcc dot gnu.org --- Created attachment 56955 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56955=edit test program for inverse functions The attach program tests the inverse functions, e.g., acospi, for all kinds on AMD64 hardware.
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 --- Comment #6 from kargl at gcc dot gnu.org --- In reflecting on the possibility of an OS lacking support for REAL(10) but having a REAL(16), the mapping of types into C are likely REAL(4) <--> float, REAL(8) <--> double, and REAL(16) <--> long double. The current patch sort of gets this wrong, because REAL(16) is not properly mapped. I'll fix that shortly.
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 --- Comment #4 from kargl at gcc dot gnu.org --- Created attachment 56953 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56953=edit test program
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 --- Comment #3 from kargl at gcc dot gnu.org --- Created attachment 56952 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56952=edit file that git cannot find Put in libgfortran/intrinsics
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 --- Comment #2 from kargl at gcc dot gnu.org --- Created attachment 56951 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56951=edit file that git cannot find Put file in libgfortran/intrinsics
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 --- Comment #1 from kargl at gcc dot gnu.org --- Created attachment 56950 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56950=edit new file that git cannot diff Put file in libgfortran/intrinsics.
[Bug fortran/113152] New: Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 Bug ID: 113152 Summary: Fortran 2023 half-cycle trigonometric functions Product: gcc Version: 13.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: --- Created attachment 56949 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56949=edit patch with implementation The attach patch implements the half-cycle trigonometric functions that are now contained within Fortran 2023. There a few things to note. 1) IEEE 754-2008, ISO/IEC TS 18661-4, C23, and Fortran 2023 all contain these functions. This likely means that the functions acospi(), asinpi(), ..., tanpi() may be available as part of an operating system's libm. In fact, FreeBSD has implementations of cospi, sinpi, and tanpi in libm, and these conform to the requirements of IEEE 754-2008 and ISO/IEC TS 18661-4. The file libgfortran/intrinsics/trigpi_fallback1.c provides fallbacks for float, double, and long double functions. As I don't know the internals for libquadmath or ibm double-double, the REAL(16) (and GFC_REAL_17) fallback functions are in libgfortran/intrinsics/trigpi_fallback1.F90. I have tested REAL(16) that sits on top of libquadmath. I have not tested the double-double situation. Finally, the fallback functions do not go to any length in meeting all of the requirements of IEEE 754-2008. For example, sinpi(n+0.5) is exactly +-1 for representable integer n. The fallbacks may raise an FE_INEXACT exception. 2) I tried adding math builtins in gcc/fortran/mathbuiltins.def to directly map to libm functions, but this ultimately led to much frustration. I gave up and wrap, for example, cospi() in _gfortran_cospi_r8(). So, there is a level of in-direction. This is done in libgfortran/intrinsics/trigpi.c. Someone smarter than I can do the math builtins. 3) I tried inserting GFC_ISYM_ACOSPI, ..., GFC_ISYM_TANPI in alphabetical order in 'enum gfc_isym_id' of gfortran.h. This runs into some obscure issue with libgomp where C_ASSOCIATED is no longer recognized. So, I placed the new members of the enum at its end. 4) I don't use git. I tried to do 'git add libgfortran/intrinsics/trigpi\*' followed by 'git commit libgfortran/intrinsics/trigpi\*', and then finally 'git diff > z_halfcycle.diff'. This does not generate one unified diff file. Sigh. I'll attach the new files along with the mangled diff.
[Bug fortran/113128] Wrong implied-do with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128 kargl at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-12-24 Known to fail||12.2.0 Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||14.0 Ever confirmed|0 |1 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Works with top-of-tree.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #9 from kargl at gcc dot gnu.org --- I have updated the diff. I don't know have ChangeLog works under git. Here's what I have written. * gcc/fortran/gfortran.texi: Remove the "Extended math intrinsics" node. It documented the only the degree trigonometric functions. That is, it was a very limited list of the additional nonstandard intrinsic subprograms offered by gfortran. Most of these functions are now part of Fortran 2023. * gcc/fortran/intrinsic.cc(add_functions): Degree trigonometric functions [A]COSD, [A]SIND, [A]TAND, and [A]TAN2D have been added to the Fortran 2023 standard. These were originally added for compaitiblity with DEC Fortran under the -fdec-math. Change these from GFC_STD_GNU to GFC_STD_F2023. (gfc_check_intrinsic_standard): Add a check for Fortran 2023. * gcc/fortran/intrinsic.texi: Update documentation for [A]COSD, [A]SIND, [A]TAND, and [A]TAN2D.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 kargl at gcc dot gnu.org changed: What|Removed |Added Attachment #56810|0 |1 is obsolete|| --- Comment #8 from kargl at gcc dot gnu.org --- Created attachment 56838 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56838=edit updated diff This is an updated diff. It removes making some functions generic when they are only specific intrinsic routines (e.g., DSIND). It also updates the documentation.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #1 from kargl at gcc dot gnu.org --- Possible ChangeLog (although I don't know the git world requirements). * intrinsic.cc(add_functions): Update the standard that the various degree trigonometric functions have been described in. (gfc_check_intrinsic_standard): Add an error string for F2023.
[Bug fortran/112873] New: F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 Bug ID: 112873 Summary: F2023 degree trig functions Product: gcc Version: 14.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: --- Created attachment 56810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56810=edit * intrinsic.cc(add_functions): Update the standard that the various degree trigonometric functions come from. (gfc_check_intrinsic_standard): Add an error string for F2023. The Fortran 2023 standard has added a number degree trigonometric functions. See 23-007r1.pdf, p. xiii: The intrinsic functions ACOSD, ASIND, ATAND, ATAN2D, COSD, SIND, and TAND are trigonometric functions in which angles are specified in degrees. gfortran already supported these functions under its DEC Fortran compatibility and made them available under -std=gnu. There is a -fdec-math function, but that seems to be non-functional or I don't understand what it does. In any event, the attached patch changes GFC_STD_GNU to GFC_STD_F2023 where appropriate. It also added the case for GFC_STD_F2023 for error messages.
[Bug libfortran/112364] calloc used incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug libfortran/112364] calloc used incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
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 ---
7 comments?
diff --git a/libgfortran/io/async.c b/libgfortran/io/async.c
index 57097438e89..8fa1f0d4ce0 100644
--- a/libgfortran/io/async.c
+++ b/libgfortran/io/async.c
@@ -262,7 +262,7 @@ init_async_unit (gfc_unit *u)
void
enqueue_transfer (async_unit *au, transfer_args *arg, enum aio_do type)
{
- transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
+ transfer_queue *tq = calloc (1, sizeof (transfer_queue));
tq->arg = *arg;
tq->type = type;
tq->has_id = 0;
@@ -284,7 +284,7 @@ int
enqueue_done_id (async_unit *au, enum aio_do type)
{
int ret;
- transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
+ transfer_queue *tq = calloc (1, sizeof (transfer_queue));
tq->type = type;
tq->has_id = 1;
@@ -308,7 +308,7 @@ enqueue_done_id (async_unit *au, enum aio_do type)
void
enqueue_done (async_unit *au, enum aio_do type)
{
- transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
+ transfer_queue *tq = calloc (1, sizeof (transfer_queue));
tq->type = type;
tq->has_id = 0;
LOCK (>lock);
@@ -328,7 +328,7 @@ enqueue_done (async_unit *au, enum aio_do type)
void
enqueue_close (async_unit *au)
{
- transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
+ transfer_queue *tq = calloc (1, sizeof (transfer_queue));
tq->type = AIO_CLOSE;
LOCK (>lock);
[Bug fortran/30409] [fortran] missed optimization with pure function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30409 --- Comment #12 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #11) > (In reply to kargl from comment #10) > > (In reply to anlauf from comment #8) > > > which is equivalent to > > > >tmp = 1 / y > >do i = 1, n > > ... = expression1(..., tmp) > >end do > > No. Strictly speaking, it is only equivalent to: > > if (n > 0) tmp = 1 / y > do i = 1, n >... = expression1(..., tmp) > end do Ah, yes, I missed the possibility that the loop may not loop at all.
[Bug fortran/30409] [fortran] missed optimization with pure function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30409 --- Comment #10 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #8) > The suggested optimization needs to take into account that the evaluation > of the temporary expression might trap, or that allocatable variables are > not allocated, etc. > > The trap etc. would not occur if the trip count of the loop is zero for the > non-hoisted variant, so we need to make sure not to generate failing code > for the hoisted one. > > Similarly, for conditional code in the loop body, like > > if (cond) then > expression1 (..., 1/y) > else > expression2 (..., 1/z) > end if > > where cond protects from traps even for finite trip counts, these conditions > may also need to be identified, and an appropriate block generated. I'm not sure what you are worried about here. If one has do i = 1, n ... = expression1(..., 1/y) end do then this is equivalent to do i = 1, n tmp = 1 / y ... = expression1(..., tmp) end do which is equivalent to tmp = 1 / y do i = 1, n ... = expression1(..., tmp) end do I suppose I could do something exceedingly stupid such as function expression1(..., xxx) common /foo/y y = 0 ... end but this would then lead to invalid Fortran when i = 2 in the above initial loops as (1/y) is invalid Fortran if y = 0.
[Bug fortran/30409] [fortran] missed optimization with pure function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30409 --- Comment #7 from kargl at gcc dot gnu.org --- The attached testcase use xmin and xmax uninitialized. After setting xmin = 0 and xmax = 1 and adding z(1) to the print statements to prevent the inner loop from being optimized away, I see the following: % gfcx -o z -O0 a.f90 && ./z time 1:1.7823E-02 7249751.00 time 2:6.37416887 7249751.00 % gfcx -o z -O1 a.f90 && ./z time 1:1.37590002E-02 7249751.00 time 2:6.36764479 7249751.00 % gfcx -o z -O2 a.f90 && ./z time 1:1.23690004E-02 7249751.00 time 2:1.85729897 7249751.00 % gfcx -o z -O3 a.f90 && ./z time 1:2.43199989E-03 7249751.00 time 2:1.85660207 7249751.00 % gfcx -o z -Ofast a.f90 && ./z time 1:3.6347E-03 7249751.50 time 2: 0.621210992 7249751.50 so the timing improves with optimization. -fdump-tree-original still shows the generation of a temporary variable for the actual argument 1/y in the second set of nested loops. -fdump-tree-optimized is fairly difficult for me to decipher, but it appears that the 1/y is not hoisted out of the inner loop.
[Bug fortran/111880] [9/10/11/12/13] False positive warning of obsolescent COMMON block with Fortran submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880 kargl at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement Priority|P3 |P5 --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to zed.three from comment #0) > Warning: Fortran 2018 obsolescent feature: COMMON block at (1) > foo.f90:14:14: > > 14 | submodule (foo) foo_submod > | 1 > Warning: Fortran 2018 obsolescent feature: COMMON block at (1) > Not sure I would call this a false positive as the locus is pointing at module 'foo', and 'foo' contains a common block.
[Bug fortran/111851] f951: Segmentation fault at gfc_delete_symtree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111851 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 --- Oddly, I'm seeing an ICE due to the assert() at line 3131 in symbol.cc(gfc_release_symbol). I don't see the memory hog issue. If I comment out that assert() and let gfortran proceed, I see % gfcx -c a.f90 a.f90:1:28: 1 | SELECT TYPE (rvec2ASSOCIATE( |1 Error: Syntax error in argument list at (1) On FreeBSD I use the following for configure ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran,lto \ --enable-bootstrap --disable-nls --disable-multilib --enable-libsanitizer
[Bug fortran/111853] f951: Segmentation fault at gfc_expression_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111853
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Priority|P3 |P4
Last reconfirmed||2023-10-18
--- Comment #1 from kargl at gcc dot gnu.org ---
NULL pointer.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 861f69ac20f..51ff3c7ed21 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5659,7 +5659,7 @@ gfc_expression_rank (gfc_expr *e)
if (ref->type != REF_ARRAY)
continue;
- if (ref->u.ar.type == AR_FULL)
+ if (ref->u.ar.type == AR_FULL && ref->u.ar.as)
{
rank = ref->u.ar.as->rank;
break;
[Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
--- Comment #7 from kargl at gcc dot gnu.org ---
An alternative patch that allows the original code to compile is
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index a6078bc608a..34eb3a65e8f 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -3160,7 +3160,7 @@ static void
ambiguous_symbol (const char *name, gfc_symtree *st)
{
- if (st->n.sym->error)
+ if (st->n.sym->error || (st->n.sym->module && !gfc_current_locus.lb))
return;
if (st->n.sym->module)
This one simply returns. If one actually tries to reference the
conflicting entity an error message is generated.
[Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #6 from kargl at gcc dot gnu.org ---
>if (st->n.sym->module)
> -gfc_error ("Name %qs at %C is an ambiguous reference to %qs "
> -"from module %qs", name, st->n.sym->name, st->n.sym->module);
> +{
> + if (gfc_current_locus.lb)
> + gfc_error ("Name %qs at %C is an ambiguous reference to %qs from"
A space is missing after "... from". Should be "... from "
> +"module %qs", name, st->n.sym->name, st->n.sym->module);
> + else
> + gfc_error ("Name %qs is an ambiguous reference to %qs, which is "
> +"available through USE association from module %qs at %L",
> +name, st->n.sym->name, st->n.sym->module,
> +>n.sym->declared_at);
> +}
>else
> gfc_error ("Name %qs at %C is an ambiguous reference to %qs "
> "from current program unit", name, st->n.sym->name);
The original code is too painful to read (aka uppercase and no formatting).
The claim is that the code is valid. Maybe it is as the conflicting
names in the modules are not referenced in the program unit. If OP
references SET_ABOR1_EXCEPTION_HANDLER, good luck.
[Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
--- Comment #5 from kargl at gcc dot gnu.org ---
Interesting bug. If one puts a break point ...
0x75917d gfc_format_decoder
/home/toon/compilers/gcc/gcc/fortran/error.cc:1078
0x2153e1f pp_format(pretty_printer*, text_info*)
/home/toon/compilers/gcc/gcc/pretty-print.cc:1475
0x21315be diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/toon/compilers/gcc/gcc/diagnostic.cc:1606
0x9b628e gfc_report_diagnostic
/home/toon/compilers/gcc/gcc/fortran/error.cc:890
0x9b628e gfc_error_opt
/home/toon/compilers/gcc/gcc/fortran/error.cc:1460
0x9b7470 gfc_error(char const*, ...)
/home/toon/compilers/gcc/gcc/fortran/error.cc:1489
0xa6205b ambiguous_symbol
/home/toon/compilers/gcc/gcc/fortran/symbol.cc:3167
here, one ends up at
gfc_error ("Name %qs at %C is an ambiguous reference to %qs from"
"module %qs", name, st->n.sym->name, st->n.sym->module);
%C means one should use gfc_current_locus to print the offending line.
If one looks are gfc_current_locus, one sees gfc_current_locus.lb = 0x0,
an infamous NULL pointer dereference then occurs. Ouch. This patch
fixes the issue:
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index a6078bc608a..5b726f8b715 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -3164,8 +3164,16 @@ ambiguous_symbol (const char *name, gfc_symtree *st)
return;
if (st->n.sym->module)
-gfc_error ("Name %qs at %C is an ambiguous reference to %qs "
- "from module %qs", name, st->n.sym->name, st->n.sym->module);
+{
+ if (gfc_current_locus.lb)
+ gfc_error ("Name %qs at %C is an ambiguous reference to %qs from"
+ "module %qs", name, st->n.sym->name, st->n.sym->module);
+ else
+ gfc_error ("Name %qs is an ambiguous reference to %qs, which is "
+ "available through USE association from module %qs at %L",
+ name, st->n.sym->name, st->n.sym->module,
+ >n.sym->declared_at);
+}
else
gfc_error ("Name %qs at %C is an ambiguous reference to %qs "
"from current program unit", name, st->n.sym->name);
[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716 --- Comment #4 from kargl at gcc dot gnu.org --- What the heck does "RESOLVED MOVED"?
[Bug fortran/111341] Elemental operator on zero-sized array seg-faults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111341 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 --- gfcx -c a.f90 a.f90:3:7: 3 | use iso_varying_string, only: varying_string, operator(//), put_line | 1 Fatal Error: Cannot open module file 'iso_varying_string.mod' for reading at (1: No such file or directory Unforturnately, it seems the issue cannot be reproduced.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 kargl at gcc dot gnu.org changed: What|Removed |Added Known to work||12.2.0, 14.0 Priority|P3 |P4
[Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218 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 --- > (tested with gcc version 14.0.0 20230828 (experimental) [master > r14-3528-gc3669bb677b] (GCC) No ICE with a 14.0.0 20230824 gfortran
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #14 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #13)
> (In reply to Steve Kargl from comment #12)
> > On Mon, Aug 07, 2023 at 10:04:54PM +, kargl at gcc dot gnu.org wrote:
> > >
> > > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> > > index 3cd470ddcca..b0bb8bc1471 100644
> > > --- a/gcc/fortran/resolve.cc
> > > +++ b/gcc/fortran/resolve.cc
> > > @@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
> > >
> > >for (n = ns->contained; n; n = n->sibling)
> > > {
> > > - if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
> > > + if (gfc_pure (ns->proc_name)
> > > + && !gfc_pure (n->proc_name)
> > > + && !n->proc_name->attr.artificial)
> > > gfc_error ("Contained procedure %qs at %L of a PURE procedure
> > > must "
> > >"also be PURE", n->proc_name->name,
> > >>proc_name->declared_at);
> > >
> > > pault, dos the above look correct?
> > >
> >
> > This patch passes a regression test with no new regressions
> > on x86_64-*-*freebsd.
>
> Hi Steve,
>
> That will certainly fix the bug. An alternative crosses my mind, which is to
> check the pureness of the final routines as the wrapper is being built and
> give the wrapper the pure attribute if they are all pure.
>
Just saw that you attached a patch on 5/23/23 that it essentially the same as I
suggested. I tried to simply set the final->attr.pure to 1, but this ran into
issues with the argument list having intent(inout) instead of just intent(in).
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Neil Carlson from comment #9)
> Bug is still present in 13.2.0.
class.cc(generate_finalization_wrapper) contains the following
/* Set up the procedure symbol. */
name = xasprintf ("__final_%s", tname);
gfc_get_symbol (name, sub_ns, );
sub_ns->proc_name = final;
final->attr.flavor = FL_PROCEDURE;
final->attr.function = 1;
final->attr.pure = 0;
final->attr.recursive = 1;
final->result = final;
final->ts.type = BT_INTEGER;
final->ts.kind = 4;
final->attr.artificial = 1;
Note final->attr.pure = 0 seems to contradict C1595 while constructing
the wrapper. I'm not too familiar with this portion of gfortran's
internals. Either the attribute should be set to 1 or the error
message can be suppressed through inspection of final->attr.artificial.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 3cd470ddcca..b0bb8bc1471 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
for (n = ns->contained; n; n = n->sibling)
{
- if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
+ if (gfc_pure (ns->proc_name)
+ && !gfc_pure (n->proc_name)
+ && !n->proc_name->attr.artificial)
gfc_error ("Contained procedure %qs at %L of a PURE procedure must "
"also be PURE", n->proc_name->name,
>proc_name->declared_at);
pault, dos the above look correct?
[Bug fortran/88286] [OOP] gfortran reports conflicting intent(in) with an intent(in) declared class variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88286 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 anlauf from comment #2) > Appears fixed in 12-branch and later. Adding known-to work. > > Can we close this one? I think the answer is "yes". It comes down to "too many bugs and too few contributors". If someone can identify the commit that fixed this bug, then by all means it can be back-ported. It's unclear to me if it is worth the effort to find the commit.
[Bug fortran/110825] TYPE(*) dummy argument to generate an unused hidden argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110825 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Priority|P3 |P4 Ever confirmed|0 |1 Known to fail||13.1.1, 14.0 Last reconfirmed||2023-07-26
[Bug fortran/110825] New: TYPE(*) dummy argument to generate an unused hidden argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110825
Bug ID: 110825
Summary: TYPE(*) dummy argument to generate an unused hidden
argument
Product: gcc
Version: 14.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: ---
The was pointed out in Fortran Discourse,
https://fortran-lang.discourse.group/t/strange-behaviour-when-using-type-and-character-in-gfortran/6233
that gfortran generates wrong code for a valid program. Here's a slightly
modified version of the program.
program foo
implicit none
character(100) :: not_used
call sub(not_used, "123")
contains
subroutine sub(useless_var, print_this)
type(*), intent(in) :: useless_var
character(*), intent(in) :: print_this
if (len_trim(print_this) /= 3) stop 1
end subroutine sub
end
The subroutine reference in the main program is generating a call with two
hidden arguments. From -fdump-tree-original,
void MAIN__ ()
{
static void sub (void * & restrict, character(kind=1)[1:] & restrict,
integer(kind=8));
character(kind=1) not_used[1:100];
sub (_used, &"123"[1]{lb: 1 sz: 1}, 100, 3);
}
we have hidden arguments 100 and 3. However, the code generated for the
contained subroutine is only expecting one hidden argument.
__attribute__((fn spec (". r r ")))
void sub (void * & restrict useless_var,
character(kind=1)[1:_print_this] & restrict print_this,
integer(kind=8) _print_this)
{
...
}
Thus, when compiled and executed the program hits 'STOP 1'. Likely, gfortran
needs to add a possibly unused hidden argument to the argument list for a
TYPE(*) dummy argument.
[Bug fortran/87326] [F18] Support the NEW_INDEX= specifier in the FORM TEAM statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87326 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 Brad Richardson from comment #3) > Was there any more progress on this? I've just run into it. > > FYI I'm trying implement a polymorphic send/receive: > https://gitlab.com/everythingfunctional/communicator Unfortunately, no. gfortran depends on opencoarray for its library support for coarray Fortran. Much of the work has been contributed by individuals funded through the Sourcery Institute (i.e., Damian's organization). He's turned his interests towards caffeine (https://github.com/berkeleylab/caffeine).
[Bug fortran/110725] [13/14 Regression] internal compiler error: in expand_expr_real_1, at expr.cc:10897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110725 kargl at gcc dot gnu.org changed: What|Removed |Added Known to fail||14.0 Known to work||12.2.0 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) > That would make it accepts-invalid then? I'm not an expert with OpenMP, so cannot make a decision here. Note, the original code compiles with 12.2.0. I don't have 13.x installed for testing. While reducing the code to something much smaller, I notice the idiom of !$omp target !$omp teams !$omp distribute parallel do simd DO 75 I=1,M 75 CONTINUE !$omp end teams !$omp end target everywhere except for the one occurrence in the reduce code of !$omp target !$omp teams !$omp distribute parallel do simd DO 75 I=1,M U(I+1,N+1) = U(I+1,1) V(I,1) = V(I,N+1) 75 CONTINUE !$omp end teams U(1,N+1) = U(M+1,1) <-- This seems out-of-place when compared V(M+1,1) = V(1,N+1) <-- to all other code. !$omp end target END SUBROUTINE If I move the '!$omp end teams' down two lines, the code compiles. If I remove the two lines of Fortran code, the code compiles.
[Bug fortran/110725] [13/14 Regression,openmp] internal compiler error: in expand_expr_real_1, at expr.cc:10897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110725 kargl at gcc dot gnu.org changed: What|Removed |Added Summary|[13/14 Regression] internal |[13/14 Regression,openmp] |compiler error: in |internal compiler error: in |expand_expr_real_1, at |expand_expr_real_1, at |expr.cc:10897 |expr.cc:10897 CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Reduced testcase. The '!$omp end teams' line in subroutine initial appears to be out-of-place. module swim_mod INTEGER, PARAMETER :: N1=7702, N2=7702 DOUBLE PRECISION, ALLOCATABLE, DIMENSION(:,:) :: U, V INTEGER :: M, N, MP1, NP1 !$omp declare target(U, V) !$omp declare target(M,N,MP1,NP1) CONTAINS SUBROUTINE ALLOC IMPLICIT NONE !$omp target update to(M,N,MP1,NP1) !$omp& ALLOCATE(U(NP1,MP1), V(NP1,MP1)) END SUBROUTINE SUBROUTINE INITAL INTEGER I !$omp target !$omp teams !$omp distribute parallel do simd DO 75 I=1,M U(I+1,N+1) = U(I+1,1) V(I,1) = V(I,N+1) 75 CONTINUE !$omp end teams U(1,N+1) = U(M+1,1) V(M+1,1) = V(1,N+1) !$omp end target END SUBROUTINE end module swim_mod
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 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 --- Unfortunately, we're going to need a reduced testcase. I tried the simple instruction to build tuv-x, but don't have json-fortran.
[Bug fortran/110629] Bug in assignment of derived type with deferred length character component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110629 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 --- Thanks for the bug report. This seems to have been fixed in trunk. I don't have gfortran 13.1 installed so cannot test. % gfcx -o z a.f90 && ./z 1 |big | 2 |red | 3 |dog | % gfcx -o z -O a.f90 && ./z 1 |big | 2 |red | 3 |dog | % gfortran12 -o z -O a.f90 && ./z 1 |big | 2 ||big| 3 ||big|| There are a few Changelog entries over the last year that mention deferred length, but it's unclear which one might have fixed the issue.
