[PATCHES, Committed] As obvious
Committed as obvious: commit 061b13ed014ba0b6891800a5c7f852bf58e4d856 Author: Jerry DeLisle Date: Thu Feb 16 18:13:56 2023 -0800 Fortran Tests: Allow passing on mingw. gcc/testsuite/ChangeLog: * gfortran.dg/bind_c_array_params_2.f90: Add *-*-ming* to dg-final. and commit f978585c2939691176ad8d3fa9c2e4e91ed18bf4 (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Thu Feb 16 19:29:44 2023 -0800 Fortran test: Modify test cases to pass on mingw. gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_14.f90: Change example function to CLOCK which is available on mingw as well as other platforms. * gfortran.dg/pr96486.f90: Change variable to PATH likewise.
[patch, fortran] PR103506 [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c
Attached patch fixes this problem by allowing the namespace pointer to
be set correctly regardless of error condition.
Regression tested on x86_64_linux_gnu.
OK for trunk and backports?
Regards,
Jerry
Author: Jerry DeLisle
Date: Sat Jan 28 20:00:34 2023 -0800
ICE in gfc_free_namespace. ice-on-invalid.
PR fortran/103506
gcc/fortran/ChangeLog:
* parse.cc (parse_module): Remove use of a bool error value
that prevented proper setting of the namespace pointer.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr103506_1.f90: New test.diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 0fb19cc9f0f..039e7e7da53 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -6502,7 +6502,6 @@ parse_module (void)
{
gfc_statement st;
gfc_gsymbol *s;
- bool error;
s = gfc_get_gsymbol (gfc_new_block->name, false);
if (s->defined || (s->type != GSYM_UNKNOWN && s->type != GSYM_MODULE))
@@ -6525,7 +6524,6 @@ parse_module (void)
st = parse_spec (ST_NONE);
- error = false;
loop:
switch (st)
{
@@ -6544,16 +6542,11 @@ loop:
default:
gfc_error ("Unexpected %s statement in MODULE at %C",
gfc_ascii_statement (st));
-
- error = true;
reject_statement ();
st = next_statement ();
goto loop;
}
-
- /* Make sure not to free the namespace twice on error. */
- if (!error)
-s->ns = gfc_current_ns;
+ s->ns = gfc_current_ns;
}
diff --git a/gcc/testsuite/gfortran.dg/pr103506_1.f90 b/gcc/testsuite/gfortran.dg/pr103506_1.f90
new file mode 100644
index 000..3f57809e099
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103506_1.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR103506 ICE in gfc_free_namespace. ice-on-invalid
+! Test case from the PR.
+module m ! { dg-error "is already being used as a MODULE" }
+stop ! { dg-error "Unexpected STOP statement in MODULE" }
+end
+program p
+call m ! { dg-error "is already being used as a MODULE" }
+end
[patch, gfortran.dg] Allow test to pass on mingw
Hi all,
Similar to a patch I committed a while ago for Cygwin, the attached
patch allows it to pass on the mingw version of gfortran.
It is trivial.
Ok for trunk?
Regards,
Jerrydiff --git a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
index 8dd7e8fb088..04faa433435 100644
--- a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
+++ b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
@@ -16,9 +16,9 @@ integer :: aa(4,4)
call test(aa)
end
-! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { ! { hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix*} } } } }
+! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { ! { hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix* *-*-ming* } } } } }
! { dg-final { scan-assembler-times "myBindC,%r2" 1 { target { hppa*-*-* } } } }
-! { dg-final { scan-assembler-times "call\tmyBindC" 1 { target { *-*-cygwin* } } } }
+! { dg-final { scan-assembler-times "call\tmyBindC" 1 { target { *-*-cygwin* *-*-ming* } } } }
! { dg-final { scan-assembler-times "brasl\t%r\[0-9\]*,myBindC" 1 { target { s390*-*-* } } } }
! { dg-final { scan-assembler-times "bl \.myBindC" 1 { target { powerpc-ibm-aix* } } } }
! { dg-final { scan-assembler-times "add_u32\t\[sv\]\[0-9\]*, \[sv\]\[0-9\]*, myBindC@rel32@lo" 1 { target { amdgcn*-*-* } } } }
[patch, fortran] ICE in attr_decl1, at fortran/decl.c:8691
The attached patch was provided by Steve Kargl. After exploring for
possible other checks I settled on leaving the patch intact.
Two existing test cases updated as different but sensible error messages
resulted.
Regression tested on main line.
OK to commit?
Regards,
Jerry
Author: Steve Kargl
Date: Mon Dec 26 14:07:04 2022 -0800
Modify checks to avoid referencing NULL pointer.
Update test cases with error messages that changed as a result.
gcc/fortran/ChangeLog:
* decl.cc (attr_decl1): Guard against NULL pointer.
* parse.cc (match_deferred_characteristics): Include
BT_CLASS in check for
derived being undefined.
gcc/testsuite/ChangeLog:
* gfortran.dg/class_result_4.f90: Update error message check.
* gfortran.dg/pr85779_3.f90: Update error message check.diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index e593518a77e..bac7b6568b0 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -8743,7 +8743,9 @@ attr_decl1 (void)
/* Update symbol table. DIMENSION attribute is set in
gfc_set_array_spec(). For CLASS variables, this must be applied
to the first component, or '_data' field. */
- if (sym->ts.type == BT_CLASS && sym->ts.u.derived->attr.is_class)
+ if (sym->ts.type == BT_CLASS
+ && sym->ts.u.derived
+ && sym->ts.u.derived->attr.is_class)
{
/* gfc_set_array_spec sets sym->attr not CLASS_DATA(sym)->attr. Check
for duplicate attribute here. */
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index bc2b2188eea..6186c48aee2 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -3934,7 +3934,7 @@ match_deferred_characteristics (gfc_typespec * ts)
m = gfc_match_prefix (ts);
gfc_buffer_error (false);
- if (ts->type == BT_DERIVED)
+ if (ts->type == BT_DERIVED || ts->type == BT_CLASS)
{
ts->kind = 0;
@@ -4215,7 +4215,7 @@ declSt:
if (bad_characteristic)
{
ts = _current_block ()->result->ts;
- if (ts->type != BT_DERIVED)
+ if (ts->type != BT_DERIVED && ts->type != BT_CLASS)
gfc_error ("Bad kind expression for function %qs at %L",
gfc_current_block ()->name,
_current_block ()->declared_at);
diff --git a/gcc/testsuite/gfortran.dg/class_result_4.f90 b/gcc/testsuite/gfortran.dg/class_result_4.f90
index 4b22a3c30ee..5497ac652ec 100644
--- a/gcc/testsuite/gfortran.dg/class_result_4.f90
+++ b/gcc/testsuite/gfortran.dg/class_result_4.f90
@@ -1,6 +1,6 @@
! { dg-do compile }
! PR fortran/78500
-class(t) function f() ! { dg-error "must be dummy, allocatable or pointer" }
+class(t) function f() ! { dg-error "is not accessible" }
f = 1 ! { dg-error "variable must not be polymorphic" }
end
diff --git a/gcc/testsuite/gfortran.dg/pr85779_3.f90 b/gcc/testsuite/gfortran.dg/pr85779_3.f90
index fba1133b3ea..a81a9faf88e 100644
--- a/gcc/testsuite/gfortran.dg/pr85779_3.f90
+++ b/gcc/testsuite/gfortran.dg/pr85779_3.f90
@@ -1,6 +1,6 @@
! { dg-do compile }
! PR fortran/85779
-class(t) function f() ! { dg-error "must be dummy, allocatable or pointer" }
+class(t) function f() ! { dg-error "is not accessible" }
type f ! { dg-error "already has a basic type" }
end type ! { dg-error "END FUNCTION statement" }
end
Re: [PATCH, Fortran] PR fortran/93524 - ISO_Fortran_binding signed char arrays
Looks good and I have tested. I will commit after one more double check
for regressions with the test case in the testsuite
I have been following Harris on this one for several days and tested the
patch before submitted here.
Thanks for patch Harris, much appreciated.
Regards,
Jerry
On 1/13/21 8:02 AM, Harris Snyder wrote:
On Wed, Jan 13, 2021 at 1:34 AM Harris Snyder wrote:
Hi everyone,
Sorry, my previous email erroneously referred to unsigned chars / uint8_t,
when I in fact meant signed chars / int8_t. The actual patch works, but the
test case files have ‘uint’ in the file names. I’ll provide a corrected patch
tomorrow to fix the file names.
Harris
Corrected patch below.
OK for master? I don't have write access so I will need someone else
to commit this for me if possible.
Thanks,
Harris Snyder
Fixes a bug in ISO_Fortran_binding.c whereby signed char or int8_t
arrays would cause crashes unless an element size is specified.
Related to PR fortran/93524.
libgfortran/ChangeLog:
* runtime/ISO_Fortran_binding.c (CFI_establish): fixed signed char arrays.
gcc/testsuite/ChangeLog:
* gfortran.dg/iso_fortran_binding_int8_array.f90: New test.
* gfortran.dg/iso_fortran_binding_int8_array_driver.c: New test.
diff --git a/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array.f90
b/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array.f90
new file mode 100644
index 000..31fdf863e0a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array.f90
@@ -0,0 +1,11 @@
+! { dg-do run }
+! { dg-additional-sources iso_fortran_binding_int8_array_driver.c }
+
+module m
+ use iso_c_binding
+contains
+ subroutine fsub( x ) bind(C, name="fsub")
+ integer(c_int8_t), intent(inout) :: x(:)
+ x = x+1
+ end subroutine
+end module
diff --git a/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array_driver.c
b/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array_driver.c
new file mode 100644
index 000..84ed127d525
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array_driver.c
@@ -0,0 +1,25 @@
+#include
+#include
+#include
+#include "ISO_Fortran_binding.h"
+
+extern void fsub(CFI_cdesc_t *);
+
+int main(void)
+{
+ int8_t x[] = {1,2,3,4};
+ int N = sizeof(x)/sizeof(x[0]);
+
+ CFI_CDESC_T(1) dat;
+ CFI_index_t ext[1];
+ ext[0] = (CFI_index_t)N;
+ int rc = CFI_establish((CFI_cdesc_t *), , CFI_attribute_other,
+ CFI_type_int8_t, 0, (CFI_rank_t)1, ext);
+ printf("CFI_establish call returned: %d\n", rc);
+
+ fsub((CFI_cdesc_t *) );
+
+ for (int i=0; ibase_addr = base_addr;
if (type == CFI_type_char || type == CFI_type_ucs4_char ||
- type == CFI_type_signed_char || type == CFI_type_struct ||
- type == CFI_type_other)
+ type == CFI_type_struct || type == CFI_type_other)
dv->elem_len = elem_len;
else
{
Re: Ping: [Patch, fortran] PR97694 - ICE with optional assumed rank class(*) argument (and PR97723)
LGTM Paul, go for it. On 12/26/20 8:37 AM, Paul Richard Thomas via Fortran wrote: Ping! On Sat, 12 Dec 2020 at 10:38, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: Fortran: Fix some select rank issues [PR97694 and 97723]. Hi All, Unlike select type, select rank selectors retain the allocatable attribute. This is corrected by the chunk in check.c. Note the trailing whitespace corrections. Resolution of select rank construct must be done in the same way as select type and so the break has been added to ensure that the block is resolved in resolve_select_rank. The final chunk prevents segfaults for class associate variables that are optional dummies, since these apparently are not adorned with the GFC_DECL_SAVED_DESCRIPTOR. Regtests OK on FC31/x86_64 - OK for master? Cheers Paul 2020-12-12 Paul Thomas gcc/fortran PR fortran/97694 PR fortran/97723 * check.c (allocatable_check): Select rank temporaries are permitted even though they are treated as associate variables. * resolve.c (gfc_resolve_code): Break on select rank as well as select type so that the block os resolved. * trans-stmt.c (trans_associate_var): Class associate variables that are optional dummies must use the backend_decl. gcc/testsuite/ PR fortran/97694 PR fortran/97723 * gfortran.dg/select_rank_5.f90: New test.
Re: *PING* [PATCH] PR fortran/90903 [part2] Add runtime checking for the MVBITS intrinsic
Harold, Looks good. Thanks for the work! Jerry On 9/20/20 11:10 AM, Harald Anlauf wrote: *ping* Gesendet: Sonntag, 13. September 2020 um 23:24 Uhr Von: "Harald Anlauf" An: "fortran" , "gcc-patches" Cc: "Paul Richard Thomas" Betreff: [PATCH] PR fortran/90903 [part2] Add runtime checking for the MVBITS intrinsic Dear all, finally here comes the second part of runtime checks for the bit manipulation intrinsics, this time MVBITS. This turned out to be more elaborate than the treatment of simple function calls. I chose the path to inline expand MVBITS, which enables additional optimization opportunities in some cases, such as constant arguments. For the case of scalar arguments, this was mostly straightforward. However, for the proper handling of MVBITS as an elemental procedure all honors should go to Paul, as he not only lend me a hand and kindly guided me through the swampland of the scalarizer, but he also managed to placate the gimple part of gcc. Regtested on x86_64-pc-linux-gnu. OK for master? Thanks, Harald PR fortran/90903 [part2] - Add runtime checking for the MVBITS intrinsic Implement inline expansion of the intrinsic elemental subroutine MVBITS with optional runtime checks for valid argument range. gcc/fortran/ChangeLog: * iresolve.c (gfc_resolve_mvbits): Remove unneeded conversion of FROMPOS, LEN and TOPOS arguments to fit a C int. * trans-intrinsic.c (gfc_conv_intrinsic_mvbits): Add inline expansion of MVBITS intrinsic elemental subroutine and add code for runtime argument checking. (gfc_conv_intrinsic_subroutine): Recognise MVBITS intrinsic, but defer handling to gfc_trans_call. * trans-stmt.c (replace_ss): (gfc_trans_call): Adjust to handle inline expansion, scalarization of intrinsic subroutine MVBITS in gfc_conv_intrinsic_mvbits. * trans.h (gfc_conv_intrinsic_mvbits): Add prototype for gfc_conv_intrinsic_mvbits. gcc/testsuite/ChangeLog: * gfortran.dg/check_bits_2.f90: New test. Co-authored-by: Paul Thomas
Re: [PATCH] PR fortran/97036 - [F2018] Allow ELEMENTAL RECURSIVE procedure prefix
ok, thanks . On 9/15/20 1:35 PM, Harald Anlauf wrote: As stated in the PR, the Fortran 2018 standard removed the restriction prohibiting ELEMENTAL RECURSIVE procedures. Adjust the relevant check. Regtested on x86_64-pc-linux-gnu. OK for master? Thanks, Harald PR fortran/97036 - [F2018] Allow ELEMENTAL RECURSIVE procedure prefix gcc/fortran/ChangeLog: * symbol.c (gfc_check_conflict): Allow ELEMENTAL RECURSIVE procedure prefix for -std=f2018. gcc/testsuite/ChangeLog: * gfortran.dg/pr97036.f90: New test.
Re: [PATCH] Fortran : rejected f0.d edit descriptor PR96436
On 8/17/20 12:31 AM, Mark Eggleston wrote: Please find attached a patch for PR96436. OK to commit? Looks good to me. Thanks for fixing this. Regards, Jerry
Re: [Patch, fortran] PR93671 - gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray
This look good, OK to commit. Thanks, Jerry On 8/10/20 8:03 AM, Andre Vehreschild wrote: Hi folks, long time, no see. I was asked by Damian to do some Coarray stuff in gfortran so here is the first step on fixing a bug. The issue at hand is, that the coarray handling is not propagated correctly and later on the coarray-token not generated/retrieved from the correct position leading to coarray programs to crash/hang. This patch fixes at least the misbehavior reported in the PR. More to come. Regtests ok on FC31.x86_64. Ok for trunk? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] Fortran : ICE in gfc_check_reshape PR95585
OK to commit and Backport. On 6/18/20 1:11 AM, Mark Eggleston wrote: Please find attached fix for PR95585. OK to commit and backport? Commit message: Fortran : ICE in gfc_check_reshape PR95585 Issue an error where an array is used before its definition instead of an ICE. 2020-06-18 Steven G. Kargl gcc/fortran/ PR fortran/PR95585 *check.c (gfc_check_reshape): Add check for a value when the symbol has an attribute flavor FL_PARAMETER. 2020-06-17 Mark Eggleston gcc/testsuite/ PR fortran/95585 * gfortran.dg/pr95585.f90: New test.
Re: [PATCH] Fortran : ICE in gfc_check_pointer_assign PR95612
OK to commit and backport. On 6/30/20 11:12 PM, Mark Eggleston wrote: Please find attached a patch which is a fix for PR95612. The original patch is by Steve Kargl. OK to commit and backport? Commit message: Fortran : ICE in gfc_check_pointer_assign PR95612 Output an error if the right hand value is a zero sized array or does not have a symbol tree otherwise continue checking. 2020-07-01 Steven G. Kargl gcc/fortran/ PR fortran/95612 * expr.c (gfc_check_pointer_assigb): Output an error if rvalue is a zero sized array or output an error if rvalue doesn't have a symbol tree. 2020-07-01 Mark Eggleston gcc/testsuite/ PR fortran/95612 * gfortran.dg/pr95612.f90: New test.
Re: [PATCH] Fortran : Fill in missing array dimensions using the lower, bound (for review)
On 6/27/20 1:40 AM, Thomas Koenig via Fortran wrote: Hi Mark, Use -fdec-add-missing-indexes to enable feature. Also enabled by fdec. A warning that the lower bound is being used for a mission dimension is output unless suppressed by using -Wno-missing-index. This is... seriously problematic. I forsee all sorts of not-so-funny interactions with more modern features. What do people actually do with this kind of code? What kind of test cases do you have that "work" with this? And people would actually want to save a few keystrokes so they don't have to write A(N,M,1) instead of A(N,M)? And is this even the right fix, how sure are you of the semantics; is there documentation for this feature (maybe on Bitsavers)? If not, this is not be done. If this goes in at all, I want this rejected with any modern Fortran feature, i.e. it should not be contain - allocatable arrays - coarrays - pointers - derived types - CLASS - assumed-shape arrays - assumed-rank arrays (well, it probably doesn't make sense) - KIND=4 characters - as an argument to any of the array intrinsics like MATMUL, EOSHIFT, ... but even with these restrictions, I will still take a lot of convincing that this make sense. Just imagine what will happen if people specify -fdec for some relatively benign reason (for example because they want -fdec-math) and start not finding bugs in their code because of this feature. Best regards Thomas Please stop fixing problematic DEC programs by using the compiler as the pet tool. Use an editor or python or some suitable tool to initialize arrays properly. I appreciate the effort, but need things run by here before the effort so you can spend the effort on really true compiler bugs, and not on the wishes of perhaps a paying customer. We should never have caved on the previous DEC enhancement. Just my humble opinion. Jerry
Re: [PATCH] PR fortran/95707 - ICE in finish_equivalences, at fortran/trans-common.c:1319
OK, and once again, thanks. Jerry On 6/17/20 12:27 PM, Harald Anlauf wrote: Another corner case of buffer overflows during name mangling found by Gerhard. We now check that the new buffer sizes suffice. The patch is on top of the patches for PRs 95687, 95688, 95689. Regtested on x86_64-pc-linux-gnu. OK for master / backports? Thanks, Harald PR fortran/95707 - ICE in finish_equivalences, at fortran/trans-common.c:1319 With submodules and equivalence declarations, name mangling may result in long internal symbols overflowing internal buffers. We now check that we do not exceed the enlarged buffer sizes. gcc/fortran/ PR fortran/95707 * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (gfc_sym_mangled_common_id): Enlarge temporary buffers, and add check on length on mangled name to prevent overflow.
Re: [PATCH] PR fortran/95827 - Buffer overflows with PDTs and long symbols
OK, and thanks for Patch. On 6/23/20 2:08 PM, Harald Anlauf wrote: Dear all, here's another case with a buffer that did overflow. Regtested on x86_64-pc-linux-gnu. OK for master / backports? Thanks, Harald PR fortran/95827 - Buffer overflows with PDTs and long symbols With submodules and coarrays, name mangling results in long internal symbols. Enlarge internal buffer. gcc/fortran/ PR fortran/95827 * iresolve.c (gfc_get_string): Enlarge internal buffer used in generating the mangled name.
