[Bug fortran/99798] ICE when compiling a variant of pr87907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- I'm working on it.
[Bug fortran/114922] fsyntax-only need the modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin --- (In reply to Axel Ehrich from comment #3) > In my understanding, the intention of the option -fsyntax-only is to > construct the module files needed to compile the code. A build process > would involve two steps: Step 1: construct all module files with gfortran > -fsyntax only. Step 2: construct the object files without this option, while > relying on the presence of all module files. (I have found this recipe on > the internet and consider it valuable.) > The normal process is to compile directly the files (without -fsyntax-only) in the right order, in a single step. Some people prefer to do it in two steps, depending on their needs. > Alternatively, the purpose of -fsyntax-only could be to save compile time by > a doing quick first check before entering the time consuming parts of the > compilation. Yes, that's the main purpose. > If this syntax check goes so far that it requires the module > files already, the goal mentioned above cannot be reached. Yes, it can. The files have to be compiled in the right order. Keep in mind that the compiler processes one file at a time and doesn't have a global knowledge of all the files together. Consider this example: module m2 use m1 end module m2 What symbols should be made available in the module file for m2? Don't you think that the knowledge of the content of m1 is needed?
[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #4 from Mikael Morin ---
For what's worth adding -fno-tree-vrp "fixes" this and enables removal of the
call to 'foo' with trunk.
Here is a minimal revert of the regressing revision, but it may just make the
problem latent.
diff --git a/gcc/gimple-range-phi.cc b/gcc/gimple-range-phi.cc
index 01900a35b32..9fa9fe83ce0 100644
--- a/gcc/gimple-range-phi.cc
+++ b/gcc/gimple-range-phi.cc
@@ -386,14 +386,6 @@ phi_analyzer::process_phi (gphi *phi)
m_work.safe_push (arg);
continue;
}
- // More than 2 outside names is too complicated.
- if (m_num_extern >= 2)
- {
- cycle_p = false;
- break;
- }
- m_external[m_num_extern] = arg;
- m_ext_edge[m_num_extern++] = gimple_phi_arg_edge (phi_stmt, x);
}
else if (code == INTEGER_CST)
{
@@ -402,12 +394,15 @@ phi_analyzer::process_phi (gphi *phi)
wi::to_wide (arg));
init_range.union_ (val);
}
- else
+ // More than 2 outside names/CONST is too complicated.
+ if (m_num_extern >= 2)
{
- // Everything else terminates the cycle.
cycle_p = false;
break;
}
+
+ m_external[m_num_extern] = arg;
+ m_ext_edge[m_num_extern++] = gimple_phi_arg_edge (phi_stmt, x);
}
}
[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- pre replaces usages of the 'e' global with a set of 'pretmp' and 'prephitmp' ssa registers. With gcc-13, the value of 'e' is reloaded directly after the call to 'foo', and that value is joined with a phi in the next bb: [local count: 7761689018]: foo (); pretmp_25 = e; goto ; [100.00%] ... [local count: 8963573811]: # j_28 = PHI <1(10), j_30(24), 1(22), j_30(25), 1(26), j_30(20)> # i_29 = PHI # prephitmp_38 = PHI d.7_22 = d; _23 = d.7_22 + 1; d = _23; if (_23 != 0) goto ; [94.50%] else goto ; [5.50%] With gcc-14, the value of 'e' is reloaded later in the next bb, causing a dependency on 'e', even on paths not calling 'foo': [local count: 7761689018]: foo (); goto ; [100.00%] ... [local count: 8963573796]: # i_28 = PHI d.7_22 = d; _23 = d.7_22 + 1; d = _23; pretmp_10 = e; if (_23 != 0) goto ; [94.50%] else goto ; [5.50%] Later on this prevents copyprop from simplifying the 'pretmp' and 'prephitmp' values to 3 and remove the branch calling 'foo'.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 Mikael Morin changed: What|Removed |Added Assignee|mikael at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #23 from Mikael Morin --- (In reply to anlauf from comment #22) > Mikael, > > since you did the essential work and commit, I am reassigning to you. Well, I'm not working on this any more. As far as I know, comment #0 is fixed, but comment #14 remains unfixed.
[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Mikael Morin --- Fixed for gfortran 14.1. Closing.
[Bug fortran/114475] [14 Regression] Regression with iso_c_binding and submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Mikael Morin --- Fixed.
[Bug fortran/107426] [12/13/14 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Mikael Morin --- Fixed for gfortran versions 14.1, 13.3, 12.4 and 11.5. Closing.
[Bug fortran/107426] [12/13/14 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #10 from Mikael Morin --- (In reply to Paul Thomas from comment #9) > Hi Mikael, > > I have assigned the PR to you since you have fixed it on mainline. I presume > that you will backport? > Yes. I was initially targetting master only, but then I figured this was a regression, so backporting was in order.
[Bug fortran/114475] [14 Regression] Regression with iso_c_binding and submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- (In reply to anlauf from comment #2) > (In reply to Jürgen Reuter from comment #1) > > I suspect this commit here, > > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > > h=44c0398e65347def316700911a51ca8b4ec0a411 > > but not totally certain. > > The following patch fixes the apparent regression: > > diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc > index 9a042cd7040..68d16a9a378 100644 > --- a/gcc/fortran/expr.cc > +++ b/gcc/fortran/expr.cc > @@ -3517,6 +3563,7 @@ check_restricted (gfc_expr *e) >if (e->error > || sym->attr.in_common > || sym->attr.use_assoc > + || sym->attr.used_in_submodule > || sym->attr.dummy > || sym->attr.implied_index > || sym->attr.flavor == FL_PARAMETER > Yes, I was coming to the same fix. I'm not too sure about it though. > > Looks like the commit actually uncovered a latent issue. > > Mikael, do you want to follow up? Yes, this is mine in any case.
[Bug fortran/103472] ICE in gfc_conv_ss_startstride, at fortran/trans-array.c:4527
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103472 Mikael Morin changed: What|Removed |Added Known to work||14.0 Known to fail||13.2.0 --- Comment #3 from Mikael Morin --- The example from comment #0 is now rejected, which avoids the problem: comment_0.f90:3:15: 3 |print *, (a(1:1)) | 1 Warning: Lower array reference at (1) is out of bounds (1 > 0) in dimension 1 comment_0.f90:3:15: 3 |print *, (a(1:1)) | 1 Warning: Lower array reference at (1) is out of bounds (1 > 0) in dimension 1 comment_0.f90:3:15: 3 |print *, (a(1:1)) | 1 Error: index in dimension 1 is out of bounds at (1)
[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 Mikael Morin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Mikael Morin --- (In reply to kargl from comment #3) > (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. > Well, the intent of this PR was on the contrary to avoid silent errors. > I am, however, of the mind that if gfortran gets to the > "Unclassifiable error" message, that perhaps, this should be > a fatal error. I guess one can find cases where later errors are useless noise, and cases where they remain useful and are not caused by bad error recovery. Anyway, I'm closing this.
[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 --- Comment #2 from Mikael Morin --- Created attachment 57739 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57739=edit 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.
[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781 --- Comment #9 from Mikael Morin --- (In reply to anlauf from comment #8) > (In reply to Mikael Morin from comment #7) > > FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors) > > Excess errors: > > /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr98016.f90:16:16: Error: > > Variable 'n' cannot appear in the expression at (1) > > This is wrong: the testcase looks valid to me. > Yes, to me as well. So the patch needs more work. :-( > > FAIL: gfortran.dg/graphite/pr107865.f90 -O (test for excess errors) > > Excess errors: > > /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/graphite/pr107865.f90:7:18: > > Error: Variable 'n' cannot appear in the expression at (1) > > Hmmm, not diagnosed by Intel. > Strange that it is able to diagnose the other, but not this one. > > We obviously have several invalid testcases in the testsuite... > Probably just bad reductions. Yes, variables named inout especially look like dubious (but valid) reductions.
[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781 --- Comment #7 from Mikael Morin --- (In reply to Mikael Morin from comment #6) > I need to reevaluate it; there were other regressions if I remember > correctly. The changes are these: PASS->FAIL: gfortran.dg/graphite/pr107865.f90 -O (test for excess errors) PASS->FAIL: gfortran.dg/pr101267.f90 -O (test for excess errors) PASS->FAIL: gfortran.dg/pr112404.f90 -O (test for excess errors) PASS->FAIL: gfortran.dg/pr78061.f -O (test for excess errors) PASS->FAIL: gfortran.dg/pr79315.f90 -O (test for excess errors) PASS->FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors) PASS->FAIL: gfortran.dg/vect/pr90681.f -O (test for excess errors) PASS->FAIL: gfortran.dg/vect/pr97761.f90 -O (test for excess errors) PASS->FAIL: gfortran.dg/vect/pr99746.f90 -O (test for excess errors) FAIL: gfortran.dg/pr79315.f90 -O (test for excess errors) Excess errors: /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr79315.f90:18:18: Error: Variable 'ims' cannot appear in the expression at (1) FAIL: gfortran.dg/pr101267.f90 -O (test for excess errors) Excess errors: /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr101267.f90:5:19: Error: Variable 'ime' cannot appear in the expression at (1) /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr101267.f90:5:24: Error: Variable 'in' cannot appear in the expression at (1) FAIL: gfortran.dg/pr112404.f90 -O (test for excess errors) Excess errors: /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr112404.f90:5:19: Error: Variable 'ime' cannot appear in the expression at (1) /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr112404.f90:5:24: Error: Variable 'in' cannot appear in the expression at (1) FAIL: gfortran.dg/pr78061.f -O (test for excess errors) Excess errors: /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr78061.f:4:13: Error: Variable 'ldc' cannot appear in the expression at (1) FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors) Excess errors: /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr98016.f90:16:16: Error: Variable 'n' cannot appear in the expression at (1) FAIL: gfortran.dg/graphite/pr107865.f90 -O (test for excess errors) Excess errors: /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/graphite/pr107865.f90:7:18: Error: Variable 'n' cannot appear in the expression at (1) FAIL: gfortran.dg/vect/pr90681.f -O (test for excess errors) Excess errors: /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/vect/pr90681.f:5:19: Error: Variable 'norbs' cannot appear in the expression at (1) FAIL: gfortran.dg/vect/pr97761.f90 -O (test for excess errors) Excess errors: /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/vect/pr97761.f90:11:36: Error: Variable 'inout' cannot appear in the expression at (1) FAIL: gfortran.dg/vect/pr99746.f90 -O (test for excess errors) Excess errors: /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/vect/pr99746.f90:6:21: Error: Variable 'lda' cannot appear in the expression at (1)
[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781 --- Comment #6 from Mikael Morin --- Created attachment 57571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57571=edit Tentative patch (In reply to anlauf from comment #5) > (In reply to anlauf from comment #4) > > Thus I suggest to fix the testcase by one of the options suggested above. > > Testcase gfortran.dg/pr101026.f is corrected at r14-9220. Ah, yes, thanks. I attach above the tentative patch that I tried before. I need to reevaluate it; there were other regressions if I remember correctly.
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 --- Comment #6 from Mikael Morin --- (In reply to kargl from comment #5) > (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. Agreed. > 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.). > This is about x%im, which is a different expression from log(cmplx(-1, 0)). x is an associate-name, and thus (I think) an object-name, and a valid designator, even if it's associated selector isn't.
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin --- (In reply to Jerry DeLisle from comment #2) > It looks like the 'selector' in this case is an expr. > Agreed. > The expr must be a pointer object or a 'designator' > Really? Can't find the constraint saying that. The only associate constraint mentioning 'designator' I can see is this: C1105 (R1105) expr shall not be a designator of a procedure pointer or a function reference that returns a procedure pointer. ... but it relates more to procedure pointers (and it is a 'shall NOT be' constraint). (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. ;-)
[Bug fortran/113799] gfc_replace_expr: double free detected ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799 Mikael Morin changed: What|Removed |Added Known to fail||10.5.0, 11.4.0, 12.3.0, ||13.2.0, 14.0 --- Comment #2 from Mikael Morin --- Reproduced with all versions I have here (14.0, 13.2, 12.3, 11.4 and 10.5).
[Bug fortran/113799] gfc_replace_expr: double free detected ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799 Mikael Morin changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-07 Status|UNCONFIRMED |NEW CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- Reduced: module m implicit none real, parameter :: inf = real(z'7F80') real, parameter :: someInf(*) = [inf, 0.] logical, parameter :: test_rminval_someInf = minval(-someInf) == -inf end
[Bug other/86656] [meta-bug] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 111291, which changed state. Bug 111291 Summary: ASAN error: heap-use-after-free gcc/fortran/parse.cc:359 in decode_statement https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/111291] ASAN error: heap-use-after-free gcc/fortran/parse.cc:359 in decode_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Mikael Morin --- Fixed for gfortran 14. Closing.
[Bug fortran/113377] Wrong code passing optional dummy argument to elemental procedure with optional dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377 --- Comment #6 from Mikael Morin --- (In reply to anlauf from comment #4) > > Note that the following scalar example also fails: > "Fortunately", it is invalid. :-) >From 15.5.2.12 (Argument presence and restrictions on arguments not present): An optional dummy argument that is not present is subject to the following restrictions. (...) (8) If it is allocatable, it shall not be allocated, deallocated, or supplied as an actual argument corresponding to an optional nonallocatable dummy argument. In comment #4, j from one is non-present, allocatable, optional and passed to j from two which is optional nonallocatable.
[Bug fortran/113377] Wrong code passing optional dummy argument to elemental procedure with optional dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377 --- Comment #5 from Mikael Morin --- (In reply to anlauf from comment #2) > Note that adding a scalar call in function one: > > r(1) = two (i(1), j) > > generates sane code: > > *((integer(kind=4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE_EXPR > ) * 4)) = two (&(*i)[0], j != 0B ? *j : 0, j != 0B); > > (...) > > There is another observation: using the value attribute for j also in one, > the scalar call from above becomes a straight > > *((integer(kind=4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE_EXPR > ) * 4)) = two (&(*i)[0], j, .j); > > while the scalarizer produces: > > integer(kind=4) * D.4340; > ... > D.4340 = > ... > *((integer(kind=4) *) __result.0 + (sizetype) ((S.3 * D.4342 + > D.4339) * 4)) = two (&(*i)[S.3 + -1], *D.4340); > > which looks more complicated (besides being wrong...) Wrong I agree, but is it really more complicated? (In reply to anlauf from comment #3) > Created attachment 57108 [details] > Patch to play with > > This is a first attempt to outline code for handling scalar dummies with the > VALUE attribute. > > This fixes the following variants of the declaration of dummy argument j > in function one: > > integer, value, optional :: j > integer, intent(in), optional :: j > integer, intent(in), optional :: j(4) > integer, intent(in), optional :: j(:) > Looks promising, maybe push a fix for just these cases as a first step? > However, > > integer, allocatable,optional :: j > Allocatable AND optional? The standard seems to accept those, but do we support them? ... (searches) ... Alright, we have some in the testsuite. ... (searches) ... The argument passing convention is a double pointer in this case. > still does not work: the code *in* the generated loop looks fine to me, but > the scalarizer dereferences j before the loop. > > I think that this is correct F2018+, as ifx handles it fine. > Not sure how to proceed here. > > > Furthermore, the patch tries to cope (= prevent an ICE) with > > integer, allocatable,optional :: j(:) > > which I think might be invalid. At least it also crashed with ifx... > There is an error to report if it's invalid, but I doubt it is.
[Bug fortran/46244] gfc_compare_derived_types is buggy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|mikael at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #21 from Mikael Morin --- (In reply to Thomas Koenig from comment #20) > Mikael, are you still planning to work on this? No, I'm not working on this any more.
[Bug fortran/113377] Wrong code passing optional dummy argument to elemental procedure with optional dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- (In reply to anlauf from comment #0) > The dump-tree suggests that the scalarizer sees the loop invariant j, > unconditionally dereferences it outside the loop, Note that the copy to the variable before the loop does NOT dereference the pointer. This case is explicitly supported by the scalarizer, see gfc_scalar_elemental_arg_saved_as_reference (and gfc_walk_elemental_function_args for the initialization of the can_be_null_ref field). Normally this is sufficient to support optional dummies (there is also additional support for class wrappers in gfc_conv_procedure_call), except if value comes into play. > generates code that > unconditionally dereferences j in the invocation of two, and uses a > wrong interface: These are the topics to investigate. I suppose we need to duplicate (or factor) the code for optional, value dummies that was added for non-elemental procedures in gfc_conv_procedure_call.
[Bug fortran/111291] ASAN error: heap-use-after-free gcc/fortran/parse.cc:359 in decode_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin --- Mine, I guess.
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin --- (In reply to kargl from comment #0) > > 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. With git you need to add all the files, not only the new ones (you can use git add --update to add the existing files). Then the patch can be generated (if you don't commit) with git diff --staged If you commit, you need to add an argument to git diff to tell him a reference to compare against, namely origin/master (remote master), master (local master), HEAD^ (last commit before the tip of the branch), etc. The default reference if omitted is the tip of the branch, what you have just committed, so the diff is empty.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #16 from Mikael Morin --- This missed the gcc stage 1 deadline, but I'm still working on it.
[Bug libfortran/112412] Masked reduction functions return an unallocated array when the result is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Mikael Morin --- Fixed for gfortran 14.1, closing.
[Bug libfortran/112371] Wrong upper bound for the result of reduction intrinsics if the array is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Mikael Morin --- Fixed for gfortran 14.1, closing.
[Bug libfortran/112412] Masked reduction functions return an unallocated array when the result is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412 Mikael Morin changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-11-08 Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- Patches submitted (and accepted): https://gcc.gnu.org/pipermail/fortran/2023-November/059904.html https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635518.html
[Bug libfortran/112371] Wrong upper bound for the result of reduction intrinsics if the array is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371 Mikael Morin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-11-08 Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Component|fortran |libfortran --- Comment #4 from Mikael Morin --- Patches submitted (and accepted): https://gcc.gnu.org/pipermail/fortran/2023-November/059904.html https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635518.html
[Bug libfortran/112412] New: Masked reduction functions return an unallocated array when the result is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412 Bug ID: 112412 Summary: Masked reduction functions return an unallocated array when the result is empty Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Target Milestone: --- Non-masked reduction functions work, but their masked variant don't allocate if the result is empty, so the result is seen as non-allocated. See: https://gcc.gnu.org/pipermail/fortran/2023-November/059902.html
[Bug fortran/112371] Wrong upper bound for the result of reduction intrinsics if the array is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #3 from Mikael Morin ---
Possible culprit:
ifunction.m4 has this code:
retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
if (alloc_size == 0)
{
/* Make sure we have a zero-sized array. */
GFC_DIMENSION_SET(retarray->dim[0], 0, -1, 1);
return;
}
[Bug fortran/112371] Wrong upper bound for the result of reduction intrinsics if the array is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371 --- Comment #2 from Mikael Morin --- If dim == 3, the ubound and shape are (/ 9, 3, 7 /) as expected. That is, the problem only arises if the resulting array is empty.
[Bug fortran/112371] Wrong upper bound for the result of reduction intrinsics if the array is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371 --- Comment #1 from Mikael Morin --- (In reply to Mikael Morin from comment #0) > i = 1 > (...) > r = sum(a, dim=i) If i is inlined, that is r = sum(a, dim=1) the shape and ubound are (/ 3, 0, 7 /) as expected. The difference is probably caused by inline vs library implementation.
[Bug fortran/112371] New: Wrong upper bound for the result of reduction intrinsics if the array is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371 Bug ID: 112371 Summary: Wrong upper bound for the result of reduction intrinsics if the array is empty Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Target Milestone: --- In the following example, I expect the ubound to be (/ 3, 0, 7 /), but the printed values are (/ 0, 0, 7 /). program p implicit none call check_iparity call check_sum call check_minloc contains subroutine check_iparity integer :: a(9,3,0,7) integer :: i integer, allocatable :: r(:,:,:) i = 1 a = reshape((/ integer:: /), shape(a)) r = iparity(a, dim=i) print *, shape(r) print *, ubound(r) !if (any(shape(r) /= (/ 3, 0, 7 /))) stop 11 !if (any(ubound(r) /= (/ 3, 0, 7 /))) stop 13 end subroutine subroutine check_sum integer :: a(9,3,0,7) integer :: i integer, allocatable :: r(:,:,:) i = 1 a = reshape((/ integer:: /), shape(a)) r = sum(a, dim=i) print *, shape(r) print *, ubound(r) !if (any(shape(r) /= (/ 3, 0, 7 /))) stop 21 !if (any(ubound(r) /= (/ 3, 0, 7 /))) stop 23 end subroutine subroutine check_minloc integer :: a(9,3,0,7) integer :: i integer, allocatable :: r(:,:,:) i = 1 a = reshape((/ integer:: /), shape(a)) r = minloc(a, dim=i) print *, shape(r) print *, ubound(r) !if (any(shape(r) /= (/ 3, 0, 7 /))) stop 31 !if (any(ubound(r) /= (/ 3, 0, 7 /))) stop 33 end subroutine end program
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Mikael Morin changed:
What|Removed |Added
Attachment #56094|0 |1
is obsolete||
--- Comment #14 from Mikael Morin ---
Created attachment 56313
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56313=edit
inline minloc with mask
This patch adds support for {min,max}loc with mask.
It is not 100% testsuite clean as there are (runtime) error messages that
regress slightly for maxloc_bounds_{4,5,6,7}.f90
(In reply to Mikael Morin from comment #11)
>
> > The problem could be with the initialization of loop iteration variables.
> > (...)
> > Unfortunately, this conditional initialization seems to
> > confuse the optimizers a lot.
> >
> On closer look, the conditional initialization doesn't seem to be that
> confusing (at least in the problematic case), as it's removed early (ccp1)
> in the pipeline. The loop iteration variables remain initialized with phis,
> but that's because of the loops.
Unfortunately, this is true for rank 1 arrays, but not for higher ranks.
Constant values are slowly propagated to the phi arguments as optimization
passes are run, but no simplification of the control flow happens as soon as
multiple loop levels are involved.
Need to look into the dim argument next.
[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781 --- Comment #3 from Mikael Morin --- I'm trying to remove the formal_arg_flag global variables, which seem to just disable all the checks on dummy arguments. Unfortunately, it regresses a bit, say pr101026.f for example can be simplified to this: SUBROUTINE PASSB4 (CC,CH) DIMENSION CC(IDO,4,L1), CH(IDO,L1,*) END which gives: pr101026.f:4:19: 4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*) | 1 Error: Variable ‘ido’ cannot appear in the expression at (1) pr101026.f:4:33: 4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*) | 1 Error: Variable ‘ido’ cannot appear in the expression at (1) pr101026.f:4:25: 4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*) | 1 Error: Variable ‘l1’ cannot appear in the expression at (1) pr101026.f:4:37: 4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*) | 1 Error: Variable ‘l1’ cannot appear in the expression at (1) What I don't see is what makes the IDO and L1 variables acceptable in a specification expression. It seems to me the errors above are valid.
[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin --- I'm on it.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #13 from Mikael Morin ---
(In reply to Tamar Christina from comment #12)
> (In reply to Mikael Morin from comment #11)
> > Created attachment 56094 [details]
> > Improved patch
> >
> > This improved patch (still single argument only) passes the fortran
> > regression testsuite.
> >
>
> Awesome! Thanks! it looks like the benchmark always uses dim=1 or the mask
> argument.
>
> Can you give a hint into what I'd need to do to add the additional params?
For the mask argument, I hope it would just need
gfc_inline_intrinsic_function_p to return true to work.
For the dim argument, it's a bit more complicated. You can have a look at how
the dim argument support for sum and product was introduced here:
https://gcc.gnu.org/pipermail/fortran/2011-October/037574.html
To describe in a few words the needed bits:
- gfc_walk_inline_intrinsic_function needs to collect the arrays involved in
scalarization. In the case where dim is absent, there is just the result of
minloc and it can't be decomposed further. If dim is present on the other
hand, the arrays are the non-dim arguments, and there is one nested loop
reducing those arrays' dimension by one. One important thing to pay attention
for, the arrays must be present in the same order they will be consumed by the
gfc_conv_intrinsic_minmaxloc later.
- All the calls to gfc_walk_expr in gfc_conv_intrinsic_minmaxloc should be
disabled in favor enter_nested_loop.
- Setting of gfc_se::ss pointers should be disabled, as they should come
correct from initialization.
- The call to gfc_cleanup_loop should be disabled
These 4 points are very similar to the sum/product patch mentioned above.
Additionally, one has to disable the changes to support the other cases of
{min,max}loc. Possibly it's easier to start with an unpatched master and merge
the patches afterwards.
Anyway, I should be able to help, maybe by the end of this week, or next week.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 Mikael Morin changed: What|Removed |Added Attachment #56091|0 |1 is obsolete|| --- Comment #11 from Mikael Morin --- Created attachment 56094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56094=edit Improved patch This improved patch (still single argument only) passes the fortran regression testsuite. (In reply to Mikael Morin from comment #8) > It regresses on minloc_1.f90 at least, but I haven't be able to pinpoint the > problem in the original tree dump so far. > The problem was an initialization of the result to the first element of the array that the patch removed, which seemed useless to me but made a difference in the questionable case where the array argument is filled with nans. > The problem could be with the initialization of loop iteration variables. > (...) > Unfortunately, this conditional initialization seems to > confuse the optimizers a lot. > On closer look, the conditional initialization doesn't seem to be that confusing (at least in the problematic case), as it's removed early (ccp1) in the pipeline. The loop iteration variables remain initialized with phis, but that's because of the loops.
[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781 Mikael Morin changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||patch CC||mikael at gcc dot gnu.org Last reconfirmed||2023-10-12 --- Comment #1 from Mikael Morin --- Confirmed. This should fix it: diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index 1042b8c18e8..e2e0fc8eba3 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -285,6 +285,7 @@ gfc_resolve_formal_arglist (gfc_symbol *proc) sym->attr.always_explicit = 1; } + bool saved_formal_arg_flag = formal_arg_flag; formal_arg_flag = true; for (f = proc->formal; f; f = f->next) @@ -533,7 +534,7 @@ gfc_resolve_formal_arglist (gfc_symbol *proc) } } } - formal_arg_flag = false; + formal_arg_flag = saved_formal_arg_flag; }
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #10 from Mikael Morin --- (In reply to Mikael Morin from comment #8) > (...) that is it was using too loops in a row in some cases. > ... *two* loops in a row ... (In reply to Tamar Christina from comment #9) > > Thanks Mikael! > > That's already plenty of help! I can try to debug further after I finish my > current patches. Would it be ok if I ask questions when I do? Yes, of course. I forgot to precise that the patch above supports only calls without any optional args. Allowing non-DIM arguments should work, as the code supporting them is already there for the scalar case. For the DIM argument, it's a bit more work. I'm not sure, but maybe the scalarizer support for reductions (SUM or PRODUCT with DIM arg) can be used to support it.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #8 from Mikael Morin --- Created attachment 56091 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56091=edit Rough patch Here is a rough patch to make the scalarizer support minloc calls. It regresses on minloc_1.f90 at least, but I haven't be able to pinpoint the problem in the original tree dump so far. The problem could be with the initialization of loop iteration variables. The existing code used for scalar minloc was versioning loops, that is it was using too loops in a row in some cases. With scalar minloc, the initialization of the loop variable could just be disabled in the second loop, but if there is more than one dimension as in the array case, this can't work. So the patch above initializes the loop variables conditionally on a "loop_break" boolean variable, which I hoped the optimizers would be able to remove. Unfortunately, this conditional initialization seems to confuse the optimizers a lot. Anyway, the patch is there; not sure how much I can pursue this further in the future.
[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 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin --- (In reply to kargl from comment #4) > What the heck does "RESOLVED MOVED"? I think it means this PR is not a gcc bug and the problem is tracked on some other project's bug tracker (it is "moved" there). Not sure where else the problem is tracked in this case.
[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996 Mikael Morin changed: What|Removed |Added Target Milestone|--- |14.0
[Bug fortran/108957] Fortran FE memleak with interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957 Mikael Morin changed: What|Removed |Added Target Milestone|--- |14.0
[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050 Mikael Morin changed: What|Removed |Added Target Milestone|--- |14.0
[Bug fortran/108957] Fortran FE memleak with interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Mikael Morin --- Fixed for gfortran 14, closing.
[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Mikael Morin --- Fixed for gfortran 14. Closing.
[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Mikael Morin --- Fixed for gfortran 14. Closing.
[Bug fortran/111339] New: bounds-check does not detect nonconforming functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111339 Bug ID: 111339 Summary: bounds-check does not detect nonconforming functions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org CC: anlauf at gcc dot gnu.org, dfranke at gcc dot gnu.org, gcc-bugs at gcc dot gnu.org, P.Schaffnit at access dot rwth-aachen.de, tkoenig at gcc dot gnu.org, urbanjost at comcast dot net, vivekrao4 at yahoo dot com Depends on: 31059 Blocks: 27766, 37802 Target Milestone: --- +++ This bug was initially created as a clone of Bug #31059 +++ Gfortran does not report an error if an allocatable array is set to a function of larger size, for example in the code below. program p integer, allocatable :: ivec(:) ivec = [1, 2] ! ivec(:) = func() ! case 1 (already diagnosed) ! ivec(:) = ivec + func() ! case 2 ! ivec(:) = func() + ivec ! case 3 contains function func() integer :: func(3) func = [7, 8, 9] end function func end Uncomment either case 1, case 2 or case 3, and see if the program leads to a runtime error with -fcheck=bounds. Case 1 is diagnosed, but not case 2 and neither case 3. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766 [Bug 27766] [meta-bug] -fbounds-check related bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059 [Bug 31059] bounds-check does not detect nonconforming assignment arrays https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37802 [Bug 37802] Improve wording for matmul bound checking
[Bug fortran/108957] Fortran FE memleak with interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957 Mikael Morin changed: What|Removed |Added Last reconfirmed||2023-09-08 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Mikael Morin --- (In reply to anlauf from comment #4) > Mikael, > > are you still onto it? Thanks for the reminder. This PR had disappeared from my radar. Taking it.
[Bug fortran/89891] [meta-bug] Accessing memory in rejected statements or expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891 Bug 89891 depends on bug 48776, which changed state. Bug 48776 Summary: ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Mikael Morin --- Fixed for gcc 14. Closing.
[Bug fortran/107923] ICE in lookup_function_fuzzy_find_candidates / check_interface0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107923 Mikael Morin changed: What|Removed |Added Resolution|--- |DUPLICATE CC||mikael at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Mikael Morin --- All the testcases here have been fixed by the fix for pr48776. Closing as duplicate. *** This bug has been marked as a duplicate of bug 48776 ***
[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 Mikael Morin changed: What|Removed |Added CC||gs...@t-online.de --- Comment #10 from Mikael Morin --- *** Bug 107923 has been marked as a duplicate of this bug. ***
[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996 Mikael Morin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #9 from Mikael Morin --- Created attachment 55801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55801=edit Draft patch, to be cleaned up. I need to clean up this, but it passes the fortran testsuite in its current form.
[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 Mikael Morin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Mikael Morin --- Created attachment 55800 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55800=edit Draft patch This seems to work on comment #0. Not tested otherwise.
[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 --- Comment #7 from Mikael Morin --- (In reply to Mikael Morin from comment #6) > Can't reproduce with a recent master (14.0.0 20230814). Sorry, missed the -std=f95 flag. Confirmed on recent master.
[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #6 from Mikael Morin --- Can't reproduce with a recent master (14.0.0 20230814).
[Bug fortran/86657] ASAN error: heap-use-after-free gcc/fortran/symbol.c:1762 in gfc_add_flavor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86657 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #6 from Mikael Morin --- Can't reproduce with recent master (14.0.0 20230814).
[Bug fortran/68152] ICE on declaring array result for function and entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68152 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- Seems to be accepted with recent master (14.0.0 20230814).
[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996 --- Comment #8 from Mikael Morin --- (In reply to JuzheZhong from comment #7) > Do you have a solution that we can fix RISC-V backend? No, this is not RISC-V specific. > Or you will fix it in Fortran front-end? Yes, the fix will have to be in the fortran front-end, but I haven't found it yet.
[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996 --- Comment #6 from Mikael Morin --- (In reply to Mikael Morin from comment #5) > Here sym->formal_ns is NULL because the symbol C has not been completely > setup. This makes the following an "obvious" fix: diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc index 8182ef29f43..5afb9f2e2d3 100644 --- a/gcc/fortran/decl.cc +++ b/gcc/fortran/decl.cc @@ -7496,6 +7496,7 @@ gfc_match_function_decl (void) sym->attr.module_procedure = 1; gfc_new_block = sym; + sym->formal_ns = gfc_current_ns; m = gfc_match_formal_arglist (sym, 0, 0); if (m == MATCH_NO) @@ -7993,6 +7994,7 @@ gfc_match_subroutine (void) sym = sym->result; gfc_new_block = sym; + sym->formal_ns = gfc_current_ns; /* Check what next non-whitespace character is so we can tell if there is the required parens if we have a BIND(C). */ However, that patch makes the situation worse by releasing the namespace for "c" too early, as we access it later in reject_statement (it is the "current" namespace).
[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996 Mikael Morin changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-17 CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin --- Confirmed on the reduced example from comment #2. The problem arises because of the bogus subroutine statement: SUBROUTINE c(d) e This is rejected and symbols C and D should be released (no symbol has been built for E at the time the statement is rejected). D is released, but C is not, and it keeps a pointer to D through it's formal field. BOOM. The reason C is not released is its reference count is 2 and the condition to break cycles at the beginning of gfc_release_symbol doesn't hold: 3118 if (sym->formal_ns != NULL && sym->refs == 2 && sym->formal_ns != sym->ns 3119 && (!sym->attr.entry || !sym->module)) Here sym->formal_ns is NULL because the symbol C has not been completely setup.
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #42 from Mikael Morin ---
(In reply to anlauf from comment #41)
> (In reply to Mikael Morin from comment #40)
> > Harald, I have just closed the followup PR110419.
> > I think this PR can be closed as well, or is there something left to be
> > done?
>
> It is pretty much done.
>
> There is a minor memleak for the bind(c) case left that can be seen for
> testcase gfortran.dg/bind_c_usage_13.f03 or the reduced version:
>
> program p
> interface
> subroutine val_c (c) bind(c)
>use iso_c_binding, only: c_char
>character(len=1,kind=c_char), value :: c
> end subroutine val_c
> end interface
> call val_c ("A")
> end
>
> The leak is plugged by the first part of the patch attached to comment#37:
>
> diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
> index 52cd88f5b00..ee3cd47cf91 100644
> --- a/gcc/fortran/trans-expr.cc
> +++ b/gcc/fortran/trans-expr.cc
> @@ -4044,8 +4044,9 @@ conv_scalar_char_value (gfc_symbol *sym, gfc_se *se,
> gfc_expr **expr)
>gfc_typespec ts;
>gfc_clear_ts ();
>
> - *expr = gfc_get_int_expr (gfc_default_character_kind, NULL,
> - (*expr)->value.character.string[0]);
> + gfc_expr *tmp = gfc_get_int_expr (gfc_default_character_kind, NULL,
> + (*expr)->value.character.string[0]);
> + gfc_replace_expr (*expr, tmp);
> }
>else if (se != NULL && (*expr)->expr_type == EXPR_VARIABLE)
> {
>
> Shall we commit this one?
Sure, go ahead.
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360 --- Comment #40 from Mikael Morin --- Harald, I have just closed the followup PR110419. I think this PR can be closed as well, or is there something left to be done?
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Mikael Morin --- The value_9.f90 FAIL is gone after the commit: https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793383.html whereas it was present before: https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793371.html Closing as FIXED. Thanks to all who contributed to the resolution.
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #19 from Mikael Morin --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2023-August/059666.html https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626870.html
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #18 from Mikael Morin ---
Created attachment 55662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55662=edit
Updated tentative patch
This fixes comment #4 as well, but the failure on value_9 remains on 32 bit
powerpc.
It is almost testsuite clean on x86_64.
There is a regression on c_char_tests_2.f03 because there is a hole in the
handling of single char values in gfc_conv_procedure_call.
Length one arguments are handled with:
6436 else if (fsym && fsym->attr.value)
6437{
6438 if (fsym->ts.type == BT_CHARACTER
6439 && fsym->ts.is_c_interop
6440 && fsym->ns->proc_name != NULL
6441 && fsym->ns->proc_name->attr.is_bind_c)
6442{
// Pass single char value
6447}
6448 else
6449{
6450gfc_conv_expr (, e);
6451
6456if (!fsym->ts.is_c_interop
6457&& gfc_length_one_character_type_p (>ts))
6458 {
// pass single char value
The failing case is when the type is interoperable (character(c_char)), but the
procedure is not bind(c). So the translation from string to single character
is neither done in the if branch (the procedure is not bind(c)) nor in the if
of the else branch (the type is interoperable).
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #17 from Mikael Morin ---
Created attachment 55660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55660=edit
Update function type patch
This patch changes the dummy argument declaration type.
It changes the dump as follows.
--- m32/pr110419_comment4.f90.005t.original 2023-07-05 13:05:58.743843174
+
+++ pr110419_comment4.f90.005t.original 2023-07-30 19:31:20.880043687 +
@@ -1,5 +1,5 @@
__attribute__((fn spec (". r w ")))
-void val (character(kind=1)[1:1] & restrict x, character(kind=1)[1:1] c,
integer(kind=4) _x, integer(kind=4) _c)
+void val (character(kind=1)[1:1] & restrict x, character(kind=1) c,
integer(kind=4) _x, integer(kind=4) _c)
{
{
struct __st_parameter_dt dt_parm.0;
@@ -25,7 +25,7 @@
_gfortran_transfer_character_write (_parm.1, , 1);
_gfortran_st_write_done (_parm.1);
}
- if (c[1]{lb: 1 sz: 1} != (*x)[1]{lb: 1 sz: 1})
+ if ((*x)[1]{lb: 1 sz: 1} != c)
{
_gfortran_stop_numeric (1, 0);
}
@@ -36,7 +36,7 @@
__attribute__((fn spec (". ")))
void p ()
{
- static void val (character(kind=1)[1:1] & restrict, character(kind=1)[1:1],
integer(kind=4), integer(kind=4));
+ static void val (character(kind=1)[1:1] & restrict, character(kind=1),
integer(kind=4), integer(kind=4));
static integer(kind=4) a = 65;
{
It seems to fix comment #4 (both 32 and 64 bits).
[Bug fortran/87142] Aliasing issue with overloaded assignment and allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142 Bug 87142 depends on bug 110618, which changed state. Bug 110618 Summary: Dependency between arguments when one is allocatable array whose dummy is intent(out) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/110618] Dependency between arguments when one is allocatable array whose dummy is intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Mikael Morin --- Fixed for 14.0.
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #15 from Mikael Morin ---
rs6000_pass_by_reference returns true with -m32, and false with -m64.
So the second argument is passed by reference with -m32, and by value with
-m64.
So the code in val looks right, it is the code in p calling val which isn't.
val is declared as:
void val (character(kind=1)[1:1] & restrict x, character(kind=1)[1:1] c,
integer(kind=8) _x, integer(kind=8) _c)
so the second argument has array type, whereas p calls val with:
void p ()
{
...
character(kind=1) char.5_3;
:
...
val (&"A"[1]{lb: 1 sz: 1}, char.5_3, 1, 1); [static-chain: ]
so the second actual argument has non-array type.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #18 from Mikael Morin --- Followup patches submitted: https://gcc.gnu.org/pipermail/fortran/2023-July/059580.html https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624081.html
[Bug fortran/110618] Dependency between arguments when one is allocatable array whose dummy is intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618 Mikael Morin changed: What|Removed |Added Last reconfirmed||2023-07-13 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin --- Patches submitted: https://gcc.gnu.org/pipermail/fortran/2023-July/059596.html https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624384.html
[Bug fortran/99798] ICE when compiling a variant of pr87907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin --- Created attachment 55524 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55524=edit Draft patch I haven't completely nailed it down, but it seems that the reason for this is the obscure condition in gfc_release_symbol to break cycles. It triggers on the symbol for g imported from the module. The symbol has 2 references, one for the submodule namespace holding it, one for subroutine namespace that is being freed.
[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #6 from Mikael Morin ---
(In reply to Mikael Morin from comment #5)
> Possibly walking the symbols in reverse order to release them would fix this.
>
It seems to work:
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 37a9e8fa0ae..4a71d84b3fe 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -3661,7 +3661,7 @@ gfc_restore_last_undo_checkpoint (void)
gfc_symbol *p;
unsigned i;
- FOR_EACH_VEC_ELT (latest_undo_chgset->syms, i, p)
+ FOR_EACH_VEC_ELT_REVERSE (latest_undo_chgset->syms, i, p)
{
/* Symbol in a common block was new. Or was old and just put in common
*/
if (p->common_block
[Bug fortran/110618] Dependency between arguments when one is allocatable array whose dummy is intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618 --- Comment #1 from Mikael Morin --- Created attachment 55517 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55517=edit Draft patch This seems to work for this case, but I'm not sure how reliable it is.
[Bug fortran/110618] New: Dependency between arguments when one is allocatable array whose dummy is intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618 Bug ID: 110618 Summary: Dependency between arguments when one is allocatable array whose dummy is intent(out) Product: gcc Version: 11.4.1 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org CC: abensonca at gcc dot gnu.org, anlauf at gcc dot gnu.org, burnus at gcc dot gnu.org, kargl at gcc dot gnu.org, vladimir.fuka at gmail dot com Depends on: 92178 Blocks: 87142 Target Milestone: --- +++ This bug was initially created as a clone of Bug #92178 +++ PR 92178 has several cases of dependency between arguments when one of them is deallocated before the call in the process of argument association. Here is another example which I don't want to handle there (and which I don't know how to fix). program p implicit none type t integer :: i end type t type u class(t), allocatable :: ta(:) end type u type(u), allocatable :: c(:) class(t), allocatable :: d(:) allocate(c, source = [u([t(1), t(3)]), u([t(4), t(9)])]) allocate(d, source = [t(1), t(5)]) call bar ( & allocated(c(d(1)%i)%ta), & d, & c(d(1)%i)%ta,& allocated (c(d(1)%i)%ta) & ) if (allocated (c(1)%ta)) stop 11 if (.not. allocated (c(2)%ta)) stop 12 contains subroutine bar (alloc, x, y, alloc2) logical :: alloc, alloc2 class(t), allocatable, intent(out) :: x(:) class(t), allocatable, intent(out) :: y(:) if (allocated (x)) stop 1 if (.not. alloc) stop 2 if (.not. alloc2) stop 3 end subroutine bar end Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142 [Bug 87142] Aliasing issue with overloaded assignment and allocatable components https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 [Bug 92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin --- When matching statement "type t(k)", two symbols are created, one for t and one for k. t is in gfc_current_ns and k is in t's f2k_derived namespace. If the statement is rejected, both t and k need to be freed. But one should care about ordering, as the release of t frees f2k_derived, which is k's namespace, so k should be released before t. I haven't checked that the above actually is the problem here, but it might be. Possibly walking the symbols in reverse order to release them would fix this. Regarding the patches posted, if sym->refs < 0 is true, then the memory for sym has already been released and may be garbage (including sym->refs). A crash is as good as anything else at this point IMHO.
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 --- Comment #14 from Mikael Morin --- The tree optimized dumps are almost the same for 32 and 64 bits. The expand dumps show more significant differences. The 64 bits dump shows the register r4 is saved to memory with: (insn 3 2 4 2 (set (mem/c:QI (plus:DI (reg/f:DI 111 virtual-incoming-args) (const_int 8 [0x8])) [10 c+0 S1 A64]) (reg:QI 4 4 [ c ])) "pr110419_comment4.f90":6:16 -1 (nil)) The 32 bits dump shows: (insn 3 2 4 2 (set (reg/v:SI 119) (reg:SI 4 4)) "pr110419_comment4.f90":6:16 -1 (nil)) (insn 4 3 5 2 (set (reg:QI 120) (mem/c:QI (reg/v:SI 119) [10 c+0 S1 A8])) "pr110419_comment4.f90":6:16 -1 (nil))
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 --- Comment #13 from Mikael Morin --- Created attachment 55488 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55488=edit -m64 rtl final dump at -O0
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 --- Comment #12 from Mikael Morin --- Created attachment 55487 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55487=edit -m64 rtl expand dump at -O0
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 --- Comment #11 from Mikael Morin --- Created attachment 55486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55486=edit -m64tree optimized (at -O0) dump
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 --- Comment #10 from Mikael Morin --- The three previous dumps are generated with the example in comment #4. The problem seems to turn around the val function needing to take the address of the c argument, which is passed by value. On powerpc, the value is available in a register. I guess the ABI specifies how this case is supposed to work?
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 --- Comment #9 from Mikael Morin --- Created attachment 55480 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55480=edit -m32 final rtl dump at -O0
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 --- Comment #8 from Mikael Morin --- Created attachment 55479 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55479=edit -m32 rtl exand dump at -O0
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 --- Comment #7 from Mikael Morin --- Created attachment 55478 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55478=edit -m32 tree optimized (at -O0) dump
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 --- Comment #6 from Mikael Morin --- I finally got my access on gcc110 working. (gdb) r Starting program: /home/mmorin/gcc-pr110360/pr110360/pr110419_comment4 Program received signal SIGSEGV, Segmentation fault. 0x1684 in val (x=..., c=..., _x=268635256, _c=268635135) at pr110419_comment4.f90:6 6 subroutine val (x, c) (gdb) x/4cb 0x1abc: 65 'A' 0 '\000'0 '\000'0 '\000' (gdb) x/4cb 0xfffef30c: 0 '\000'0 '\000'0 '\000'8 '\b' (gdb) p _x $1 = 268635256 (gdb) p _c $2 = 268635135 (gdb) info registers r0 0x1804 268437508 r1 0xfffef1a0 4294898080 r2 0xf7fe9e40 4160659008 r3 0x1abc 268438204 r4 0x4165 r5 0x1 1 r6 0x1 1 r7 0x0 0 r8 0xfd60354 265683796 r9 0x1000 268435456 r100xfffef338 4294898488 r110xfffef338 4294898488 r120x24000842 603981890 r130x10028028 268599336 r140x0 0 r150x0 0 r160x0 0 r170x0 0 r180x0 0 r190x0 0 r200x0 0 r210x0 0 r220x0 0 r230x0 0 r240x0 0 r250x0 0 r260x0 0 r270xf7fdf970 4160616816 r280xf7fe 4160618496 r290x0 0 r300x4165 r310xfffef1a0 4294898080 pc 0x1684 0x1684 msr0xd032 53298 cr 0x24000842 603981890 lr 0x1804 0x1804 ctr0xfc248a0 264390816 xer0x0 0 fpscr 0x0 0 vscr 0x1 65536 vrsave 0x -1 orig_r30x1800 268437504 trap 0x300 768 (gdb) p $3 = (PTR TO -> ( character*1 )) 0x1abc The debug info seems to be somewhat broken, but the arguments seem to be passed to r3, r4, r5, r6 registers and have the right value there. (gdb) disass Dump of assembler code for function val: 0x1664 <+0>: stwur1,-400(r1) 0x1668 <+4>: mflrr0 0x166c <+8>: stw r0,404(r1) 0x1670 <+12>:stw r30,392(r1) 0x1674 <+16>:stw r31,396(r1) 0x1678 <+20>:mr r31,r1 0x167c <+24>:stw r3,360(r31) 0x1680 <+28>:mr r30,r4 => 0x1684 <+32>:lbz r9,0(r30) 0x1688 <+36>:stb r9,364(r31) 0x168c <+40>:stw r5,368(r31) 0x1690 <+44>:stw r6,372(r31) 0x1694 <+48>:stw r11,376(r31) 0x1698 <+52>:lis r9,4096 0x169c <+56>:addir9,r9,2676 Not sure I read assembly correctly, but looks like we are trying to load the second argument (available in r4) by reference instead of by value. I don't know what to look at next.
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 --- Comment #2 from Mikael Morin --- (In reply to Mikael Morin from comment #1) > Harald committed an additional fix to the PR: > Unfortunately, the failure on big endian power remains. Is the execution output the same as before?
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- Harald committed an additional fix to the PR: The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa commit r14-2171-g8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa Author: Harald Anlauf Date: Wed Jun 28 22:16:18 2023 +0200 Fortran: ABI for scalar CHARACTER(LEN=1),VALUE dummy argument [PR110360] gcc/fortran/ChangeLog: PR fortran/110360 * trans-expr.cc (gfc_conv_procedure_call): For non-constant string argument passed to CHARACTER(LEN=1),VALUE dummy, ensure proper dereferencing and truncation of string to length 1. gcc/testsuite/ChangeLog: PR fortran/110360 * gfortran.dg/value_9.f90: Add tests for intermediate regression.
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360 --- Comment #23 from Mikael Morin --- (In reply to anlauf from comment #22) > Created attachment 55418 [details] > Slighty revised version of 3rd patch > > I've looked at gfc_conv_string_parameter, which I was not aware of. > This can be used for a more readable patch. > Looks good. > It appears one could even use the revised part for constant arguments, too. > However, this changes the tree-dump for gfortran.dg/bind_c_usage_13.f03 > slightly in two places, implying the need for an adjustment of the pattern. > As I am not entirely sure whether the result of that change is correct, > I refrained from using that version. > OK, let's play it safe. > (The partial output from Power BE appears to suggest that constant argument > is still right.) > > Mikael: do you want to test on Power, or shall I proceed? Sorry, still can't login at the moment. Reading the account creation message again, I may need to wait "a few days". So please proceed.
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360 --- Comment #21 from Mikael Morin --- (In reply to anlauf from comment #20) > Created attachment 55407 [details] > Third patch set > > Here's a lightly tested 3rd patch that tries to handle the chaos I created... > > Can you have a look? This looks good. There is gfc_conv_string_parameter that seems to be used often with gfc_string_to_single_character and that you could use to generate the address, but it is basically equivalent to your solution, I think. .
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360 --- Comment #19 from Mikael Morin --- (In reply to Mikael Morin from comment #18) > There is the "obvious" problem that gfc_build_wide_string_const creates a > bare array, whereas gfc_string_to_single_character expects a pointer > wrapping around it. > I was wrong saying above that "A" is a pointer. It is converted to a > pointer if passed as argument in C, but the middle-end clearly distinguishes > between arrays and pointers, and "A" is an array, not a pointer to an array. Sorry, you can scratch that, the failing case is the NON-constant case.
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360 --- Comment #18 from Mikael Morin --- (In reply to Mikael Morin from comment #15) > I have asked for an account on the compile farm (see > https://gcc.gnu.org/wiki/CompileFarm) to have access to a powerpc machine. It was pretty fast to get the green light, but then the machines have to see the change of configuration to accept my logging in. It's not working yet. (In reply to anlauf from comment #17) > Running under gdb seems to tell that gfc_string_to_single_character returns > a NULL_TREE for yet unknown reason. There is the "obvious" problem that gfc_build_wide_string_const creates a bare array, whereas gfc_string_to_single_character expects a pointer wrapping around it. I was wrong saying above that "A" is a pointer. It is converted to a pointer if passed as argument in C, but the middle-end clearly distinguishes between arrays and pointers, and "A" is an array, not a pointer to an array.
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360 --- Comment #15 from Mikael Morin --- (In reply to anlauf from comment #14)> > Let's hope that somebody with access to such a system can run the testcase > manually and append the output to this PR. I have asked for an account on the compile farm (see https://gcc.gnu.org/wiki/CompileFarm) to have access to a powerpc machine. You may want to do the same, can prove handy sometimes. I'll investigate tomorrow and post the missing information here.
