| Summary: | [F03] ASSOCIATE construct confused with slightly complicated case | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Fred Krogh <siteg> |
| Component: | fortran | Assignee: | Paul Thomas <pault> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | janus, neil.n.carlson, pault, townsend |
| Priority: | P3 | Keywords: | wrong-code |
| Version: | 4.6.0 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2014-02-10 00:00:00 | |
| Bug Depends on: | 37577 | ||
| Bug Blocks: | 20585 | ||
| Attachments: |
Fails test, with minor change works
A fix for this problem |
||
Sorry failed to include the output of the program. Here it is. i_good= 1 3 5 i_bad= 1 4197184 3 I think this is one of the bugs, which depend on a new array descriptor (cf. http://gcc.gnu.org/wiki/ArrayDescriptorUpdate). The problem is that for associate (i=>t2%j%i) the array i(1:3) is not contiguous in memory. In the current array descriptor implementation, only arrays with strides which are multiples of the block are possible - that's fine grained enough if there is only "integer :: i" but no longer if there is also another element ("integer :: k"). In that case, one needs to have strides which are byte-based ("stride multiplier") It is rather high on the to-do list of gfortran, but as the patch will be invasive and will have to be done at once as it breaks the ABI (i.e. the downward compatibility), it is still pending. The idea is that one will use a descriptor which is compatible with the upcomming TR 29113. (TR = Technical Report, small standard extension which will be also integrated in the next Fortran standard.) Cf. http://gcc.gnu.org/wiki/ArrayDescriptorUpdate Given some other larger on-going projects, the lack of time of some core developers and given that GCC 4.7 will probably already branched in September combined with the need for ABI breakage [which should happen only once], I fear it won't be fixed for 4.7 but only later. :-( Confirmed on 4.7, 4.8, and trunk (4.9 r207643). At r207649, compiling the test gives the following ICE: pr49636.f90:14:0: internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1183 print '(" i_bad=", 3I10)', i(1:3) It is caused by r207646 Author: pault Date: Sun Feb 9 20:50:21 2014 UTC (12 hours, 41 minutes ago) Changed paths: 5 Log Message: 2014-02-09 Paul Thomas <pault@gcc.gnu.org> PR fortran/57522 * resolve.c (resolve_assoc_var): Set the subref_array_pointer attribute for the 'associate-name' if necessary. * trans-stmt.c (trans_associate_var): If the 'associate-name' is a subref_array_pointer, assign the element size of the associate variable to 'span'. 2014-02-09 Paul Thomas <pault@gcc.gnu.org> PR fortran/57522 * gfortran.dg/associated_target_5.f03 : New test Created attachment 32098 [details] A fix for this problem I am sure that this trick will fix pr57019 too. This latter is claimed to be a regression but I am sure that it never worked :-) Nonetheless, I will take advantage of the regression label! I will work on it tomorrow night. By the way, this patch regtests OK on trunk. I have to make sure that substrings of character arrays work OK with ASSOCIATE. Thanks for the heads-up Dominique! Cheers Paul > Created attachment 32098 [details] > A fix for this problem AFAICT it fixes the problem for 64 bit mode only. In 32 bit mode the ICE is gone, but I get at run time i_good= 1 3 5 i_bad= 1********** 3 > I am sure that this trick will fix pr57019 too. This latter is claimed > to be a regression but I am sure that it never worked :-) Nonetheless, > I will take advantage of the regression label! > > I will work on it tomorrow night. > > By the way, this patch regtests OK on trunk. I have to make sure > that substrings of character arrays work OK with ASSOCIATE. Did you regtest with -m32? I see gfortran.dg/associated_target_5.f03 failing at execution time with -m32, as well as the first test in pr57522 0 1 2 3 0 4 1 5 Dear Dominique, Thanks for the heads-up about -m32 - I thought that the code would be immune to word length changes ***sigh*** Cheers Paul On 12 February 2014 00:40, dominiq at lps dot ens.fr <gcc-bugzilla@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49636 > > --- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- >> Created attachment 32098 [details] >> A fix for this problem > > AFAICT it fixes the problem for 64 bit mode only. In 32 bit mode the ICE is > gone, but I get at run time > > i_good= 1 3 5 > i_bad= 1********** 3 > >> I am sure that this trick will fix pr57019 too. This latter is claimed >> to be a regression but I am sure that it never worked :-) Nonetheless, >> I will take advantage of the regression label! >> >> I will work on it tomorrow night. >> >> By the way, this patch regtests OK on trunk. I have to make sure >> that substrings of character arrays work OK with ASSOCIATE. > > Did you regtest with -m32? I see gfortran.dg/associated_target_5.f03 failing at > execution time with -m32, as well as the first test in pr57522 > > 0 1 2 3 > 0 4 1 5 > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug. Ping! (In reply to Dominique d'Humieres from comment #7) > Ping! I am just going through the PRs assigned to me and tying to draw up a priority list. ***sigh*** there are quite a lot fo which there are partial fixes! Paul *** Bug 70705 has been marked as a duplicate of this bug. *** *** Bug 77310 has been marked as a duplicate of this bug. *** This has transformed itself into an ICE: associate (i=>t2%j%i) internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1278 0x5bb622 gfc_get_element_type(tree_node*) ../../trunk/gcc/fortran/trans-types.c:1278 0x895a50 trans_associate_var ../../trunk/gcc/fortran/trans-stmt.c:1741 0x89b1b1 gfc_trans_block_construct(gfc_code*) ../../trunk/gcc/fortran/trans-stmt.c:2065 0x81ed07 trans_code ../../trunk/gcc/fortran/trans.c:1924 0x84a7bd gfc_generate_function_code(gfc_namespace*) ../../trunk/gcc/fortran/trans-decl.c:6507 0x7d5ade translate_all_program_units ../../trunk/gcc/fortran/parse.c:6121 0x7d5ade gfc_parse_file() ../../trunk/gcc/fortran/parse.c:6324 0x81bf0f gfc_be_parse_file ../../trunk/gcc/fortran/f95-lang.c:204 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. Author: pault Date: Sun May 20 10:04:46 2018 New Revision: 260414 URL: https://gcc.gnu.org/viewcvs?rev=260414&root=gcc&view=rev Log: 2018-05-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/49636 * trans-array.c (gfc_get_array_span): Renamed from 'get_array_span'. (gfc_conv_expr_descriptor): Change references to above. * trans-array.h : Add prototype for 'gfc_get_array_span'. * trans-stmt.c (trans_associate_var): If the associate name is a subref array pointer, use gfc_get_array_span for the span. 2018-05-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/49636 * gfortran.dg/associate_38.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_38.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog Author: pault Date: Sun May 20 11:07:44 2018 New Revision: 260418 URL: https://gcc.gnu.org/viewcvs?rev=260418&root=gcc&view=rev Log: 2018-05-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/49636 Backport from trunk * trans-array.c (gfc_get_array_span): Renamed from 'get_array_span'. (gfc_conv_expr_descriptor): Change references to above. * trans-array.h : Add prototype for 'gfc_get_array_span'. * trans-stmt.c (trans_associate_var): If the associate name is a subref array pointer, use gfc_get_array_span for the span. 2018-05-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/49636 Backport from trunk * gfortran.dg/associate_38.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/associate_38.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-array.c branches/gcc-8-branch/gcc/fortran/trans-array.h branches/gcc-8-branch/gcc/fortran/trans-stmt.c branches/gcc-8-branch/gcc/testsuite/ChangeLog Fixed on 8-branch and trunk. The required support is just not there on 7-branch - sorry. Thanks for the report. Paul |
Created attachment 24684 [details] Fails test, with minor change works The attached 16 line fortran program shows the problem. The Intel (11.1) compiler works on this example.