[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #12 from José Rui Faustino de Sousa --- (In reply to Dominique d'Humieres from comment #11) > Did you try to click on 'take' in > > Assignee: > Not yet assigned to anyone (edit) (take) > I do not have the "edit" or "take" links and if I click "Not yet assigned to anyone" it tries to send an email to "unassig...@gcc.gnu.org"... Thank you very much. Best regards, José Rui
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #10 from José Rui Faustino de Sousa --- (In reply to Dominique d'Humieres from comment #9) > > Patch (version 2) posted: > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055991.html > > Please assign the PR to yourself when you submit a patch! Sorry to bother you, but how do I assign the PR? I don't think I have the necessary permissions, but I may be missing something obvious... Thank you very much. Best regards, José Rui
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #8 from José Rui Faustino de Sousa --- Patch (version 2) posted: https://gcc.gnu.org/pipermail/fortran/2021-April/055991.html
[Bug fortran/100245] ICE on automatic reallocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100245 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html
[Bug fortran/100245] New: ICE on automatic reallocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100245 Bug ID: 100245 Summary: ICE on automatic reallocation Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50667 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50667=edit Fortran code showing problem Hi All! Automatic reallocation ICEs when assigning class to derived type. Seen on: GNU Fortran (GCC) 12.0.0 20210424 (experimental) GNU Fortran (GCC) 11.0.1 20210424 (prerelease) GNU Fortran (GCC) 10.3.1 20210424 GNU Fortran (GCC) 9.3.1 20210424 Thank you very much. Best regards, José Rui
[Bug fortran/82376] Duplicate function call using -fcheck=pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82376 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-April/055973.html
[Bug fortran/100136] [11/12 Regression] ICE, regression, using flag -fcheck=pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136 --- Comment #3 from José Rui Faustino de Sousa --- Only handles the ICE... Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html
[Bug fortran/100136] New: ICE, regression, using flag -fcheck=pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136 Bug ID: 100136 Summary: ICE, regression, using flag -fcheck=pointer Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50623=edit Fortran code showing problem Hi All! ICE using flag -fcheck=pointer. Seen on: GNU Fortran (GCC) 11.0.1 20210417 (experimental) Older versions don't ICE, but don't do any checking either... Thank you very much. Best regards, José Rui
[Bug fortran/100132] Optimization breaks pointer association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132 --- Comment #1 from José Rui Faustino de Sousa --- Patch posted https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html
[Bug fortran/100132] New: Optimization breaks pointer association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132 Bug ID: 100132 Summary: Optimization breaks pointer association Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50622=edit Fortran code showing problem Hi All! Pointer association is lost when compiling with -O1 or -O2, curiously not with -O3 unless -fcheck=recursion is used Seen on: GNU Fortran (GCC) 11.0.1 20210417 (experimental) GNU Fortran (GCC) 10.3.1 20210417 GNU Fortran (GCC) 9.3.1 20210417 Thank you very much. Best regards, José Rui
[Bug fortran/100120] associated intrinsic failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100120 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted. https://gcc.gnu.org/pipermail/fortran/2021-April/055942.html
[Bug fortran/100098] Polymorphic pointers and allocatables have incorrect rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100098 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted. https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html
[Bug fortran/100097] Unlimited polymorphic pointers and allocatables have incorrect rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100097 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted. https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html
[Bug fortran/100094] Undefined pointers have incorrect rank when using optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100094 --- Comment #3 from José Rui Faustino de Sousa --- (In reply to kargl from comment #1) > Isn't the code invalid Fortran because it references an undefined pointer? > If yes, the compiler is allows to do whatever it wants with the code. AFAIK that is correct off all the "associate-like" constructs, the only exception is select rank. 11.1.10.3 Attributes of a SELECT RANK associate name, paragraph 3: "The associating entity has the ALLOCATABLE, POINTER, or TARGET attribute if the selector has that attribute. The other attributes of the associating entity are described in 11.1.3.3." Best regards, José Rui
[Bug fortran/100040] Wrong code with intent out assumed-rank allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100040 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted. https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html
[Bug fortran/100029] ICE on subroutine call with allocatable polymorphic assumed-rank argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted. https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html
[Bug fortran/100120] New: associated intrinsic failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100120 Bug ID: 100120 Summary: associated intrinsic failure Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50617=edit Fortran code showing problem Associated intrinsic returns wrong results with polymorphic pointers. Seen on: GNU Fortran (GCC) 11.0.1 20210415 (experimental) GNU Fortran (GCC) 10.3.1 20210415 GNU Fortran (GCC) 9.3.1 20210415 Thank you very much. Best regards, José Rui
[Bug fortran/100118] New: ICE on sizeof with derived type components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100118 Bug ID: 100118 Summary: ICE on sizeof with derived type components Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50616 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50616=edit Fortran code showing problem ICE on using sizeof with derived type components. seen on: GNU Fortran (GCC) 11.0.1 20210415 (experimental) GNU Fortran (GCC) 10.3.1 20210415 GNU Fortran (GCC) 9.3.1 20210415 Thank you very much. Best regards, José Rui
[Bug fortran/100103] New: Automatic reallocation fails inside select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100103 Bug ID: 100103 Summary: Automatic reallocation fails inside select rank Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50606 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50606=edit Fortran code showing problem Hi All! Automatic reallocation on intrinsic assignment fails inside select rank construct. Seen on: GNU Fortran (GCC) 11.0.1 20210415 (experimental) GNU Fortran (GCC) 10.3.1 20210415 Thank you very much. Best regards, José Rui
[Bug fortran/100098] New: Polymorphic pointers and allocatables have incorrect rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100098 Bug ID: 100098 Summary: Polymorphic pointers and allocatables have incorrect rank Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50601 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50601=edit Fortran code showing problem Hi All! Rank information is not correctly written into the pointer and allocatable polymorphic object descriptors. Seen on: GNU Fortran (GCC) 11.0.1 20210415 (experimental) GNU Fortran (GCC) 10.3.1 20210415 Thank you very much. Best regards, José Rui
[Bug fortran/100097] New: Unlimited polymorphic pointers and allocatables have incorrect rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100097 Bug ID: 100097 Summary: Unlimited polymorphic pointers and allocatables have incorrect rank Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50600 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50600=edit Fortran code showing problem Hi All! Rank information is not correctly written into the pointer and allocatable unlimited polymorphic descriptors. Seen on: GNU Fortran (GCC) 11.0.1 20210415 (experimental) GNU Fortran (GCC) 10.3.1 20210415 Thank you very much. Best regards, José Rui
[Bug fortran/100094] New: Undefined pointers have incorrect rank when using optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100094 Bug ID: 100094 Summary: Undefined pointers have incorrect rank when using optimization Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50599 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50599=edit Fortran code showing problem Hi All! Rank information is not correctly written into the pointer descriptor when using optimization or -ffpe-trap. Seen on: GNU Fortran (GCC) 11.0.1 20210415 (experimental) GNU Fortran (GCC) 10.3.1 20210415 Thank you very much. Best regards, José Rui
[Bug fortran/100040] New: Wrong code with intent out assumed-rank allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100040 Bug ID: 100040 Summary: Wrong code with intent out assumed-rank allocatable Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50562 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50562=edit Fortran code showing problem Hi All! With intent out assumed-rank allocatable argument the generated code is missing is missing the descriptor copy out. Seen in: GNU Fortran (GCC) 11.0.1 20210411 (experimental) GNU Fortran (GCC) 10.3.1 20210411 Thank you very much. Best regards, José Rui
[Bug fortran/100029] New: ICE on subroutine call with allocatable polymorphic assumed-rank argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029 Bug ID: 100029 Summary: ICE on subroutine call with allocatable polymorphic assumed-rank argument Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50556=edit Fortran code showing problem Hi All! ICE on subroutine call when passing an allocatable polymorphic assumed-rank intent-out argument. Seen in: GNU Fortran (GCC) 11.0.1 20210411 (experimental) GNU Fortran (GCC) 10.3.1 20210411 GNU Fortran (GCC) 9.3.1 20210411 Thank you very much. Best regards. José Rui
[Bug fortran/84006] [8/9/10/11 Regression] ICE in storage_size() with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 José Rui Faustino de Sousa changed: What|Removed |Added CC||jrfsousa at gmail dot com --- Comment #8 from José Rui Faustino de Sousa --- Patch posted https://gcc.gnu.org/pipermail/fortran/2021-April/055922.html
[Bug fortran/100027] ICE on storage_size with polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027 --- Comment #1 from José Rui Faustino de Sousa --- Patch posted https://gcc.gnu.org/pipermail/fortran/2021-April/055922.html
[Bug fortran/100025] ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100025 --- Comment #1 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-April/055921.html
[Bug fortran/100024] ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100024 --- Comment #1 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-April/055921.html
[Bug fortran/100027] New: ICE on storage_size with polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027 Bug ID: 100027 Summary: ICE on storage_size with polymorphic argument Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50554 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50554=edit Fortran code showing problem Hi All! ICE on storage_size with pointer (or allocatable) array argument. Tested on: GNU Fortran (GCC) 11.0.1 20210410 (experimental) GNU Fortran (GCC) 10.3.1 20210410 GNU Fortran (GCC) 9.3.1 20210410 Thank you very much. Best regards, José Rui
[Bug fortran/100025] New: ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100025 Bug ID: 100025 Summary: ICE on subroutine missing explicit interface Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50552 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50552=edit Fortran code showing problem Hi All! ICE on assumed-rank subroutine call with missing explicit interface. Tested on: GNU Fortran (GCC) 11.0.1 20210410 (experimental) GNU Fortran (GCC) 10.3.1 20210410 Does not ICE on: GNU Fortran (GCC) 9.3.1 20210410 Thank you very much. Best regards, José Rui
[Bug fortran/100024] New: ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100024 Bug ID: 100024 Summary: ICE on subroutine missing explicit interface Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50551 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50551=edit Fortran code showing problem Hi All! ICE on assumed-rank subroutine call with missing explicit interface. Tested on: GNU Fortran (GCC) 11.0.1 20210410 (experimental) GNU Fortran (GCC) 10.3.1 20210410 Does not ICE on: GNU Fortran (GCC) 9.3.1 20210410 Thank you very much. Best regards, José Rui
[Bug fortran/100018] ICE on missing polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100018 --- Comment #1 from José Rui Faustino de Sousa --- Path posted: https://gcc.gnu.org/pipermail/fortran/2021-April/055916.html
[Bug fortran/100018] New: ICE on missing polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100018 Bug ID: 100018 Summary: ICE on missing polymorphic argument Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Hi All! ICE with simple subroutine missing a dummy argument. subroutine foo(that) implicit none class(*), target, intent(in) :: this class(*), pointer, intent(out) :: that that => this return end subroutine foo Tested on: GNU Fortran (GCC) 11.0.1 20210410 (experimental) GNU Fortran (GCC) 10.3.1 20210410 GNU Fortran (GCC) 9.3.1 20210410 Thank you very much. Best regards, José Rui
[Bug fortran/91726] [8/9 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726
--- Comment #9 from José Rui Faustino de Sousa ---
Hi Paul!
This seems to fix the ICE generated by using -ftrapv -fcheck=bounds
Fixes "nelems" type and adds an optional assert to make sure it stays fixed.
Best regards,
José Rui
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index be5eb89350f..7954b138605 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -9375,7 +9375,7 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
nelems));
}
else
- nelems = build_int_cst (size_type_node, 1);
+ nelems = build_int_cst (gfc_array_index_type, 1);
if (CLASS_DATA (c)->attr.dimension
|| CLASS_DATA (c)->attr.codimension)
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 2fa17b36c03..258e885faaa 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -1446,6 +1452,7 @@ gfc_copy_class_to_class (tree from, tree to, tree nelems,
bool unlimited)
name = (const char *)(DECL_NAME (to)->identifier.id.str);
from_len = gfc_conv_descriptor_size (from_data, 1);
+ gcc_assert (TREE_TYPE (orig_nelems) == gfc_array_index_type);
tmp = fold_build2_loc (input_location, NE_EXPR,
logical_type_node, from_len, orig_nelems);
msg = xasprintf ("Array bound mismatch for dimension %d "
[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352 José Rui Faustino de Sousa changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from José Rui Faustino de Sousa --- Fixed by: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=cd49b7067893b548a10c99ea0cb6aba2977eef2e
[Bug fortran/96728] Fatal Error: Reading module inquiry functions on assumed-rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96728 José Rui Faustino de Sousa changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from José Rui Faustino de Sousa --- Fixed by: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=a240e83ce9d92786ac9a15ab815b58197b85ada2
[Bug fortran/96727] ICE with character length specified using specification function on assumed-rank array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96727 José Rui Faustino de Sousa changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from José Rui Faustino de Sousa --- Fixed by: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3a7a95a220c14043da1e1166530e1d76f001dad9
[Bug fortran/96726] ICE with user defined specification function on assumed-rank array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96726 José Rui Faustino de Sousa changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from José Rui Faustino de Sousa --- Fixed by: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=8f7d99acf6d94eed6a7f9b9f76bd4c2243c660b2
[Bug fortran/94110] Passing an assumed-size to an assumed-shape argument should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110 José Rui Faustino de Sousa changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from José Rui Faustino de Sousa --- Fixed by: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=8e1be7efcb1c68dd82e2b2c1bcf3e5ace245654d
[Bug fortran/96870] Class name on error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96870 --- Comment #1 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2020-August/054955.html
[Bug fortran/96870] New: Class name on error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96870 Bug ID: 96870 Summary: Class name on error message Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 49161 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49161=edit Fortran code demonstrating problems. Hi all! Having error messages with the internal class name is not very helpful for the average user: Error: Type mismatch in argument ‘p’ at (1); passed CLASS(__class_main_p_T0_p) to CLASS(__class_main_p_T1_t) Seen on: GNU Fortran (GCC) 9.3.1 20200831 GNU Fortran (GCC) 10.2.1 20200831 GNU Fortran (GCC) 11.0.0 20200831 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/96728] Fatal Error: Reading module inquiry functions on assumed-rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96728 --- Comment #4 from José Rui Faustino de Sousa --- Hi Paul, Sorry for the confusion. I did not knew I could (should) have assigned it to myself. Sorry for the wasted time. Thank you very much. Best regards, José Rui
[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352 José Rui Faustino de Sousa changed: What|Removed |Added Keywords||patch --- Comment #6 from José Rui Faustino de Sousa --- Done! https://gcc.gnu.org/pipermail/fortran/2020-August/054908.html Thank you very much. Best regards, José Rui
[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352 --- Comment #4 from José Rui Faustino de Sousa --- I have tested the patch posted by Steve Kargl and it seems to do the trick. Can I do anything to get this going? Best regards, José Rui
[Bug fortran/96728] New: Fatal Error: Reading module inquiry functions on assumed-rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96728 Bug ID: 96728 Summary: Fatal Error: Reading module inquiry functions on assumed-rank Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 49091 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49091=edit Fortran code demonstrating problems. Hi all! Fatal error reading modules containing inquiry functions on specification expressions. Tested on: GNU Fortran (GCC) 9.3.1 20200819 GNU Fortran (GCC) 10.2.1 20200819 GNU Fortran (GCC) 11.0.0 20200807 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/96727] New: ICE with character length specified using specification function on assumed-rank array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96727 Bug ID: 96727 Summary: ICE with character length specified using specification function on assumed-rank array Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 49090 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49090=edit Fortran code demonstrating problems. Hi all! Using a specification function depending on an assumed-rank array argument to set character length ICEs on: GNU Fortran (GCC) 9.3.1 20200819 GNU Fortran (GCC) 10.2.1 20200819 GNU Fortran (GCC) 11.0.0 20200807 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/96726] New: ICE with user defined specification function on assumed-rank array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96726 Bug ID: 96726 Summary: ICE with user defined specification function on assumed-rank array Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 49089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49089=edit Fortran code demonstrating problems. Hi all! An user defined specification function with an assumed-rank argument ICEs on: GNU Fortran (GCC) 9.3.1 20200819 GNU Fortran (GCC) 10.2.1 20200819 GNU Fortran (GCC) 11.0.0 20200807 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/96724] New: Bogus warnings with the repeat intrinsic and the flag -Wconversion-extra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96724 Bug ID: 96724 Summary: Bogus warnings with the repeat intrinsic and the flag -Wconversion-extra Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 49088 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49088=edit Fortran code demonstrating problems. Hi all! Getting bogus warnings using the flag -Wconversion-extra of the type: Warning: Conversion from INTEGER() to INTEGER(8) AFAIK the repeat intrinsic is "generic" on integer kind and, IMHO, no warnings should be generated. Tested on: GNU Fortran (GCC) 9.3.1 20200819 GNU Fortran (GCC) 10.2.1 20200819 GNU Fortran (GCC) 11.0.0 20200807 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/96418] Test coarray_alloc_comp_4.f08 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96418 --- Comment #1 from José Rui Faustino de Sousa --- And coarray_alloc_comp_3.f08 too. Best regards, José Rui
[Bug fortran/96418] New: Test coarray_alloc_comp_4.f08 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96418 Bug ID: 96418 Summary: Test coarray_alloc_comp_4.f08 ICEs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Hi all! Test coarray_alloc_comp_4.f08 ICEs if using -fcoarray=single instead of -fcoarray=lib. Thank you very much. Best regards, José Rui
[Bug fortran/82375] PDT components in PDT declarations fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82375 José Rui Faustino de Sousa changed: What|Removed |Added CC||jrfsousa at gmail dot com --- Comment #8 from José Rui Faustino de Sousa --- Hi all! Still ICEs using -fcheck=bounds Due to the bounds check the symbol gets added to the deferrdd symbols list (tlink) and then gfc_trans_deferred_vars calls gfc_check_pdt_dummy and an infinite loop is created due to the recursion into the PDT components in structure_alloc_comps. This seems to be enough to reproduce: subroutine push_8 (self) type link(mat_len) integer, len :: mat_len type (link(:)), allocatable :: next end type link type (link(:)), allocatable :: self integer :: i i = self%mat_len print *, i end subroutine push_8 Thank you very much. Best regards, José Rui
[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352 --- Comment #1 from José Rui Faustino de Sousa --- On further investigation the ICE is not generated by the extra parenthesis, but by the use of the lbound intrinsic.
[Bug fortran/95352] New: ICE on extra parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352 Bug ID: 95352 Summary: ICE on extra parenthesis Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48611=edit Fortran code demonstrating problems. Hi All! An extra parenthesis generates an ICE with: GNU Fortran (GCC) 10.1.1 20200525 GNU Fortran (GCC) 11.0.0 20200525 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/95331] Unlimited polymorphic arrays have wrong bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95331 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 48604 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48604=edit Fortran code demonstrating problems. Somehow the testcase was left behind...
[Bug fortran/95331] New: Unlimited polymorphic arrays have wrong bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95331 Bug ID: 95331 Summary: Unlimited polymorphic arrays have wrong bounds Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Hi All! Unlimited polymorphic (class(*)) arrays have wrong bounds. Tested with: GNU Fortran (GCC) 9.3.1 20200518 GNU Fortran (GCC) 10.1.1 20200518 GNU Fortran (GCC) 11.0.0 20200518 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/85868] Subarray of a pointer array associated with a pointer dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85868 --- Comment #9 from José Rui Faustino de Sousa --- Hi All, Still present in: GNU Fortran (GCC) 9.3.1 20200525 GNU Fortran (GCC) 10.1.1 20200525 GNU Fortran (GCC) 11.0.0 20200525 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/85868] Subarray of a pointer array associated with a pointer dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85868 José Rui Faustino de Sousa changed: What|Removed |Added CC||jrfsousa at gmail dot com --- Comment #8 from José Rui Faustino de Sousa --- Created attachment 48602 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48602=edit New test case
[Bug fortran/95214] New: ICE on assumed-rank character array with select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95214 Bug ID: 95214 Summary: ICE on assumed-rank character array with select rank Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48568 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48568=edit Fortran code demonstrating problems. Hi All! ICE with 10 and 11 on assumed-rank character array with select rank block. using: GNU Fortran (GCC) 10.1.1 20200518 GNU Fortran (GCC) 11.0.0 20200518 (experimental) This is very likely related to Bug 67938 and Bug 66833. Thank you very much. Best regards, José Rui
[Bug fortran/95196] New: Assumed-rank incorrect array bounds inside select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95196 Bug ID: 95196 Summary: Assumed-rank incorrect array bounds inside select rank Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48557 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48557=edit Fortran code demonstrating problems. Hi all! Assumed-rank array has incorrect array bounds inside select rank clauses. Probably related to Bug 94289. Seen with: GNU Fortran (GCC) 10.1.1 20200513 GNU Fortran (GCC) 11.0.0 20200513 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/95138] New: ICE on transfer to unlimited polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95138 Bug ID: 95138 Summary: ICE on transfer to unlimited polymorphic Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48536 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48536=edit Fortran code demonstrating problems. Hi all! ICE on 10 and 11, 9 compiles part of the code, so there is also some aspect of regression here. Using -Wsurprising gives surprising (to me...) diagnostics. Not sure if all the code is kosher, most likely it is not... using: GNU Fortran (GCC) 11.0.0 20200513 (experimental) GNU Fortran (GCC) 10.1.1 20200513 GNU Fortran (GCC) 9.3.1 20200513 Thank you very much. Best regards, José Rui
[Bug fortran/95071] New: ICE on select type block with assumed-rank selector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95071 Bug ID: 95071 Summary: ICE on select type block with assumed-rank selector Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48513 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48513=edit Fortran code demonstrating problems. Hi all! ICE on wrong code with 10 and 11, rejects valid using -finit-integer and 9. GNU Fortran (GCC) 9.3.1 20200503 GNU Fortran (GCC) 10.0.1 20200505 (prerelease) GNU Fortran (GCC) 11.0.0 20200503 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/88247] [8/9/10/11 Regression] ICE in get_array_ctor_var_strlen, at fortran/trans-array.c:2068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88247 José Rui Faustino de Sousa changed: What|Removed |Added CC||jrfsousa at gmail dot com --- Comment #7 from José Rui Faustino de Sousa --- Hi all! Reduced version still ICEs with 9/10/11 program p type t character(:), dimension(:), allocatable :: d end type t type(t), allocatable :: x associate (y => [x%d(2:1:-1)]) end associate end program p Best regards, José Rui
[Bug fortran/91726] [8/9 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726 José Rui Faustino de Sousa changed: What|Removed |Added CC||jrfsousa at gmail dot com --- Comment #7 from José Rui Faustino de Sousa --- Hi all! Still ICEs with 9/10/11 using -ftrapv -fcheck=bounds Best regards, José Rui
[Bug fortran/94048] ICE and other problems using rank intrinsic to set array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94048 --- Comment #2 from José Rui Faustino de Sousa --- Please ignore the last attachment I mixed up the bug report...
[Bug fortran/94022] Array slices of assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022 --- Comment #3 from José Rui Faustino de Sousa --- Created attachment 48274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48274=edit The cleaned-up version with pointer and bind(c) tests
[Bug fortran/94048] ICE and other problems using rank intrinsic to set array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94048 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 48273 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48273=edit The cleaned-up version with pointer and bind(c) tests
[Bug fortran/94022] Array slices of assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022 --- Comment #2 from José Rui Faustino de Sousa --- Hi Thomas! The fix to this problem seems to be simple: diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c index fdca9cc..9ad885b 100644 --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -6237,6 +6241,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, || gfc_expr_attr (e).allocatable) set_dtype_for_unallocated (, e); else if (e->expr_type == EXPR_VARIABLE + && e->ref + && e->ref->u.ar.type == AR_FULL && e->symtree->n.sym->attr.dummy && e->symtree->n.sym->as && e->symtree->n.sym->as->type == AS_ASSUMED_SIZE) If you look at the output of -fdump-tree-original of the example using pointers and bind(c) it becomes clear that setting the last dimension upper bound to -1 to mark the array as assumed-size is the problem. (That way to signal assumed-size arrays is also problematic) But that change breaks the OpenMP tests and I did not look into it any further at the time. Best regards, José Rui
[Bug fortran/94110] Erroneous code compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110 --- Comment #2 from José Rui Faustino de Sousa --- Hi Thomas! IIRC assumed-size arrays are implemented has packaged descriptor less arrays. In order to point to them or to pass them to a procedure expecting an assumed or deferred-shape array one has to create an array descriptor. To create such descriptor one must know the array bounds, which one does not for assumed-size arrays. Fortran pointers, unlike their C brethren, also carry bound information and AFAIK one can not have an array, or a pointer to an array, which has undefined bounds (what would the intrinsics like shape, ubound and size return?). So in order to point to, or pass, an assumed-size array to a procedure expecting an assumed or deferred-shape array the user must provide the missing bound information, which can be done by specifying an array section effectively creating an explicit-shape array (see PR94022). So if one has an assumed-size array “arr”, rank 3, and a procedure “sub”, with either an assumed or deferred-shape array dummy argument, one can do: a = arr(:,:,1:n) p => arr(:,:,1:n) call sub(arr(:,:,1:n)) Assuming appropriate declarations of both “a” and “p”. But one can not address the whole assumed-size array: a = arr ! already generates error p=> arr ! already generates error call sub(arr) ! The case here What IMHO might be relevant and that I could find in the standard: 8.5.8.3 Assumed-shape array (par 1): “An assumed-shape array is a nonallocatable nonpointer dummy argument array that takes its shape from its effective argument.” 8.5.8.5 Assumed-size array: C835: “An object whose array bounds are specified by an implied-shape-or-assumed-size-spec shall be a dummy data object or a named constant.” (par. 4): “An assumed-size array shall not appear in a context that requires its shape.” 9.5.2 Whole arrays (par. 2): “An assumed-size array (8.5.8.5) is permitted to appear as a whole array in an executable construct or specification expression only as an actual argument in a procedure reference that does not require the shape.” 10.1.2.2 Primary: C1002 (R1001) The designator shall not be a whole assumed-size array. 10.2.2.2 Syntax of the pointer assignment statement C1025: “The expr shall be a designator that designates a variable with either the TARGET or POINTER attribute and is not an array section with a vector subscript, or it shall be a reference to a function that returns a data pointer.” 15.5.2.4 Ordinary dummy variables (par. 16): “If a dummy argument is an assumed-shape array [...] the actual argument shall not be an assumed-size array.” 15.5.2.7 Pointer dummy variables (par. 2): “If the dummy argument does not have INTENT (IN) [...]. Otherwise, the actual argument shall be a pointer or a valid target for the dummy pointer in a pointer assignment statement. If the actual argument is not a pointer, the dummy pointer becomes pointer associated with the actual argument.” Should the compiler diagnose the error? Well it seems possible to do it and error reports are always better than surprising results... Is it required to? I would believe so... But I am interested on having the compiler hand hold me as much as possible... ;-) Best regards, José Rui
[Bug fortran/94331] New: Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 Bug ID: 94331 Summary: Bind(C) corrupts array descriptors Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48119 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48119=edit Fortran code demonstrating problems. Hi all! Call to bind(c) procedure corrupts array descriptor overwriting array bounds. in: GNU Fortran (GCC) 10.0.1 20200324 (experimental) Also in 9 but it's too buggy there to be relevant. Thank you very much. Best regards, José Rui
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 48120 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48120=edit C code demonstrating problems.
[Bug fortran/94327] Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 48113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48113=edit C code demonstrating problems.
[Bug fortran/94327] New: Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 Bug ID: 94327 Summary: Bind(c) argument attributes are incorrectly set Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48112=edit Fortran code demonstrating problems. Hi all! Argument attributes should match the dummy argument attribute not the effective argument's. Found in both: GNU Fortran (GCC) 9.3.1 20200324 and GNU Fortran (GCC) 10.0.1 20200324 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289 --- Comment #1 from José Rui Faustino de Sousa --- Hi all! My first comment is not very clear so to elaborate a bit. For assumed-rank arrays no temporary array descriptor with the correct bounds is created like it is for assumed-shape arrays. So although the array bounds are correctly reported by the lbound, ubound and shape intrinsics the underlying array descriptor is still the original one. And since it is the original array descriptor, not a temporary with correct array bounds, that is passed down the call chain subsequent procedures will get a descriptor with the wrong bounds. This will probably imply adding assumed-rank arrays to the deferred initialization list, which is already done (I guess accidentally) for bind(c) procedures. I guess by removing the condition on the first if clause in gfc_build_dummy_array_decl and, hopefully, then in the "type_of_array" switch in gfc_trans_deferred_vars. This will imply also solving PR93957. Best regards, José Rui
[Bug fortran/94289] New: Assumed-rank array bounds resuscitate on the second call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289 Bug ID: 94289 Summary: Assumed-rank array bounds resuscitate on the second call Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48096=edit Code demonstrating problems. Hi all! Assumed-rank array bounds of the type ubound:lbound are correctly set to 1:extent on the first call but they raise again in the second call. both on: GNU Fortran (GCC) 9.3.1 20200322 and GNU Fortran (GCC) 10.0.1 20200316 (experimental) Thank you very much. Best regards, José Rui P.S.- Sorry for the bad puns... :-)
[Bug fortran/94192] New: ICE on wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94192 Bug ID: 94192 Summary: ICE on wrong code Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48041 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48041=edit Code demonstrating problems. Hi all! ICE both in: GNU Fortran (GCC) 9.2.1 20200307 and GNU Fortran (GCC) 10.0.1 20200307 (experimental) simplify_bound in simplify.c does not expect an AS_DEFERRED array. Thank you very much. Best regards, José Rui
[Bug fortran/94110] New: Erroneous code compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110 Bug ID: 94110 Summary: Erroneous code compiling Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48000 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48000=edit Code demonstrating problems. Hi all! I am pretty sure this code is erroneous both because you can not pass an assumed-size to an assumed-shape and because of pointer association rules. Compiles without any warnings even using -pedantic -Wall -Wextra and others in both: GNU Fortran (GCC) 9.2.1 20200307 and GNU Fortran (GCC) 10.0.1 20200307 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/94104] New: Request for diagnostic improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104 Bug ID: 94104 Summary: Request for diagnostic improvement Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47999 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47999=edit Code demonstrating problems. Hi all! Minor nitpick, the attached program raises an error: $ gfortran ./diag.f90 ./diag.f90:10:16: 10 | print *, sumf(a) |1 Error: Actual argument for ‘a’ must be a pointer at (1) in both: GNU Fortran (GCC) 9.2.1 20200307 and GNU Fortran (GCC) 10.0.1 20200307 (experimental) The diagnostic is a bit misleading as the variable can be pointer or target. Thank you very much. Best regards, José Rui
[Bug fortran/94090] New: ICE on mismatched interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94090 Bug ID: 94090 Summary: ICE on mismatched interface Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47996 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47996=edit Code demonstrating problems. Hi all! ICE on mismatched interface, -pedantic finds the error. in both: GNU Fortran (GCC) 9.2.1 20200303 and GNU Fortran (GCC) 10.0.1 20200303 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/94048] New: ICE and other problems using rank intrinsic to set array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94048
Bug ID: 94048
Summary: ICE and other problems using rank intrinsic to set
array size
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jrfsousa at gmail dot com
Target Milestone: ---
Created attachment 47978
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47978=edit
Code demonstrating problems.
Hi all!
ICE using rank to set the size of an array.
Both in:
GNU Fortran (GCC) 9.2.1 20200303
and
GNU Fortran (GCC) 10.0.1 20200303 (experimental)
The ICE is easy to fix:
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 79e00b4..a5993ea 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3253,7 +3253,7 @@ check_references (gfc_ref* ref, bool (*checker)
(gfc_expr*))
switch (ref->type)
{
case REF_ARRAY:
- for (dim = 0; dim != ref->u.ar.dimen; ++dim)
+ for (dim = 0; dim < ref->u.ar.dimen; ++dim)
{
if (!checker (ref->u.ar.start[dim]))
return false;
On x86_64-pc-linux-gnu it tests OK.
The real problems start after that... :-)
Using the module generates:
f951: Fatal Error: Reading module ‘ice2_m.mod’ at line 23 column 6: Bad name
compilation terminated.
Using the function by itself returns a malformed array, compiling with
-fbounds-check generates the error:
At line 11 of file ./ice2.f90
Fortran runtime error: Dimension 1 of array 'bar' has extent 1 instead of -1
I belive that the error is at the interface and the ifm.n artificial variable
is not properly generated.
Thank you very much.
Best regards,
José Rui
[Bug fortran/94022] New: Array slices of assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022 Bug ID: 94022 Summary: Array slices of assumed-size arrays Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47963 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47963=edit Code demonstrating problems. Hi all! When passing array slices of assumed-size arrays the upper bound of the slice gets rewritten to mark the array as assumed-size. I believe that this behavior is incorrect and array slices are explicit shape arrays. OpenMP seems to rely on this behavior. Seen in: GNU Fortran (GCC) 9.2.1 20200303 GNU Fortran (GCC) 10.0.1 20200303 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/94020] New: Size, shape, possibly other intrinsics non standard conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94020 Bug ID: 94020 Summary: Size, shape, possibly other intrinsics non standard conforming Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47960=edit Code demonstrating problems. Hi all! The size, the shape and likely many other intrinsics to depend on the macro GFC_DESCRIPTOR_EXTENT will return spurious values for assumed-size arrays with negative lower bounds. At least size and shape will never return negative values required when dealing with assumed-size arrays. Seen in: GNU Fortran (GCC) 9.2.1 20200303 GNU Fortran (GCC) 10.0.1 20200303 (experimental) IMHO before even attempting to fix the problems it is essential that some clear official policy is agreed upon in order to define the protocol to be used to signal assumed-size and zero sized arrays. Thank you very much. Best regards, José Rui
[Bug fortran/93963] New: Select rank mishandling allocatable and pointer arguments with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93963 Bug ID: 93963 Summary: Select rank mishandling allocatable and pointer arguments with bind(c) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47925 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47925=edit Code demonstrating problems. Hi all Select rank mishandles allocatable and pointer arguments when using bind(c) with: GNU Fortran (GCC) 10.0.1 20200227 (experimental) Best regards, José Rui
[Bug fortran/93957] New: ICE (regression) passing assumed rank arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93957 Bug ID: 93957 Summary: ICE (regression) passing assumed rank arrays with bind(c) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47921 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47921=edit Code triggering ICE Hi all! ICE regression probably introduced by the patch to PR92123 in: GNU Fortran (GCC) 10.0.1 20200224 (experimental) Best regards, José Rui
[Bug driver/93874] New: ICE due to command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93874 Bug ID: 93874 Summary: ICE due to command line options Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Hi all! $ touch ./empty.c $ gcc -fdisable-tree-dse3 -fdump-passes ./empty.c The file just haves to exist and have a known file format. The -fdisable-tree value does not have to be dse3. Best regards. José Rui
[Bug fortran/92621] Segmentation fault with assumed rank allocatable intent(out) with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #3 from José Rui Faustino de Sousa --- Created attachment 47882 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47882=edit New test case
[Bug fortran/92621] Segmentation fault with assumed rank allocatable intent(out) with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
--- Comment #2 from José Rui Faustino de Sousa ---
Looked a bit further into this and found additional problems both under:
gfortran version 10.0.1 20200219 (experimental) (GCC)
and
gfortran version 9.2.1 20200219 (GCC)
With the new test case it will always crash with, infrequently, a segmentation
fault or an attempt to allocate already allocated variable.
From the code generated using -fdump-tree-original:
program alloc_p
alloc_p ()
{
struct array01_integer(kind=4) a;
a.data = 0B;
{
// allocates a
{
void * cfi.9;
// cfi.9 never gets properly initialized and sometimes
// the free tries to deallocate whatever it points to
// generating a segmentation fault
if (cfi.9 != 0B)
{
__builtin_free (cfi.9);
cfi.9 = 0B;
}
// cfi.9 is finally intialized here
cfi.9 = 0B;
// notice that a never got deallocated like it should
_gfortran_gfc_desc_to_cfi_desc (, );
a.dtype.attribute = 1; // <- unnecessary duplicate?
// when hello tries to allocate a it will crash with an
// attempt to allocate an already allocated variable
hello (cfi.9);
<...>
}
_gfortran_stop_string (0B, 0, 0);
}
}
It seems that it is generating code that will try to deallocate an
uninitialized pointer, and consequently segfault, and that the memory that
should be freed never is touched so the array will pass on still allocated.
Best regards,
José Rui
[Bug fortran/92621] Segmentation fault with assumed rank allocatable intent(out) with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 47327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47327=edit C code
[Bug fortran/92621] New: Segmentation fault with assumed rank allocatable intent(out) with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 Bug ID: 92621 Summary: Segmentation fault with assumed rank allocatable intent(out) with bind(c) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47326=edit Code demonstrating problems. Hi all! Segmentation fault both on: GNU Fortran (GCC) 9.2.1 20191119 and GNU Fortran (GCC) 10.0.0 20191119 (experimental) Seems to be triggered by an erroneous call to free on entry (required by intent(out) *if* allocated) Heisenbug type does not trigger always, does not show under gdb or valgrind. Compiling using the flag "-static-libgfortran" seems to stabilize it, crashing repeatedly, also under gdb, but not under valgrind. The flag "-Wmaybe-uninitialized" generates garbage diagnostics.
[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482 --- Comment #2 from José Rui Faustino de Sousa --- IMHO the point here is if interoperable procedures (bind(c)) are required to have arguments of interoperable type. My reading of 18.3.6 is that it is not required, most relevant for character type would be 18.3.6.2 (5) and (7). Which, like you write, imply the use of a C descriptor. If I understood it correctly the descriptor should be scalar (rank=0) and have "elem_len" equal to character length. The error in 10.0.0 is raised without using any flags and the warning in 9.1.0 requires -Wall -Wmaybe-uninitialized. Please notice that the problem shown by the "strg_print_2" procedure is without using "bind(c)". Thank you very much. Best regards, José Rui
[Bug fortran/92482] New: Possibly wrong error diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482 Bug ID: 92482 Summary: Possibly wrong error diagnostic Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47225=edit Code demonstrating problems. What seems to me a spurious error is flagged by gfortran 10.0.0 20191106: Error: Character argument ‘this’ at (1) must be length 1 because procedure ‘strg_print_0’ is BIND(C) Gfortran 9.1.0 also issues a warning and the code generated raises a segmentation fault: Warning: ‘.this’ may be used uninitialized in this function [-Wmaybe-uninitialized] I may be missing the something in the standard but I see no clause demanding this behavior and it is used on C.12.14 Mapping of MPI interfaces to Fortran. Thank you very much. Best regards, José Rui
[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 --- Comment #4 from José Rui Faustino de Sousa --- Sorry I blooped while trying to simplify the sample code... :-( The new code should ICE 10.0.0, but not 9.1.0, using either the C procedure or the Fortran bind(c) one. Using just the "arr_set" procedure with bind(c) set is very likely a duplicate of PR 92189 like you mention. Sorry for the mishap I hope the code is correct this time around. Thank you very much. Best regards, José Rui
[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 José Rui Faustino de Sousa changed: What|Removed |Added Attachment #47134|0 |1 is obsolete|| --- Comment #3 from José Rui Faustino de Sousa --- Created attachment 47135 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47135=edit Corrected code demonstrating problems.
[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 José Rui Faustino de Sousa changed: What|Removed |Added Attachment #47130|0 |1 is obsolete|| --- Comment #2 from José Rui Faustino de Sousa --- Created attachment 47134 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47134=edit Corrected code demonstrating problems.
[Bug fortran/92284] New: Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 Bug ID: 92284 Summary: Subroutine with bind(c) attribute causing varied problems Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47130 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47130=edit Code demonstrating problems. Hi all! Code attached causes various problems in both 9.1.0 and 10.0.0 including ICE on 9.1.0. The problems reported vary depending on the array having the allocatable or pointer attributes. -Wmaybe-uninitialized reports uninitialized internal variables -fcheck=* changes which. When it runs the error is: At line 26 of file ./arr.f90 Fortran runtime error: Index '1' of dimension 1 of array 'this' above upper bound of 0 Error termination. Backtrace: #0 0x401051 in arr_set at ./arr.f90:26 #1 0x4011c5 in arr_p at ./arr.f90:11 #2 0x40147c in main at ./arr.f90:14 Thank you very much. Best regards, José Rui
[Bug fortran/92277] New: ICE with assumed rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92277 Bug ID: 92277 Summary: ICE with assumed rank Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47129 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47129=edit Code triggering ICE Hi all! Internal compiler error with assumed rank arguments. GNU Fortran (GCC) 10.0.0 20191028 (experimental) Not present in GNU Fortran (GCC) 9.1.0 Command line: gfortran -c ./arr.f90 Compiler output: ./arr.f90:19:0: 19 | call arr_set_c(this) | internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘indirect_ref’ in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5261 0x6f65d5 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../gcc-trunk/gcc/tree.c:10099 0x5ff3be contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc-trunk/gcc/tree.h:3381 0x5ff3be gfc_conv_gfc_desc_to_cfi_desc ../../gcc-trunk/gcc/fortran/trans-expr.c:5261 0x8b04d2 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc-trunk/gcc/fortran/trans-expr.c:6153 0x8ead27 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc-trunk/gcc/fortran/trans-stmt.c:406 0x86e1db trans_code ../../gcc-trunk/gcc/fortran/trans.c:1920 0x89bbce gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:6791 0x8721f1 gfc_generate_module_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans.c:2250 0x81b5e5 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:6263 0x81b5e5 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:6515 0x86b11f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:208 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Thank you very much. Best regards, José Rui
[Bug fortran/92142] New: CFI_setpointer corrupts descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92142 Bug ID: 92142 Summary: CFI_setpointer corrupts descriptor Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47060 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47060=edit Code demonstrating problems. Hi all! CFI_setpointer does not check if it is setting a pointer and will set any type of object to the target. CFI_setpointer will also change the pointer attribute of the pointer to whatever is the target's attribute corrupting the descriptor. Thank you very much. Best regards, José Rui
