| Message ID | aa24b662-f174-b520-8b54-e5d26e7bd218@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [fortran,V3] PR fortran/100683 - Array initialization refuses valid | expand |
Hi José, On 17.06.21 21:34, José Rui Faustino de Sousa via Gcc-patches wrote: > Update to a proposed patch to: > PR100683 - Array initialization refuses valid > due to more errors being found... > > Patch tested only on x86_64-pc-linux-gnu. LGTM – sorry for the very belated review. > Add call to simplify expression before parsing Nit: I think you mean resolving/processing/expanding/checking – as gfc_resolve_expr comes after the actual parsing. > *and* check *appropriately* if the expression is still an array after > simplification. * * * I have to admit that I got a bit lost with your patches. Are there still outstanding patches? I also recall approving a patch quite some time ago which was then not committed for a long time. (I have not checked whether it was committed by now.) Thus: Do you have a list of patches pending review? Secondly, I assume you can commit or do you have commit issues? Tobias > Fortran: Fix bogus error > > gcc/fortran/ChangeLog: > > PR fortran/100683 > * resolve.c (gfc_resolve_expr): Add call to gfc_simplify_expr. > > gcc/testsuite/ChangeLog: > > PR fortran/100683 > * gfortran.dg/pr87993.f90: increased test coverage. > * gfortran.dg/PR100683.f90: New test. ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf
Hi Tobias, On 21/06/21 12:37, Tobias Burnus wrote: > Thus: Do you have a list of patches pending review? > https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html https://gcc.gnu.org/pipermail/fortran/2021-June/056168.html https://gcc.gnu.org/pipermail/fortran/2021-June/056167.html https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html https://gcc.gnu.org/pipermail/fortran/2021-June/056155.html https://gcc.gnu.org/pipermail/fortran/2021-June/056154.html https://gcc.gnu.org/pipermail/fortran/2021-June/056152.html https://gcc.gnu.org/pipermail/fortran/2021-June/056159.html https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html https://gcc.gnu.org/pipermail/fortran/2021-June/056169.html https://gcc.gnu.org/pipermail/fortran/2021-April/055921.html I am not 100% sure this is all of them but it should be most. > Secondly, I assume > you can commit or do you have commit issues? > Up to now there were no problems. Best regards, José Rui
Hi José, hi all, especially since my patch which moved the descriptor conversion from libgfortran to gfortran is in, I wonder whether there are still patches to be applied and useful testcases; I assume there are more issues in Bugzilla, especially as I filled myself some (often related to polymorphism or assumed rank). While I (and also Sandra) try to resolve some bugs and look at testcases: it would be helpful if others – in particular José – could check whether: (a) PRs can be now closed, (b) testcases exist which still should be added, (c) patches exist which still are applicable (even if they need to be revised). (Partial/full list below.) I hope that we can really cleanup this backlog – and possibly fix also some of the remaining bugs before GCC 12 is released! And kudos to José for the bug reports, testcases and patches – and sorry for slow reviews. I hope we resolve the pending issues and be quicker in future. Tobias PS: Old and probably current but incomplete pending patch list: On 21.06.21 17:21, José Rui Faustino de Sousa wrote: > On 21/06/21 12:37, Tobias Burnus wrote: >> Thus: Do you have a list of patches pending review? > > https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html > > https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html > > https://gcc.gnu.org/pipermail/fortran/2021-June/056168.html > > https://gcc.gnu.org/pipermail/fortran/2021-June/056167.html > > https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html > > https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html > > https://gcc.gnu.org/pipermail/fortran/2021-June/056155.html > > https://gcc.gnu.org/pipermail/fortran/2021-June/056154.html > > https://gcc.gnu.org/pipermail/fortran/2021-June/056152.html > > https://gcc.gnu.org/pipermail/fortran/2021-June/056159.html > > https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html > > https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html > > https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html > > https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html > > https://gcc.gnu.org/pipermail/fortran/2021-June/056169.html > > https://gcc.gnu.org/pipermail/fortran/2021-April/055921.html > > I am not 100% sure this is all of them but it should be most. ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Hi Tobias, My disappearance is partly responsible for the backlog. I told José that I would start working on it some months since but just have not had the time. I can do some of the reviews but still do not have much time to spare. Perhaps you could divide them up between us. Andrew Benson has been working on some standards issues associated with a patch of mine that sorts out finalization for intrinsic assignment - PR64290. The main issue was that of finalization of finalizable types/classes that themselves have finalizable array components. I believe that the patch has it right, following a comparison between the (differing!) behaviour of other brands. We have also found a case where gfortran, with the patch applied, that still does not finalize when it should. I will work up a fix for this and will coordinate with Andrew to produce testcases as necessary, well before 15th November. Best regards Paul On Fri, 22 Oct 2021 at 08:42, Tobias Burnus <tobias@codesourcery.com> wrote: > Hi José, hi all, > > especially since my patch which moved the descriptor conversion from > libgfortran to gfortran is in, I wonder whether there are still patches > to be applied and useful testcases; I assume there are more issues in > Bugzilla, especially as I filled myself some (often related to > polymorphism or assumed rank). While I (and also Sandra) try to resolve > some bugs and look at testcases: > > it would be helpful if others – in particular José – could check > whether: (a) PRs can be now closed, (b) testcases exist which still > should be added, (c) patches exist which still are applicable (even if > they need to be revised). (Partial/full list below.) > > I hope that we can really cleanup this backlog – and possibly fix also > some of the remaining bugs before GCC 12 is released! > > And kudos to José for the bug reports, testcases and patches – and sorry > for slow reviews. I hope we resolve the pending issues and be quicker in > future. > > Tobias > > PS: Old and probably current but incomplete pending patch list: > > On 21.06.21 17:21, José Rui Faustino de Sousa wrote: > > On 21/06/21 12:37, Tobias Burnus wrote: > >> Thus: Do you have a list of patches pending review? > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056168.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056167.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056155.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056154.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056152.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056159.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056169.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055921.html > > > > I am not 100% sure this is all of them but it should be most. > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: > Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; > Registergericht München, HRB 106955 >
Hi José, hi Fortraners, triage of all listed patches: > On 21.06.21 17:21, José Rui Faustino de Sousa wrote: >> https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html PR100040 - Wrong code with intent out assumed-rank allocatable PR100029 - ICE on subroutine call with allocatable polymorphic → Both: Still occurs, ICE in gfc_deallocate_scalar_with_status TODO: Review patch. >> https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html PR100097 - Unlimited polymorphic pointers and allocatables have incorrect rank PR100098 - Polymorphic pointers and allocatables have incorrect rank → Both: PASS TODO: Check whether it makes sense to apply the testcase TODO: Close PRs → See also patch below (2021-June/056169.html) >> https://gcc.gnu.org/pipermail/fortran/2021-June/056168.html PR96870 - Class name on error message → Fixed with sufficient test coverage; thus, I closed the PR. Nothing to be done. >> https://gcc.gnu.org/pipermail/fortran/2021-June/056167.html PR96724 - Bogus warnings with the repeat intrinsic and the flag -Wconversion-extra| repeat ('x', NCOPIES=i08) ! i08 is 20_1 shows: Warning: Conversion from INTEGER(1) to INTEGER(8) at (1) [-Wconversion-extra] TODO: Review patch. | >> https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html Bug 93308 - bind(c) subroutine changes lower bound of array argument in caller Bug 93963 - Select rank mishandling allocatable and pointer arguments with bind(c) Bug 94327 - Bind(c) argument attributes are incorrectly set Bug 94331 - Bind(C) corrupts array descriptors Bug 97046 - Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter → All already closed as FIXED TODO: Nothing, unless we want to pick one of the testcases. >> https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html PR94104 - Request for diagnostic improvement 10 | print *, sumf(a) | 1 Error: Actual argument for ‘a’ must be a pointer at (1) NOTE: as the dummy is intent(in), since F2008 alternatively a TARGET attr would be also okay. TODO: Review patch - in principle, I am fine with the but I am not sure the 'valid target' in the error message is clear enough. Might require some message tweaking for clarity. >> https://gcc.gnu.org/pipermail/fortran/2021-June/056155.html Gerald's PR100948 - [12 Regression] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9069 Still has an ICE. TODO: Review patch. >> https://gcc.gnu.org/pipermail/fortran/2021-June/056154.html Bug 100906 - Bind(c): failure handling character with len/=1 → Testcase now passes. Bug 100907 - Bind(c): failure handling wide character → I think now okay – but the testcase assumes elem_len/sizeof(char) == #chars but for the C descriptor, elem_len / sizeof(char-type) = #chars Thus, sz is not 1 or 7 bytes but 4 or 28 bytes (or 1/7 characters) Bug 100911 - Bind(c): failure handling C_PTR → Closed as FIXED. Bug 100914 - Bind(c): errors handling complex → Closed as FIXED Bug 100915 - Bind(c): failure handling C_FUNPTR → Closed as FIXED Bug 100916 - Bind(c): CFI_type_other unimplemented → Bogus testcase (for 't(ype)' argument) otherwise it expects CFI_type_other instead of CFI_type_struct (TODO: Is that sensible?) TODO: Check whether a testcase is needed TODO: Close the three still open PRs >> https://gcc.gnu.org/pipermail/fortran/2021-June/056152.html Bug 101047 - Pointer explicit initialization fails Bug 101048 - Class pointer explicit initialization refuses valid ..., pointer, save :: ptr => tgt fails to associate ptr with tgt (wrong-code + rejects valid) TODO: Review patch. >> https://gcc.gnu.org/pipermail/fortran/2021-June/056159.html PR92621 - Problems with memory handling with allocatable intent(out) arrays with bind(c) I think mostly fixed by my big bind(C) patch, but there still one ICE with '-fcheck=all -fsanitize=undefined' TODO: Fix that bug (unlikely to be fixed by José's patch) TODO: Check whether testcase should be added and then close the PR >> https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html PR100245 - ICE on automatic reallocation. Still ICEs TODO: Review patch. >> https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html PR100136 - ICE, regression, using flag -fcheck=pointer First testcase has an ICE with -fcheck=pointer Second testcase has always an ICE + possibly missing func. TODO: Review patch – and probably: follow-up patch for remaining issue >> https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html PR100132 - Optimization breaks pointer association. 'fn spec' is wrong :-( TODO: Review patch! >> https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html PR100103 - Automatic reallocation fails inside select rank Still segfaults at runtime for 'that = a' where the RHS is a parameter and the LHS an allocatable assumed-rank array (inside select rank). TODO: Review patch >> https://gcc.gnu.org/pipermail/fortran/2021-June/056169.html PR100097 - Unlimited polymorphic pointers and allocatables have incorrect rank PR100098 - Polymorphic pointers and allocatables have incorrect rank → Both: PASS TODO: Check whether it makes sense to apply the testcase TODO: Close PRs → See also patch above (2021-April/055933.html) >> https://gcc.gnu.org/pipermail/fortran/2021-April/055921.html PR100024 & PR100025 - ICE on missing polymorphic argument. ICE in argument_rank_mismatch TODO: Review patch. >> I am not 100% sure this is all of them but it should be most. If PRs link them, we find them eventually. Otherwise, we won't :-( Tobias ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Hi Tobias, Am 22.10.21 um 15:06 schrieb Tobias Burnus: >>> https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html > > PR100103 - Automatic reallocation fails inside select rank > Still segfaults at runtime for 'that = a' where the RHS is a parameter > and the LHS an allocatable assumed-rank array (inside select rank). > > TODO: Review patch this one LGTM. Thanks for the patch! Harald
Hi Tobias, José, Am 22.10.21 um 15:06 schrieb Tobias Burnus: >>> https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html > > PR100136 - ICE, regression, using flag -fcheck=pointer > > First testcase has an ICE with -fcheck=pointer > Second testcase has always an ICE + possibly missing func. > > TODO: Review patch – and probably: follow-up patch for remaining issue I think this LGTM. Thanks for the patch! Harald
Hi Tobias, José, Am 22.10.21 um 15:06 schrieb Tobias Burnus: >>> https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html > > PR100245 - ICE on automatic reallocation. > Still ICEs > > TODO: Review patch. this one works and LGTM. Thanks for the patch! Harald
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c index 45c3ad3..01a2977 100644 --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -7137,7 +7137,12 @@ gfc_resolve_expr (gfc_expr *e) /* Also try to expand a constructor. */ if (t) { + t = gfc_simplify_expr (e, 1); + if (!t) + break; gfc_expression_rank (e); + if (e->expr_type != EXPR_ARRAY) + break; if (gfc_is_constant_expr (e) || gfc_is_expandable_expr (e)) gfc_expand_constructor (e, false); } diff --git a/gcc/testsuite/gfortran.dg/PR100683.f90 b/gcc/testsuite/gfortran.dg/PR100683.f90 new file mode 100644 index 0000000..6929bb5 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/PR100683.f90 @@ -0,0 +1,36 @@ +! { dg-do run } +! +! Test the fix for PR100683 +! + +program main_p + + implicit none + + integer :: i + integer, parameter :: n = 11 + integer, parameter :: u(*) = [(i, i=1,n)] + + type :: foo_t + integer :: i + end type foo_t + + type, extends(foo_t) :: bar_t + integer :: a(n) + end type bar_t + + type(bar_t), parameter :: a(*) = [(bar_t(i, u), i=1,n)] + type(bar_t) :: b(n) = [(bar_t(i, u), i=1,n)] + + if(any(a(:)%i/=u)) stop 1 + do i = 1, n + if(any(a(i)%a/=u)) stop 2 + end do + if(any(b(:)%i/=u)) stop 3 + do i = 1, n + if(any(b(i)%a/=u)) stop 4 + end do + stop + +end program main_p + diff --git a/gcc/testsuite/gfortran.dg/pr87993.f90 b/gcc/testsuite/gfortran.dg/pr87993.f90 index 96d353d..abc6d0d 100644 --- a/gcc/testsuite/gfortran.dg/pr87993.f90 +++ b/gcc/testsuite/gfortran.dg/pr87993.f90 @@ -2,7 +2,15 @@ ! Code contributed by Gerhard Steinmetz <gscfq at t-online dot de> program p integer, parameter :: a(2) = 1 - integer, parameter :: b = a%kind + character, parameter :: b(2) = "X" + integer, parameter :: i = a%kind + integer, parameter :: j = a(2)%kind + integer, parameter :: k = b%kind + integer, parameter :: l = b(2)%kind if (any(a /= 1)) stop 1 - if (b /= kind(a)) stop 2 + if (any(b /= "X")) stop 2 + if (i /= kind(a)) stop 3 + if (j /= kind(a)) stop 4 + if (k /= kind(b)) stop 5 + if (l /= kind(b)) stop 6 end
Hi all! Update to a proposed patch to: PR100683 - Array initialization refuses valid due to more errors being found... Patch tested only on x86_64-pc-linux-gnu. Add call to simplify expression before parsing *and* check *appropriately* if the expression is still an array after simplification. Add two more situations (already present in the original PR) to pr87993.f90 to catch the kind of error I was making. Thank you very much. Best regards, José Rui Fortran: Fix bogus error gcc/fortran/ChangeLog: PR fortran/100683 * resolve.c (gfc_resolve_expr): Add call to gfc_simplify_expr. gcc/testsuite/ChangeLog: PR fortran/100683 * gfortran.dg/pr87993.f90: increased test coverage. * gfortran.dg/PR100683.f90: New test.