[patch, libgfortran] PR99210 X editing for reading file with encoding='utf-8'
The attached patch fixes the X editing.
Fairly self explanatory. I created the patch a few years back.
Regression tested on x86_64 and new test case.
OK for trunk?
Regards,
Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr99210.f90 b/gcc/testsuite/gfortran.dg/pr99210.f90
new file mode 100644
index 000..9fd2fb468df
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr99210.f90
@@ -0,0 +1,29 @@
+! { dg-do run }
+! PR99210 X editing for reading file with encoding='utf-8'
+program test_bug_format_x
+ use iso_fortran_env
+ integer, parameter :: u = selected_char_kind('ISO_10646')
+
+ character(kind=u, len=1) a, b, a1, b1, b2
+
+ open(unit=10, file='test_bug_format_x.tmp', encoding='UTF-8')
+
+ a = char(int(z'03B1'), u)
+ b = char(int(z'03B2'), u)
+ write(10, '(a1, a1)') a, b
+
+ rewind(10)
+ read(10, '(a1, a1)') a1, b1
+
+ rewind(10)
+ read(10, '(1x, a1)') b2
+
+ close (10, status="delete")
+ if(a /= a1 .or. b /= b1) then
+error stop 1
+ end if
+
+ if(b /= b2) then
+error stop 2
+ end if
+end program test_bug_format_x
diff --git a/libgfortran/io/read.c b/libgfortran/io/read.c
index 0ffcf76fd38..e2d2f8be806 100644
--- a/libgfortran/io/read.c
+++ b/libgfortran/io/read.c
@@ -1307,6 +1307,23 @@ read_x (st_parameter_dt *dtp, size_t n)
if (n == 0)
return;
+
+ if (dtp->u.p.current_unit->flags.encoding == ENCODING_UTF8)
+{
+ gfc_char4_t c;
+ size_t nbytes, j;
+
+ /* Proceed with decoding one character at a time. */
+ for (j = 0; j < n; j++)
+ {
+ c = read_utf8 (dtp, &nbytes);
+
+ /* Check for a short read and if so, break out. */
+ if (nbytes == 0 || c == (gfc_char4_t)0)
+ break;
+ }
+ return;
+}
length = n;
Re: Mattermost discussion on PR98426
On Fri, Apr 26, 2024, 2:47 AM Tobias Burnus wrote: > Hi Bernhard, hello all, > Bernhard Reutner-Fischer wrote: > > PS: unfortunately the git branch > (https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool > ) mentioned in mail (I) lived in the old git, before we switched to > git, and i fear that branch maybe got lost. > > Try gcc-old.git instead: > > > https://gcc.gnu.org/git/?p=gcc-old.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool > Tobias > Thanks for all this information. At least we don't start from zero. Jerry - >
Re: [Ping, Fortran, Patch, PR85510, v2] Fix coarray token in associate not linking
Ok and thanks. On Fri, Aug 9, 2024, 7:33 AM Andre Vehreschild wrote: > Ping! > > And the last ping in the series. I have a "bigger" patch in the queue and > want > the pending ones done beforehand. > > Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? > > - Andre > > On Mon, 22 Jul 2024 16:35:28 +0200 > Andre Vehreschild wrote: > > > Hi all, hi Paul, > > > > you asked me to have a look at PR85510 (which the associate meta bug is > > blocked by). I have come up with the cause. The symbol of the coarray is > > deemed to be host_associated and therefore the caf_token is not created > in > > the correct scope. I am not familiar with host-association, so my > solution > > may be wrong. The essence of my patch is to ensure, that the namespace > the > > symbol is in is not caused by an associate command. I hope this is the > way to > > go. > > > > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? > > > > Regards, > > Andre > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de >
Re: [Patch] Fortran: Fix libgfortran I/O race with newunit_free [PR99529]
Looks good Tobias, OK, Odd about that line in set_internal_unit. Probably leftover from a copy/paste. I see in comment #5 of the PR that you mentioned trying the assert to make sure it is useless code. Thanks for the patch, Jerry On 3/11/21 2:38 AM, Tobias Burnus wrote: Revised version – the previous had a lock inversion, which could lead to a deadlock, found by -fsanitize=thread. See transfer.c for the changes. OK? Tobias On 11.03.21 10:42, Tobias Burnus wrote: Hi all, as found by Martin (thanks!) there is a race for newunit_free. While that call is within the unitlock for the calls in io/unit.c, the call in transfer.c did not use locks. Additionally, unit = get_gfc_unit (dtp->common.unit, do_create); set_internal_unit (dtp, unit, kind); gets first the unit (with proper locking when using the unit number dtp->common.unit) but then in set_internal_unit it re-sets the unit number to the same number without locking. That causes race warnings and if the assignment is not atomic it is a true race. OK for mainline? What about GCC 10? As Martin notes in the email thread and in the PR there are more race warnings (and likely true race issues). Tobias
Re: 12 PR fixed
I have reviewed this and all looks good.
I also regression tested on x86_64-pc-linux-gnu.
I don't want to do a bunch of individual commits.
Steve, if you can do a ChangeLog I can commit in one blast.
Regards,
Jerry
On 3/13/21 1:33 PM, Steve Kargl via Fortran wrote:
The following patch fixes 91960, 93635, 95501, 95502, 95710, 96013,
96025, 97122, 99256, 99349, 99351, and 99506. Most of the individual
patches are languishing in bugzilla. One or two needed to reformatted
due to divergences in main and my local repository. Please commit.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 82db8e4e1b2..63138cfa9bc 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1009,6 +1009,14 @@ kind_value_check (gfc_expr *e, int n, int k)
static bool
variable_check (gfc_expr *e, int n, bool allow_proc)
{
+ /* Expecting a variable, not an alternate return. */
+ if (!e)
+{
+ gfc_error ("%qs argument of %qs intrinsic must be a variable",
+gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic);
+ return false;
+}
+
if (e->expr_type == EXPR_VARIABLE
&& e->symtree->n.sym->attr.intent == INTENT_IN
&& (gfc_current_intrinsic_arg[n]->intent == INTENT_OUT
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 947e4f868a1..9039c9dca2a 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -410,9 +410,7 @@ match_data_constant (gfc_expr **result)
/* If a parameter inquiry ends up here, symtree is NULL but **result
contains the right constant expression. Check here. */
if ((*result)->symtree == NULL
- && (*result)->expr_type == EXPR_CONSTANT
- && ((*result)->ts.type == BT_INTEGER
- || (*result)->ts.type == BT_REAL))
+ && (*result)->expr_type == EXPR_CONSTANT)
return m;
/* F2018:R845 data-stmt-constant is initial-data-target.
@@ -1772,12 +1770,6 @@ gfc_set_constant_character_len (gfc_charlen_t len,
gfc_expr *expr,
if (expr->ts.type != BT_CHARACTER)
return;
- if (expr->expr_type != EXPR_CONSTANT)
-{
- gfc_error_now ("CHARACTER length must be a constant at %L",
&expr->where);
- return;
-}
-
slen = expr->value.character.length;
if (len != slen)
{
@@ -11495,8 +11487,9 @@ gfc_match_final_decl (void)
block = gfc_state_stack->previous->sym;
gcc_assert (block);
- if (!gfc_state_stack->previous || !gfc_state_stack->previous->previous
- || gfc_state_stack->previous->previous->state != COMP_MODULE)
+ if (!gfc_state_stack->previous->previous
+ && gfc_state_stack->previous->previous->state != COMP_MODULE
+ && gfc_state_stack->previous->previous->state != COMP_SUBMODULE)
{
gfc_error ("Derived type declaration with FINAL at %C must be in the"
" specification part of a MODULE");
@@ -11505,7 +11498,6 @@ gfc_match_final_decl (void)
module_ns = gfc_current_ns;
gcc_assert (module_ns);
- gcc_assert (module_ns->proc_name->attr.flavor == FL_MODULE);
/* Match optional ::, don't care about MATCH_YES or MATCH_NO. */
if (gfc_match (" ::") == MATCH_ERROR)
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 92a6700568d..e1acc2db000 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3476,6 +3476,7 @@ gfc_specification_expr (gfc_expr *e)
{
gfc_error ("Expression at %L must be of INTEGER type, found %s",
&e->where, gfc_basic_typename (e->ts.type));
+ gfc_clear_ts (&e->ts);
return false;
}
@@ -3815,6 +3816,9 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue,
int proc_pointer;
bool same_rank;
+ if (!lvalue->symtree)
+return false;
+
lhs_attr = gfc_expr_attr (lvalue);
if (lvalue->ts.type == BT_UNKNOWN && !lhs_attr.proc_pointer)
{
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 4d5890fd523..86aabf4a840 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -1409,7 +1409,7 @@ gfc_match_pointer_assignment (void)
gfc_matching_procptr_assignment = 0;
m = gfc_match (" %v =>", &lvalue);
- if (m != MATCH_YES)
+ if (m != MATCH_YES || !lvalue->symtree)
{
m = MATCH_NO;
goto cleanup;
@@ -3867,6 +3867,15 @@ sync_statement (gfc_statement st)
stat = tmp;
saw_stat = true;
+ if (tmp->symtree
+ && (tmp->symtree->n.sym->attr.flavor == FL_PARAMETER
+ || tmp->symtree->n.sym->ts.type != BT_INTEGER))
+ {
+ gfc_error ("Expecting scalar-int-variable at %L",
+&tmp->where);
+ goto cleanup;
+ }
+
if (gfc_match_char (',') == MATCH_YES)
continue;
@@ -3884,6 +3893,16 @@ sync_statement (gfc_statement st)
gfc_error ("Redundant ERRMSG tag found at %L", &tmp->where);
goto cleanup;
}
+
+ if (tmp->symtree
+ && (tmp-
Re: 12 PR fixed
Well, I am seeing the falling upon a closer look. I do not know if
related to the patch yet. Lets make sure this is fixed.
FAIL: gfortran.dg/pr87907.f90 -O (internal compiler error)
FAIL: gfortran.dg/pr87907.f90 -O (test for excess errors)
FAIL: gfortran.dg/pr96013.f90 -O (test for excess errors)
FAIL: gfortran.dg/pr96025.f90 -O (internal compiler error)
FAIL: gfortran.dg/pr96025.f90 -O (test for errors, line 5)
FAIL: gfortran.dg/pr96025.f90 -O (test for excess errors)
On 3/13/21 8:46 PM, Jerry DeLisle wrote:
I have reviewed this and all looks good.
I also regression tested on x86_64-pc-linux-gnu.
I don't want to do a bunch of individual commits.
Steve, if you can do a ChangeLog I can commit in one blast.
Regards,
Jerry
On 3/13/21 1:33 PM, Steve Kargl via Fortran wrote:
The following patch fixes 91960, 93635, 95501, 95502, 95710, 96013,
96025, 97122, 99256, 99349, 99351, and 99506. Most of the individual
patches are languishing in bugzilla. One or two needed to reformatted
due to divergences in main and my local repository. Please commit.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 82db8e4e1b2..63138cfa9bc 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1009,6 +1009,14 @@ kind_value_check (gfc_expr *e, int n, int k)
static bool
variable_check (gfc_expr *e, int n, bool allow_proc)
{
+ /* Expecting a variable, not an alternate return. */
+ if (!e)
+ {
+ gfc_error ("%qs argument of %qs intrinsic must be a variable",
+ gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic);
+ return false;
+ }
+
if (e->expr_type == EXPR_VARIABLE
&& e->symtree->n.sym->attr.intent == INTENT_IN
&& (gfc_current_intrinsic_arg[n]->intent == INTENT_OUT
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 947e4f868a1..9039c9dca2a 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -410,9 +410,7 @@ match_data_constant (gfc_expr **result)
/* If a parameter inquiry ends up here, symtree is NULL but
**result
contains the right constant expression. Check here. */
if ((*result)->symtree == NULL
- && (*result)->expr_type == EXPR_CONSTANT
- && ((*result)->ts.type == BT_INTEGER
- || (*result)->ts.type == BT_REAL))
+ && (*result)->expr_type == EXPR_CONSTANT)
return m;
/* F2018:R845 data-stmt-constant is initial-data-target.
@@ -1772,12 +1770,6 @@ gfc_set_constant_character_len (gfc_charlen_t
len, gfc_expr *expr,
if (expr->ts.type != BT_CHARACTER)
return;
- if (expr->expr_type != EXPR_CONSTANT)
- {
- gfc_error_now ("CHARACTER length must be a constant at %L",
&expr->where);
- return;
- }
-
slen = expr->value.character.length;
if (len != slen)
{
@@ -11495,8 +11487,9 @@ gfc_match_final_decl (void)
block = gfc_state_stack->previous->sym;
gcc_assert (block);
- if (!gfc_state_stack->previous ||
!gfc_state_stack->previous->previous
- || gfc_state_stack->previous->previous->state != COMP_MODULE)
+ if (!gfc_state_stack->previous->previous
+ && gfc_state_stack->previous->previous->state != COMP_MODULE
+ && gfc_state_stack->previous->previous->state != COMP_SUBMODULE)
{
gfc_error ("Derived type declaration with FINAL at %C must be
in the"
" specification part of a MODULE");
@@ -11505,7 +11498,6 @@ gfc_match_final_decl (void)
module_ns = gfc_current_ns;
gcc_assert (module_ns);
- gcc_assert (module_ns->proc_name->attr.flavor == FL_MODULE);
/* Match optional ::, don't care about MATCH_YES or MATCH_NO. */
if (gfc_match (" ::") == MATCH_ERROR)
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 92a6700568d..e1acc2db000 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3476,6 +3476,7 @@ gfc_specification_expr (gfc_expr *e)
{
gfc_error ("Expression at %L must be of INTEGER type, found %s",
&e->where, gfc_basic_typename (e->ts.type));
+ gfc_clear_ts (&e->ts);
return false;
}
@@ -3815,6 +3816,9 @@ gfc_check_pointer_assign (gfc_expr *lvalue,
gfc_expr *rvalue,
int proc_pointer;
bool same_rank;
+ if (!lvalue->symtree)
+ return false;
+
lhs_attr = gfc_expr_attr (lvalue);
if (lvalue->ts.type == BT_UNKNOWN && !lhs_attr.proc_pointer)
{
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 4d5890fd523..86aabf4a840 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -1409,7 +1409,7 @@ gfc_match_pointer_assignment (void)
gfc_matching_procptr_assignment = 0;
m = gfc_match (" %v =>", &lvalue);
- if (m != MATCH_YES)
+ if (m != MATCH_YES || !lvalue->
Re: 12 PR fixed
I can convert the tabs/spaces no problem.
On 3/14/21 5:01 AM, Tobias Burnus wrote:
Small additional remark: I see new lines which use 8 spaces instead of
a tab – that should also be fixed.
And: Please don't forget to CC gcc-patches@ as well.
Thanks,
Tobias
On 14.03.21 12:38, Tobias Burnus wrote:
On 14.03.21 06:13, Jerry DeLisle wrote:
Well, I am seeing the falling upon a closer look. I do not know if
related to the patch yet. Lets make sure this is fixed.
FAIL: gfortran.dg/pr87907.f90 -O (internal compiler error)
FAIL: gfortran.dg/pr87907.f90 -O (test for excess errors)
FAIL: gfortran.dg/pr96013.f90 -O (test for excess errors)
FAIL: gfortran.dg/pr96025.f90 -O (internal compiler error)
FAIL: gfortran.dg/pr96025.f90 -O (test for errors, line 5)
FAIL: gfortran.dg/pr96025.f90 -O (test for excess errors)
I do see the failure with the new patch applied –
and the testcase from the patchset for:
@@ -0,0 +1,10 @@
+! { dg-do compile }
+module m
+ type t
+ end type
+contains
+ function f() result(t)
+ character(3) :: c
+ c = 'abc'
+ end
+end
The problem is that for:
#6 0x008c1195 in gfc_error (gmsgid=gmsgid@entry=0x1bfbdbe
"Invalid symbol %qs at %L") at ../../repos/gcc/gcc/fortran/error.c:1381
#7 0x00904204 in write_symbol (n=,
sym=0x2905350) at ../../repos/gcc/gcc/fortran/module.c:5892
#8 0x00904272 in write_symbol1_recursion (sp=out>) at ../../repos/gcc/gcc/fortran/module.c:6122
#9 0x00907136 in write_symbol1 (p=) at
../../repos/gcc/gcc/fortran/module.c:6155
#10 write_module () at ../../repos/gcc/gcc/fortran/module.c:6302
#11 dump_module (name=, name@entry=0x77189120 "m",
dump_flag=dump_flag@entry=1) at
../../repos/gcc/gcc/fortran/module.c:6431
namely:
5889 if ((sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor ==
FL_LABEL)
5890 && !(sym->ts.type != BT_UNKNOWN && sym->attr.result))
5891 {
5892 gfc_error ("Invalid symbol %qs at %L", sym->name,
5893 &sym->declared_at);
sym->name is invalid.
valgrind shows:
==61032== Invalid read of size 1
==61032== at 0x90411C: write_symbol(int, gfc_symbol*) (module.c:5889)
==61032== by 0x904271:
write_symbol1_recursion(sorted_pointer_info*) (module.c:6122)
==61032== by 0x907135: write_symbol1 (module.c:6155)
==61032== by 0x907135: write_module (module.c:6302)
==61032== by 0x907135: dump_module(char const*, int) (module.c:6431)
==61032== by 0x907494: gfc_dump_module(char const*, int)
(module.c:6488)
==61032== by 0x922643: gfc_parse_file() (parse.c:6509)
==61032== by 0x971063: gfc_be_parse_file() (f95-lang.c:212)
==61032== by 0xF23C3E: compile_file() (toplev.c:457)
==61032== by 0x88453E: do_compile (toplev.c:2201)
==61032== by 0x88453E: toplev::main(int, char**) (toplev.c:2340)
==61032== by 0x88703F: main (main.c:39)
==61032== Address 0x52207fa is 90 bytes inside a block of size 344
free'd
==61032== at 0x483CA3F: free (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==61032== by 0x93C3BE: resolve_symbol(gfc_symbol*) (resolve.c:15340)
==61032== by 0x95B7F2: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:4204)
==61032== by 0x93F2C3: resolve_types(gfc_namespace*)
(resolve.c:17326)
==61032== by 0x93F363: resolve_types(gfc_namespace*)
(resolve.c:17337)
==61032== by 0x93A80C: gfc_resolve(gfc_namespace*) [clone .part.0]
(resolve.c:17441)
==61032== by 0x921F16: gfc_parse_file() (parse.c:6495)
==61032== by 0x971063: gfc_be_parse_file() (f95-lang.c:212)
==61032== by 0xF23C3E: compile_file() (toplev.c:457)
==61032== by 0x88453E: do_compile (toplev.c:2201)
==61032== by 0x88453E: toplev::main(int, char**) (toplev.c:2340)
==61032== by 0x88703F: main (main.c:39)
==61032== Block was alloc'd at
==61032== at 0x483DD99: calloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==61032== by 0x1BBDD24: xcalloc (xmalloc.c:162)
==61032== by 0x960C4C: gfc_new_symbol(char const*, gfc_namespace*)
(symbol.c:3172)
==61032== by 0x961007: gfc_get_sym_tree(char const*,
gfc_namespace*, gfc_symtree**, bool) (symbol.c:3412)
==61032== by 0x961235: gfc_get_symbol(char const*, gfc_namespace*,
gfc_symbol**) (symbol.c:3465)
==61032== by 0x8A79C3: match_result(gfc_symbol*, gfc_symbol**)
[clone .isra.0] [clone .part.0] (decl.c:6679)
==61032== by 0x8AD29A: match_result (decl.c:6772)
==61032== by 0x8AD29A: gfc_match_suffix(gfc_symbol*, gfc_symbol**)
(decl.c:6724)
==61032== by 0x8B194C: gfc_match_function_decl() (decl.c:7387)
==61032== by 0x9182AA: decode_statement() (parse.c:343)
==61032== by 0x91C53C: next_free (parse.c:1316)
==61032== by 0x91C53C: next_statement() (parse.c:1548)
==61032== by 0x920C0A: parse_contained(int) (parse.c:5746)
==61032==
Re: [patch, fortran] Also use size estimate for vector-matrix matmul
Yes Ok for trunk. Thanks much! On 3/19/21 10:37 AM, Thomas Koenig via Fortran wrote: Hell world, here is the patch I talked about earlier. It passes regression testing. OK for trunk? Best regards Thomas Add size check to vector-matrix matmul. It turns out the library version is much faster for vector-matrix multiplications for large sizes than what inlining can produce. Use size checks for switching between this and inlining for that case to. gcc/fortran/ChangeLog: * frontend-passes.c (inline_limit_check): Add rank_a argument. If a is rank 1, set the second dimension to 1. (inline_matmul_assign): Pass rank_a argument to inline_limit_check. (call_external_blas): Likewise. gcc/testsuite/ChangeLog: * gfortran.dg/inline_matmul_6.f90: Adjust count for _gfortran_matmul.
Re: [Patch] Fortran: Fix 'name' bound size [PR99688]
Hi Tobias and others,
Reembering some of my own history, we always have used a +1 on
'LENGTH_MAX' items to allow the C null termination on strings or buffers
for obvious reasons.
Certainly OK for trunk and backports.
Regards,
Jerry
On 3/21/21 9:08 AM, Tobias Burnus wrote:
The gfc_match_select_rank issue showed up in the testsuite
and was found by Martin's asan-bootstrapped GCC. First
analysis by Harald – thanks to both!
However, I think the other variables I fixed were also
prone to overflows; see below for its usage.
OK for mainline? Other branches?
Tobias
PS: Other pending Fortran patches – please review!
[Patch] Fortran: Fix intrinsic null() handling [PR99651]
[Patch] Fortran: Fix func decl mismatch [PR93660]
PPS: Usage of 'name' in the patched functions:
resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", c->ts.u.derived->name);
select_intrinsic_set_tmp (gfc_typespec *ts)
{
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", ts->u.derived->name);
gfc_match_select_type (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, &expr2);
gfc_match_select_rank (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, &expr2);
Re: off-by-one buffer overflow patch
On 3/26/21 10:38 AM, dhumieres.dominique--- via Fortran wrote: I have proposed a similar patch in pr95998. I cannot commit to git!-( Thanks Dominique I do not see a patch in 95998. Do you need help to do a commit? Jerry
Re: off-by-one buffer overflow patch
Pushed: To git+ssh://gcc.gnu.org/git/gcc.git 651684b462f..01685676a93 master -> master Author: Steve Kargl Date: Sat Mar 27 15:02:16 2021 -0700 fortran: Fix off-by-one in buffer sizes. gcc/fortran/ChangeLog: * misc.c (gfc_typename): Fix off-by-one in buffer sizes. Regards, Jerry On 3/27/21 6:28 AM, dhumieres.domini...@free.fr wrote: Le 2021-03-27 06:36, Jerry DeLisle a écrit : On 3/26/21 10:38 AM, dhumieres.dominique--- via Fortran wrote: I have proposed a similar patch in pr95998. I cannot commit to git!-( Thanks Dominique I do not see a patch in 95998. Do you need help to do a commit? Jerry I was too quick and did not realize that I did not post the actual patch I have in my working tree, but the Steve's one does the trick. And yes I need help to do a commit. Thanks Dominique
Re: [PATCH] PR fortran/99840 - [8/9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
Yes OK for trunk and affected branches. Thanks, Jerry On 3/31/21 2:08 PM, Harald Anlauf via Fortran wrote: Dear all, the simplification of the TRANSPOSE of a zero-sized array would lead to an ICE if the result was used in a subsequent simplification of a MATMUL. The reason was the lack of the proper initialization of the shape, which is mpz_t. Use mpz_init_set instead of mpz_set. Regtested on x86_64-pc-linux-gnu. OK for mainline? Since this is a regression, backport to all affected branches? Thanks, Harald PR fortran/99840 - ICE in gfc_simplify_matmul, at fortran/simplify.c:4777 The simplification of the transposition of a constant array shall properly initialize and set the shape of the result. gcc/fortran/ChangeLog: PR fortran/99840 * simplify.c (gfc_simplify_transpose): Properly initialize resulting shape. gcc/testsuite/ChangeLog: PR fortran/99840 * gfortran.dg/transpose_5.f90: New test.
Re: [Patch, fortran] PR99818 - [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
Paul, This looks OK to me for Trunk. I believe 10 is in freeze so it may have to wait or get release manager approval. Jerry On 4/1/21 6:44 AM, Paul Richard Thomas via Fortran wrote: This one is trivial. The wrong error message was transformed by my patch for PR98897 into an ICE. This patch now produces the correct error. Regtests OK on FC33/x86_64 - OK for the affected branches? Paul Fortran: Fix ICE on wrong code [PR99818]. 2021-04-01 Paul Thomas gcc/fortran/ChangeLog PR fortran/99818 * interface.c (compare_parameter): The codimension attribute is applied to the _data field of class formal arguments. gcc/testsuite/ChangeLog PR fortran/99818 * gfortran.dg/coarray_48.f90: New test.
Re: *PING* [PATCH] PR fortran/100274 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
LGTM, OK for trunk and back ports. On 5/4/21 11:34 AM, Harald Anlauf via Fortran wrote: PING! --- Dear Fortranners, Gerhard found a case where the mismatch of actual and formal argument lead to an ICE instead of the relevant warning. Furthermore, the special case of character argument avoided the check that the actual argument must be definable if the formal one is INTENT-OUT or -INOUT. The check was already there, it just did not get triggered here. The patch is close to obvious, trivial and self-explaining. I chose to continue doing the argument checking after emitting the warning. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK for backports to the affected branches? Thanks, Harald PR fortran/100274 - ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131 When the check for the length of formal and actual character arguments found a mismatch and emitted a warning, it would skip further checks like that could lead to errors. Fix that by continuing the checking. Also catch a NULL pointer dereference. gcc/fortran/ChangeLog: PR fortran/100274 * interface.c (gfc_compare_actual_formal): Continue checks after emitting warning for argument length mismatch. * trans-expr.c (gfc_conv_procedure_call): Check for NULL pointer dereference. gcc/testsuite/ChangeLog: PR fortran/100274 * gfortran.dg/argument_checking_25.f90: New test.
Re: [PATCH] PR fortran/100602 - [11/12 Regression] Erroneous "pointer argument is not associated" runtime error
On 5/18/21 11:36 AM, Harald Anlauf via Fortran wrote: The generation of the new runtime check picked up the wrong attributes in the case of CLASS array arguments. There is related new code in gfc_conv_procedure_call which served as reference for the fix. Regtested on x86_64-pc-linux-gnu. OK for mainline / 11-branch? Thanks, Harald Fortran: Fix erroneous "pointer argument is not associated" runtime error For CLASS arrays we need to use the CLASS data attributes to determine which runtime check to generate. gcc/fortran/ChangeLog: PR fortran/100602 * trans-intrinsic.c (gfc_conv_intrinsic_size): Use CLASS data attributes for CLASS arrays for generation of runtime error. gcc/testsuite/ChangeLog: PR fortran/100602 * gfortran.dg/pointer_check_14.f90: New test. Yes, OK for both, thanks Jerry
Re: [PATCH] PR fortran/100656 - ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
On 5/26/21 2:04 PM, Harald Anlauf via Fortran wrote: Dear Fortranners, Gerhard found a case where bounds-checking for an optional, allocatable character dummy resulted in an ICE. We'd better not call the presence check on a non-dummy symbol, as this will hit an assert... Regtested on x86_64-pc-linux-gnu. OK for mainline? And backport to 11? (The code in question has not been touched for nearly 10 years, so I'm expecting this to be safe). Thanks, Harald PR fortran/100656 - prevent ICE in gfc_conv_expr_present gcc/fortran/ChangeLog: PR fortran/100656 * trans-array.c (gfc_conv_ss_startstride): Do not call check for presence of a dummy argument when a symbol actually refers to a non-dummy. gcc/testsuite/ChangeLog: PR fortran/100656 * gfortran.dg/bounds_check_22.f90: New test. Yes, OK on both. Thanks Jerry
Re: [patch, Fortran, RFC] Introduce GFC_STD_UNSIGNED
Good to go. On Fri, Oct 11, 2024, 9:06 AM Thomas Koenig wrote: > Am 11.10.24 um 18:00 schrieb Thomas Koenig: > > Hello world, > > > > the attached patch creates an unsigned "standard" for the > > gfc_option.allow_std field. > > > > One of the main reason why people want UNSIGNED for Fortran is > > interfacing for C. > > > > This is a preparation for further work on the ISO_C_BINDING constants. > > That, we do via iso-c-binding.def , whose last field is a standard > > for the constant to be defined for the standard in question, which is > > then checked. I could try and invent a different method for this, > > but I'd rather not. > > > > So, OK for trunk? Other, better ideas? > > ChangeLog was missing, here it is. Also regression-tested. > > > gcc/fortran/ChangeLog: > > * intrinsic.cc (add_functions): Convert uint and > selected_unsigned_kind to GFC_STD_UNSIGNED. > (gfc_check_intrinsic_standard): Handle GFC_STD_UNSIGNED. > * libgfortran.h (GFC_STD_UNSIGNED): Add. > * options.cc (gfc_post_options): Set GFC_STD_UNSIGNED > if -funsigned is set. >
Re: [patch, fortran] Implement maxloc and minloc for unsigned
The iparm.m4 was what I was looking for. Thanks, Jerry On Sun, Oct 6, 2024, 5:26 AM Thomas Koenig wrote: > Am 05.10.24 um 22:52 schrieb Thomas Koenig: > > Hi Jerry, > > > >> I see all the generated files in the patch, but I do not see the M4 > >> macro or other mechanism which generated these. Was this in a > >> previous submission that I missed? > > > > The "magic" in this case is mentioning them in Makefile.am and > > (regenerated) in Makefile.in. > > > > The rest is done by the previous modification to m4/iparm.m4 in > > 5d98fe096b5d17021875806ffc32ba41ea0e87b0 , which generates > > the type from the file name, in this case containing the 'm' > > as the type-specifying letter. > > To be a little bit more elaborate... > > Since the patch which removed some machinery warnings, you have to use > --enable-maintainer-mode (and do the above). The generated files will > then be in (assuming your build directory is trunk/bin and the > architecture is AMD64 on Linux) > trunk-bin/x86_64-pc-linux-gnu/libgfortran/generated > and you then have to copy what's new over to > trunk/libgfortran/generated , then do a second bootstrap, preferably in > a separate directory) without --enable-maintainer-mode to see if > everything works right. > > Best regards > > Thomas > > >
Re: [patch, fortran] Implement maxloc and minloc for unsigned
I think your good to go. Thanks for patch! On Mon, Oct 7, 2024, 2:12 AM Andre Vehreschild wrote: > Hi Thomas, > > this patch looks very similar to previous ones. I therefore deem it ok for > mainline. May be you want to wait for Jerry to voice his ok/findings > before you > apply it. > > Thanks for the patch. > > - Andre > > On Sun, 6 Oct 2024 08:58:30 -0700 > Jerry Delisle wrote: > > > The iparm.m4 was what I was looking for. Thanks, > > > > Jerry > > > > On Sun, Oct 6, 2024, 5:26 AM Thomas Koenig > wrote: > > > > > Am 05.10.24 um 22:52 schrieb Thomas Koenig: > > > > Hi Jerry, > > > > > > > >> I see all the generated files in the patch, but I do not see the M4 > > > >> macro or other mechanism which generated these. Was this in a > > > >> previous submission that I missed? > > > > > > > > The "magic" in this case is mentioning them in Makefile.am and > > > > (regenerated) in Makefile.in. > > > > > > > > The rest is done by the previous modification to m4/iparm.m4 in > > > > 5d98fe096b5d17021875806ffc32ba41ea0e87b0 , which generates > > > > the type from the file name, in this case containing the 'm' > > > > as the type-specifying letter. > > > > > > To be a little bit more elaborate... > > > > > > Since the patch which removed some machinery warnings, you have to use > > > --enable-maintainer-mode (and do the above). The generated files will > > > then be in (assuming your build directory is trunk/bin and the > > > architecture is AMD64 on Linux) > > > trunk-bin/x86_64-pc-linux-gnu/libgfortran/generated > > > and you then have to copy what's new over to > > > trunk/libgfortran/generated , then do a second bootstrap, preferably in > > > a separate directory) without --enable-maintainer-mode to see if > > > everything works right. > > > > > > Best regards > > > > > > Thomas > > > > > > > > > > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de >
Re: Building a gcc RPM
I suggest that you go get the Fedora 40 or rawhide rpm packages already built and updated. Just went search for Fedora repositories. On Sat, Sep 21, 2024, 12:42 AM Patrick Begou < patrick.be...@univ-grenoble-alpes.fr> wrote: > Hi all, > > this is a marginal question but I would like to build a rpm package of gnu > compilers (gcc, g++ and gfortran) built from the git repo to propagate the > latest version on my cluster nodes. My goal is to deploy in > /opt/GCC14/compilers/14.2.0 (as under /opt/GCC14 I will have to deploy also > some tools like OpenMPI for this compiler version) and use environment > Module to select the desired version. > > I'm able to do this with a tar.gz archive of the binaries that I can > propagate but a rpm package would be easier (or faster) to manage with > ansible. But I'm stuck for several days on this subject. Many software > provides spec files or "buildrm.sh" scripts (slurm, pmix...) and may be > some contributors or GCC users have yet done this successfully. I found > some src rpm packages but for other distributions (not el9) and I wasn't > able to use (and modify) their spec file. > > Default gcc in el9 is only 11.4.1. > > Thanks > > Patrick > >
Re: [patch, fortran] PR117765 Impure function within a BLOCK construct within a DO CONCURRENT
Thanks Paul, got it. On Mon, Nov 25, 2024, 3:13 AM Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Jerry, > > OK by me. > > A small nit: s/too/to/ in the ChangeLog. > > Thanks for the patch > > Paul > > > On Mon, 25 Nov 2024 at 02:50, Jerry D wrote: > >> I would like to commit the attached patch for Steve. >> >> Regression tested on x86-64-linux-gnu. >> >> OK for trunk? >> >> Author: Steve Kargl >> Date: Sun Nov 24 18:26:03 2024 -0800 >> >> Fortran: Check IMPURE in BLOCK inside DO CONCURRENT. >> >> PR fortran/117765 >> >> gcc/fortran/ChangeLog: >> >> * resolve.cc (check_pure_function): Check the stack too >> see if there in a nested BLOCK and, if that block is in >> a DO_CONCURRENT, issue an error. >> >> gcc/testsuite/ChangeLog: >> >> * gfortran.dg/impure_fcn_do_concurrent.f90: New test. >> >
Re: [PATCH] Fortran: fix two minor front-end GMP memleaks
Looks good, OK to push. On Sun, Dec 8, 2024, 1:39 PM Harald Anlauf wrote: > Dear all, > > while looking at testcases with inquiry refs, I encountered two minor > GMP memleaks due to double-initialization of GMP variables. Easily > plugged by the attached patch. > > Regtested on x86_64-pc-linux-gnu. > > I intend to commit as obvious within 24h unless there are objections. > > Thanks, > Harald > >
Re: [Patch, fortran] PR117897 - [13/14 Regression] Bug in gfortran compiled windows run time with the latest release (14.2.0)
Thanks Paul. Regards, Jerry On Tue, Dec 17, 2024, 12:34 AM Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > This bug was so obviously in defiance of the standard that I pushed it to > mainline as r15-6260. I meant to post this message immediately but was > distracted before I could press send. I will be backporting today. > > Paul > >
Re: [2nd PING, Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.
I got as far as applying and regression testing version 2. I have queried around for others to look over the patch. I will scan this one. Since you are the expert in this area, we may just have you push and let the pieces fall out. I will get back to you later today. Jerry On Fri, Dec 20, 2024, 4:37 AM Andre Vehreschild wrote: > Hi all, > > pinging again. > > Please note, that attached patch is a slightly updated version. > > Regtests ok on x86_64-pc-linux-gnu. Ok for mainline? > > Regards, > Andre > > On Mon, 16 Dec 2024 10:58:22 +0100 > Andre Vehreschild wrote: > > > PING! > > > > On Fri, 6 Dec 2024 19:10:08 +0100 > > Andre Vehreschild wrote: > > > > > Hi all, > > > > > > I had to dive deeply into the issue with handling allocatable > components in > > > derived types and to find a future proof solution. I hope do have > found a > > > universal and flexible one now: > > > > > > For each allocatable (or pointer) component in a derived type a coarray > > > token is required. While this is quite easy for the current compilation > > > unit, it is very difficult to do for arbitrary compilation units or > when > > > one gets libraries that are not aware of coarray's needs. The approach > this > > > patch now implements is to delegate the evaluation of a reference into > a > > > coarray into a separate access routine. This routine is present on > every > > > image, because it is generated by the compiler at the time it knows > that a > > > coarray access is done. With external compilation units or libraries > this > > > solves the access issue, because each image knows how to access its own > > > objects, but does not need a coarray token for allocatable (or pointer) > > > components anymore. The access on the remote image's object is done by > the > > > remote image itself (for the MPI implementation in a separate thread). > > > Therefore it knows about the bounds of arrays, allocation and > association > > > state of components and can handle those. > > > > > > Furthermore is this approach faster, because it has O(1) complexity > > > regarding the communication. The old approach was O(N) where N is the > > > number of allocatable/pointer components + array descriptors on the > path of > > > the access. The new approach sends a set of parameters to the remote > image > > > and gets the desired data in return. > > > > > > At the moment the patch handles only getting of data from a remote > image. It > > > is split into two patchsets. The first one does some preparatory clean > up, > > > like stopping to add caf_get calls into the expression tree and > removing > > > them afterwards again, where they are in the way. > > > > > > The second patch is then doing the access routine creation. > Unfortunately is > > > this the longer patch. I have also updated the documentation of the caf > > > API. I hope to not have overlooked something. > > > > > > This is the first part of a series to rework all coarray access > routines to > > > use the new approach and then remove the deprecated calls. This makes > things > > > clearer and easier to maintain, although the tree-dump now presents > some > > > more generated routines, which might look odd. > > > > > > Bootstrapped and regtested ok on x86_64-pc-linux-gnu / Fedora 39 and > 41. Ok > > > for mainline? > > > > > > I will continue working on the coarray stuff and fix upcoming bugs in > the > > > future. > > > > > > Regards, > > > Andre > > > -- > > > Andre Vehreschild * Email: vehre ad gmx dot de > > > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de >
Re: [PATCH] libfortran: G formatting for UNSIGNED [PR118536]
Looks Ok by me. Thanks, Jerry On Fri, Jan 17, 2025, 12:25 PM Harald Anlauf wrote: > Dear all, > > the attached obvious patch extends G formatting to UNSIGNED by reusing > the code for I formatting. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald > >
Re: Fortran documentation patches
I think the idea is OK. I am not so adept with editors so if you can make it doable, reordering information is fine with me On Tue, Dec 31, 2024, 5:12 PM Sandra Loosemore wrote: > Tobias pointed out that I forgot to CC the fortran mailing list about > these patches to the gfortran manual that I pushed just before the > holidays, while wearing my documentation maintainer hat: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672151.html > https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672152.html > https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672153.html > https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672155.html > https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672154.html > > I have a few more of these content-free cleanup patches pending that I > will remember to send here when I have a chance to push them. > > Also, I was wondering if I could get some more feedback on PR47928 > before I spend time doing anything about that. It's a proposal to > reorder the subheadings for each entry in the intrinsics chapter into > something that's easier to follow, like renaming "Syntax" to "Synopsis" > and moving it before the "Description", and pushing "Standard" down to > the end of the entry. > > -Sandra >
[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 = &gfc_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,
&gfc_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
Error on left hand function reference
Hi all, I spotted this today on the Fortran-Lang Discourse. It would not be setting precednce for us to allow an extension and turn this into a warning with -std=gnu and an error of strict compliance is wanted. https://fortran-lang.discourse.group/t/error-the-leftmost-part-ref-in-a-data-ref-cannot-be-a-function-reference/4990 I will create a PR and chase this one if concurrence here. Opinions? Jerry
[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] 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
[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.
Possible funding of gfortran work
Hi all, I found this message in my spam folder tonight. Please look. I also sent a note to Damian on this. Maybe we can get someone to push forward on te native coarrays work? Other thoughts? Jerry
GFortran MatterMost new Hosting
Hello all, As of today the free hosting of our MatterMost workspace is ended. The MatterMost cloud service organization decided to end free accounts. Fortunately, the platform is Open Source and we owe a tremendous gratitude to the Oregon State University Open Software Lab (OSUOSL)for providing a new host and for migrating our instance over to this new host. The new location is: https://gfortran-mm.osuosl.org/ If you have a previous account here, go to the website and use the password reset feature with your email to reconnect. At least one user had the reset email show up in a spam folder so check there if you do not see it in your inbox. You may notice a boatload of Unreads. Just click each folder and these will go away and we are back in business. I will be sending a separate email to each user individually with the above information to catch those who do not frequent the gfortran mailing list. A special thanks to Lance Albertson and his team at OSUOSL for their help in getting us a good home for our collaboration work space. Best regards to all, Jerry PS if you need to join this workspace, send me an email request and I can send you and invitation.
