Re: [PATCH] Fortran: improve attribute conflict checking [PR93635]
Le 09/05/2024 à 22:30, Harald Anlauf a écrit :
Hi Mikael,
Am 09.05.24 um 21:51 schrieb Mikael Morin:
Hello,
Le 06/05/2024 à 21:33, Harald Anlauf a écrit :
Dear all,
I've been contemplating whether to submit the attached patch.
It addresses an ICE-on-invalid as reported in the PR, and also
fixes an accepts-invalid (see testcase), plus maybe some more,
related due to incomplete checking of symbol attribute conflicts.
The fix does not fully address the general issue, which is
analyzed by Steve: some of the checks do depend on the selected
Fortran standard, and under circumstances such as in the testcase
the checking of other, standard-version-independent conflicts
simply does not occur.
Steve's solution would fix that, but unfortunately leads to issues
with error recovery in notoriously fragile parts of the FE: e.g.
testcase pr87907.f90 needs adjusting, and minor variations
of it will lead to various other horrendous ICEs that remind
of existing PRs where parsing or resolution goes sideways.
I therefore propose a much simpler approach: move - if possible -
selected of the standard-version-dependent checks after the
version-independent ones. I think this could help in getting more
consistent error reporting and recovery. However, I did *not*
move those checks that are critical when processing interfaces.
(-> pr87907.f90 / (sub)modules)
Your patch looks clean, but I'm concerned that the order of the checks
should be the important ones first, regardless of their standard
version. I'm trying to look at the ICE caused by your other tentative
patch at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635#c6 but I
can't reproduce the problem. Do you by any chance have around some of
the variations causing "horrendous" ICEs?
Oh, that's easy. Just move the block
conf_std (allocatable, dummy, GFC_STD_F2003);
conf_std (allocatable, function, GFC_STD_F2003);
conf_std (allocatable, result, GFC_STD_F2003);
towards the end of the gfc_check_conflict before the return true.
While the error messages for the original gfortran.dg/pr87907.f90
look harmless, commenting out the main program p I get:
pr87907.f90:15:18:
15 | subroutine g(x) ! { dg-error "mismatch in argument" }
| 1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1)
f951: internal compiler error: Segmentation fault
0x13b8ec2 crash_signal
../../gcc-trunk/gcc/toplev.cc:319
0xba530e free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4026
0xba5319 free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4026
0xba5319 free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4026
0xba5319 free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4026
0xba5609 gfc_free_namespace(gfc_namespace*&)
../../gcc-trunk/gcc/fortran/symbol.cc:4168
0xba39c1 gfc_free_symbol(gfc_symbol*&)
../../gcc-trunk/gcc/fortran/symbol.cc:3173
0xba3b89 gfc_release_symbol(gfc_symbol*&)
../../gcc-trunk/gcc/fortran/symbol.cc:3216
0xba5339 free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4029
0xba5609 gfc_free_namespace(gfc_namespace*&)
../../gcc-trunk/gcc/fortran/symbol.cc:4168
0xba58ef gfc_symbol_done_2()
../../gcc-trunk/gcc/fortran/symbol.cc:4236
0xb12ec8 gfc_done_2()
../../gcc-trunk/gcc/fortran/misc.cc:387
0xb4ac7f clean_up_modules
../../gcc-trunk/gcc/fortran/parse.cc:7057
0xb4af02 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.cc:7122
0xb4b735 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.cc:7413
0xbb626f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.cc:241
Restoring the main program but simply adding "end subroutine g"
where it is naively expected gives:
pr87907.f90:15:18:
15 | subroutine g(x) ! { dg-error "mismatch in argument" }
| 1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1)
pr87907.f90:16:9:
16 | end subroutine g
| 1
Error: Expecting END SUBMODULE statement at (1)
pr87907.f90:20:7:
20 | use m ! { dg-error "has a type" }
| 1
21 | integer :: x = 3
22 | call g(x) ! { dg-error "which is not consistent
with" }
|
2
Error: 'g' at (1) has a type, which is not consistent with the CALL at (2)
f951: internal compiler error: in gfc_free_namespace, at
fortran/symbol.cc:4164
0xba55e1 gfc_free_namespace(gfc_namespace*&)
../../gcc-trunk/gcc/fortran/symbol.cc:4164
0xba39c1 gfc_free_symbol(gfc_symbol*&)
../../gcc-trunk/gcc/fortran/symbol.cc:3173
0xba3b89 gfc_release_symbol(gfc_symbol*&)
../../gcc-trunk/gcc/fortran/symbol.cc:3216
0xba5339 free_sym_tree
../../gcc-trunk/gcc/fortran/symbol.cc:4029
0xba5609 gfc_free_namespace(gfc_namespace*&)
../../gcc-trunk/gcc/fortran/symbol.cc:4168
0xba58ef gfc_symbol_done_2()
../../gcc-trunk/gcc/fortran/symbol.c
[PATCH] Fortran: fix dependency checks for inquiry refs [PR115039]
Dear all,
the attached simple and obvious patch fixes a bogus recursion error
with inquiry refs used statement functions. The commit message
says all there is to say...
Regtested on x86_64-pc-linux-gnu.
I intend to commit to mainline within the next 24 hours unless someone
screams... Will also backport to 14-branch after a decent delay.
Thanks,
Harald
From 8bb31eb3d7f8ea6d21066380c36abf53f7b64156 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 10 May 2024 21:18:03 +0200
Subject: [PATCH] Fortran: fix dependency checks for inquiry refs [PR115039]
gcc/fortran/ChangeLog:
PR fortran/115039
* expr.cc (gfc_traverse_expr): An inquiry ref does not constitute
a dependency and cannot collide with a symbol.
gcc/testsuite/ChangeLog:
PR fortran/115039
* gfortran.dg/statement_function_5.f90: New test.
---
gcc/fortran/expr.cc | 3 ++-
.../gfortran.dg/statement_function_5.f90 | 20 +++
2 files changed, 22 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/statement_function_5.f90
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 66edad58278..8e29535b0f7 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -5500,7 +5500,8 @@ gfc_traverse_expr (gfc_expr *expr, gfc_symbol *sym,
break;
case REF_INQUIRY:
- return true;
+ /* An inquiry_ref does not collide with a symbol. */
+ return false;
default:
gcc_unreachable ();
diff --git a/gcc/testsuite/gfortran.dg/statement_function_5.f90 b/gcc/testsuite/gfortran.dg/statement_function_5.f90
new file mode 100644
index 000..bc5a5dba7a0
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/statement_function_5.f90
@@ -0,0 +1,20 @@
+! { dg-do compile }
+! PR fortran/115039
+!
+! Check that inquiry refs work with statement functions
+!
+! { dg-additional-options "-std=legacy -fdump-tree-optimized" }
+! { dg-prune-output " Obsolescent feature" }
+! { dg-final { scan-tree-dump-not "_gfortran_stop_numeric" "optimized" } }
+
+program testit
+ implicit none
+ complex :: x
+ real:: im
+ integer :: slen
+ character(5) :: s
+ im(x) = x%im + x%re + x%kind
+ slen(s) = s%len
+ if (im((1.0,3.0) + (2.0,4.0)) /= 14.) stop 1
+ if (slen('abcdef') /= 5) stop 2
+end program testit
--
2.35.3
Re: [PATCH] Fortran: improve attribute conflict checking [PR93635]
Hi Mikael, Am 10.05.24 um 11:45 schrieb Mikael Morin: Le 09/05/2024 à 22:30, Harald Anlauf a écrit : I'll stop here... Thanks. Go figure, I have no problem reproducing today. It's PR99798 (and there is even a patch for it). this patch has rotten a bit: the type of gfc_reluease_symbol has changed to bool, this can be fixed. Unfortunately, applying the patch does not remove the ICEs here... We currently do not recover well from errors, and the prevention of corrupted namespaces is apparently a goal we aim at. Yes, and we are not there yet. But at least there is a sensible error message before the crash. True. But having a sensible error before ICEing does not improve user experience either. Are you planning to work again on PR99798? Cheers, Harald Cheers, Harald The patch therefore does not require any testsuite update and should not give any other surprises, so it should be very safe. The plan is also to leave the PR open for the time being. Regtesting on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald
Re: [PATCH] Fortran: improve attribute conflict checking [PR93635]
Am 10.05.24 um 21:48 schrieb Harald Anlauf: Hi Mikael, Am 10.05.24 um 11:45 schrieb Mikael Morin: Le 09/05/2024 à 22:30, Harald Anlauf a écrit : I'll stop here... Thanks. Go figure, I have no problem reproducing today. It's PR99798 (and there is even a patch for it). this patch has rotten a bit: the type of gfc_reluease_symbol has changed to bool, this can be fixed. Unfortunately, applying the patch does not remove the ICEs here... Oops, I take that back! There was an error on my side applying the patch; and now it does fix the ICEs after correcting that hickup We currently do not recover well from errors, and the prevention of corrupted namespaces is apparently a goal we aim at. Yes, and we are not there yet. But at least there is a sensible error message before the crash. True. But having a sensible error before ICEing does not improve user experience either. Are you planning to work again on PR99798? Cheers, Harald Cheers, Harald The patch therefore does not require any testsuite update and should not give any other surprises, so it should be very safe. The plan is also to leave the PR open for the time being. Regtesting on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald
Re: [PATCH] Fortran: fix dependency checks for inquiry refs [PR115039]
Le 10/05/2024 à 21:24, Harald Anlauf a écrit : Dear all, the attached simple and obvious patch fixes a bogus recursion error with inquiry refs used statement functions. The commit message says all there is to say... Regtested on x86_64-pc-linux-gnu. I intend to commit to mainline within the next 24 hours unless someone screams... Will also backport to 14-branch after a decent delay. Thanks, Harald I agree that the return value change makes sense, but the function is generic, broader than just dependency checking, so the comment feels a bit out of place.
Re: [Patch, fortran] PR84006 [11/12/13/14/15 Regression] ICE in storage_size() with CLASS entity
Hi Harald,
Thanks for the review. The attached resubmission fixes all the invalid
accesses, memory leaks and puts right the incorrect result.
In the course of fixing the fix, I found that deferred character length
MOLDs gave an ICE because reallocation on assign was using 'dest_word_len'
before it was defined. This is fixed by not fixing 'dest_word_len' for
these MOLDs. Unfortunately, the same did not work for unlimited polymorphic
MOLD expressions and so I added a TODO error in iresolve.cc since it
results in all manner of memory errors in runtime. I will return to this
another day.
A resubmission of the patch for PR113363 will follow since it depends on
this one to fix all the memory problems.
OK for mainline?
Regards
Paul
On Thu, 9 May 2024 at 08:52, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Harald,
>
> The Linaro people caught that as well. Thanks.
>
> Interestingly, I was about to re-submit the patch for PR113363, in which
> all the invalid accesses and memory leaks are fixed but requires this patch
> to do so. The final transfer was thrown in because it seemed to be working
> out of the box but should be checked anyway.
>
> Inserting your print statements, my test shows the difference in
> size(chr_a) but prints chr_a as "abcdefgjj" no matter what I do. Needless
> to say, the latter was the only check that I did. The problem, I suspect,
> lies somewhere in the murky depths of
> trans-array.cc(gfc_alloc_allocatable_for_assignment) or in the array part
> of intrinsic_transfer, untouched by either patch, and is present in 13- and
> 14-branches.
>
> I am onto it.
>
> Cheers
>
> Paul
>
>
> On Wed, 8 May 2024 at 22:06, Harald Anlauf wrote:
>
>> Hi Paul,
>>
>> this looks mostly good, but the new testcase transfer_class_4.f90
>> does exhibit a problem with your patch. Run it with valgrind,
>> or with -fcheck=bounds, or with -fsanitize=address, or add the
>> following around the final transfer:
>>
>> print *, storage_size (star_a), storage_size (chr_a), size (chr_a), len
>> (chr_a)
>>chr_a = transfer (star_a, chr_a)
>> print *, storage_size (star_a), storage_size (chr_a), size (chr_a), len
>> (chr_a)
>> print *, ">", chr_a, "<"
>>
>> This prints for me:
>>
>>40 40 2 5$
>>40 40 4 5$
>> >abcdefghij^@^@^@^@^@^@^@^@^@^@<$
>>
>> So since the physical representation of chr_a is sufficient
>> to hold star_a (F2023:16.9.212), no reallocation with a wrong
>> calculated size should happen. (Intel and NAG get this right.)
>>
>> Can you check again?
>>
>> Thanks,
>> Harald
>>
>>
>>
diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc
index c961cdbc2df..c63a4a8d38c 100644
--- a/gcc/fortran/iresolve.cc
+++ b/gcc/fortran/iresolve.cc
@@ -3025,6 +3025,10 @@ gfc_resolve_transfer (gfc_expr *f, gfc_expr *source ATTRIBUTE_UNUSED,
}
}
+ if (UNLIMITED_POLY (mold))
+gfc_error ("TODO: unlimited polymorphic MOLD in TRANSFER intrinsic at %L",
+ &mold->where);
+
f->ts = mold->ts;
if (size == NULL && mold->rank == 0)
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index bc8eb419cff..4590aa6edb4 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -317,6 +317,8 @@ gfc_resize_class_size_with_len (stmtblock_t * block, tree class_expr, tree size)
size = gfc_evaluate_now (size, block);
tmp = gfc_evaluate_now (fold_convert (type , tmp), block);
}
+ else
+ tmp = fold_convert (type , tmp);
tmp2 = fold_build2_loc (input_location, MULT_EXPR,
type, size, tmp);
tmp = fold_build2_loc (input_location, GT_EXPR,
@@ -11994,15 +11996,24 @@ trans_class_assignment (stmtblock_t *block, gfc_expr *lhs, gfc_expr *rhs,
/* Take into account _len of unlimited polymorphic entities.
TODO: handle class(*) allocatable function results on rhs. */
- if (UNLIMITED_POLY (rhs) && rhs->expr_type == EXPR_VARIABLE)
+ if (UNLIMITED_POLY (rhs))
{
- tree len = trans_get_upoly_len (block, rhs);
+ tree len;
+ if (rhs->expr_type == EXPR_VARIABLE)
+ len = trans_get_upoly_len (block, rhs);
+ else
+ len = gfc_class_len_get (tmp);
len = fold_build2_loc (input_location, MAX_EXPR, size_type_node,
fold_convert (size_type_node, len),
size_one_node);
size = fold_build2_loc (input_location, MULT_EXPR, TREE_TYPE (size),
size, fold_convert (TREE_TYPE (size), len));
}
+ else if (rhs->ts.type == BT_CHARACTER && rse->string_length)
+ size = fold_build2_loc (input_location, MULT_EXPR,
+gfc_charlen_type_node, size,
+rse->string_length);
+
tmp = lse->expr;
class_han = GFC_CLASS_TYPE_P (TREE_TYPE (tmp))
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index 83041183fcb..80dc3426ab0 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -8250,7 +8250,9 @@ gfc_conv_intrinsic_storage_size (gfc_se *se, gfc_expr *exp
