Re: [patch, fortran] PR117430 gfortran allows type(C_ptr) in I/O list
On 2/13/25 7:09 PM, Jerry D wrote: On 2/13/25 1:42 PM, Harald Anlauf wrote: Am 12.02.25 um 21:49 schrieb Jerry D: The attached patch is fairly obvious. The use of notify_std is changed to a gfc_error. Several test cases had to be adjusted. Regression tested on x86_64. OK for trunk? This is not a review, just some random comments on the testsuite changes by your patch: I will update and give the i some declarations. I just tried integer and it worked. Of course you are correct to declasre these as type(c_ptr) Regarding, the use of transfer, I will fix those as well. The patch itself is trivial so I will wait a day or so for any other comments. Thanks for feedback. Jerry Committed after adjusting the test cases. commit r15-7569-g12771b Author: Jerry DeLisle Date: Thu Feb 13 20:19:56 2025 -0800 Fortran: gfortran allows type(C_ptr) in I/O list Before this patch, gfortran was accepting invalid use of type(c_ptr) in I/O statements. The fix affects several existing test cases so no new test case needed. Existing tests were modified to pass by either using the transfer function to convert to an acceptable value or using an assignment to a like type (non-I/O). PR fortran/117430 gcc/fortran/ChangeLog: * resolve.cc (resolve_transfer): Change gfc_notify_std to gfc_error. gcc/testsuite/ChangeLog: * gfortran.dg/c_loc_test_17.f90: Use an assignment rather than PRINT. * gfortran.dg/c_ptr_tests_10.f03: Use a transfer function. * gfortran.dg/c_ptr_tests_16.f90: Use an assignment. * gfortran.dg/c_ptr_tests_9.f03: Use a transfer function. * gfortran.dg/init_flag_17.f90: Likewise. * gfortran.dg/pr32601_1.f03: Use an assignment.
[patch, Fortran, committed] Fix PR 118845
Hello world,
I just committed the fix for PR 11845 as obvious and simple, as
r15-7552-gfd00010ba21c04bddb20aef52f62de5636075067 .
Fix PR 118884, Lapack build failure.
The fix for PR 118845 introduced new checks, which in turn exposed
a case where the typespec information on a symbol generated symbol
was not set. This led to an apparent type of BT_UNKNOWN, and hence
an error. Fixed as obvious and simple, after regression-testing.
Best regards
Thomas
gcc/fortran/ChangeLog:
* frontend-passes.cc (check_externals_procedure): Copy
typespec from old to new symbol.
gcc/testsuite/ChangeLog:
* gfortran.dg/interface_54.f90: New test.diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 6b470b83e21..20bf6e127ff 100644
--- a/gcc/fortran/frontend-passes.cc
+++ b/gcc/fortran/frontend-passes.cc
@@ -5727,6 +5727,7 @@ check_externals_procedure (gfc_symbol *sym, locus *loc,
gcc_assert (new_sym);
new_sym->attr = sym->attr;
new_sym->attr.if_source = IFSRC_DECL;
+ new_sym->ts = sym->ts;
gfc_current_ns = gsym->ns;
gfc_get_formal_from_actual_arglist (new_sym, actual);
diff --git a/gcc/testsuite/gfortran.dg/interface_54.f90 b/gcc/testsuite/gfortran.dg/interface_54.f90
new file mode 100644
index 000..98318cae888
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/interface_54.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR 118884 - this used to be rejected due to confused interface
+! checking.
+
+subroutine cget24
+ external cslect
+ logical cslect
+
+ call cgeesx(cslect)
+ if( cslect() ) print *,"foo"
+ call cgeesx(cslect)
+end subroutine cget24
Re: [PATCH] Fortran: passing of derived type to VALUE, OPTIONAL dummy argument [PR118080]
Hello Harald, the attached patch fixes inconsistent handling of passing derived type actual arguments to scalar dummies with VALUE,OPTIONAL attribute. As suggested by Tobias, we should consistently pass a hidden boolean flag that indicates the presence or absence of the actual, similar to the case of intrinsic types. For more details see the attached. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK. Thanks for the patch!
Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines
Am 14.02.25 um 19:19 schrieb Jerry D: I think this is good to commit. (all 7 parts) I think so too, with one caveat... Does anyone else have any comments? This patch series (of necessity) introduces ABI changes. What will happen with user code compiled against the old interface? I guess a link failure (plus an answer in stack exchange where the explanation is given, so people can google it, and a mention in the release notes) would be acceptable, but is there anything that can be done in addition? Best regards Thomas
[patch, Fortran, doc, committed] PR 118159, defunct website
Hello world,
I just committed Andrew's patch from the PR as obvious as
r15-7557-gbf84e5e64662f8f0fdebfc0212e32bfca678f9eb .
Best regards
Thomas
Remove defunct web site for site of Fortran preprocessor.
gcc/fortran/ChangeLog:
PR fortran/118159
* invoke.texi: Remove mention of defunct web site for Coco.
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index ff4040732d8..ab708db89b6 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -662,8 +662,7 @@ include code for these additional kind types: @code{__GFC_INT_1__},
While CPP is the de-facto standard for preprocessing Fortran code,
Part 3 of the Fortran 95 standard (ISO/IEC 1539-3:1998) defines
Conditional Compilation, which is not widely used and not directly
-supported by the GNU Fortran compiler. You can use the program coco
-to preprocess such files (@uref{http://www.daniellnagle.com/coco.html}).
+supported by the GNU Fortran compiler.
