[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from Dominique d'Humieres --- > Can the bug be marked as resolved? AFAICT yes.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #25 from Martin Liška --- Can the bug be marked as resolved?
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #24 from Vittorio Zecca --- It works on my x86_64-pc-linux-gnu with gfortran 7.0.1
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #23 from Iain Sandoe --- (In reply to Paul Thomas from comment #19) > Created attachment 40286 [details] > Failing testcases with -flto under Darwin > > The PR is fixed under Linux but gives a link error under Darwin with -flto. > From Dominique's message to the list on 7th December: > The tests gfortran.dg/char_result_16.f90 and gfortran.dg/char_result_17.f90 > fail with > > lto1: error: two or more sections for > .gnu.lto___get_PROC_names.3e3ee55b08747e7c > lto1: internal compiler error: cannot read LTO decls from > /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccEJosbA.o > > This may be darwin specific as the linker is more picky than the linux one. It might be Darwin-specific for a number of reasons: (a) Darwin doesn't use the linker plugin so there's a different code-path, (b) we have to wrap the LTO sections to accommodate the limitation of 255 sections on darwin (c) Something to do with missing symbol aliases (d) something else ;-) However, in this case it does not appear to be a Darwin linker issue; the ICE is in lto1 - the only external Darwin tool involved at that point is the assembler, and AFAICT the assembler is correctly rendering that there are two instances in the input assembly (as posted by Dominique and as per the complaint in the ICE). Next thing is to figure out how/why we have those two instances.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #22 from Iain Sandoe --- (In reply to Dominique d'Humieres from comment #20) > Created attachment 40303 [details] > Assembly for char_result_16 with -flto on darwin It appears that two identical entries are present: .section __GNU_LTO,__wrapper_sects,regular,debug L_GNU_LTO4: ;# .gnu.lto___get_PROC_names.547da9c50a5f9b09 .set L$gnu$lto$offs4,L_GNU_LTO4-L_GNU_LTO0 .set L$gnu$lto$size4,L_GNU_LTO5-L_GNU_LTO4 .ascii "x\234cc``\250\1bI\6\10\230\302\314\270\254\377\322" .ascii "2vE\246\371\15\34s\230\301\2G\377\177?\300\337\315<\207\231\221\221\11\310\375z\352\352D\16E.\204\374\226#\307\333" .ascii "8 \362\214@n_\347\372\277\\\212B\10\371k-s\205-\266" .ascii "5t,h0\230\303\314\304\300\270\233Q\221q\27\243\14\343N \275\3HogTd`\334\303h\301\300\356\233\230\227\236\257\240\300\356_\4d\244*\260;\26\24\344\244*(\0\0g\2-\203" .text .section __GNU_LTO,__wrapper_sects,regular,debug L_GNU_LTO2: ;# .gnu.lto___get_PROC_names.547da9c50a5f9b09 .set L$gnu$lto$offs2,L_GNU_LTO2-L_GNU_LTO0 .set L$gnu$lto$size2,L_GNU_LTO3-L_GNU_LTO2 .ascii "x\234cc``\250\1bI\6\10\230\302\314\270\254\377\322" .ascii "2vE\246\371\15\34s\230\301\2G\377\177?\300\337\315<\207\231\221\221\11\310\375z\352\352D\16E.\204\374\226#\307\333" .ascii "8 \362\214@n_\347\372\277\\\212B\10\371k-s\205-\266" .ascii "5t,h0\230\303\314\304\300\270\233Q\221q\27\243\14\343N \275\3HogTd`\334\303h\301\300\356\233\230\227\236\257\240\300\356_\4d\244*\260;\26\24\344\244*(\0\0g\2-\203" .text I assume that's not expected - so we need to determine why (i.e. if there really are two coming in or if we've recorded something incorrectly)
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 Dominique d'Humieres changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #21 from Dominique d'Humieres --- Note that the test gfortran.dg/char_result_17.f90 should be run only on target supporting LTO.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #20 from Dominique d'Humieres --- Created attachment 40303 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40303&action=edit Assembly for char_result_16 with -flto on darwin
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #19 from Paul Thomas --- Created attachment 40286 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40286&action=edit Failing testcases with -flto under Darwin The PR is fixed under Linux but gives a link error under Darwin with -flto. From Dominique's message to the list on 7th December: The tests gfortran.dg/char_result_16.f90 and gfortran.dg/char_result_17.f90 fail with lto1: error: two or more sections for .gnu.lto___get_PROC_names.3e3ee55b08747e7c lto1: internal compiler error: cannot read LTO decls from /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccEJosbA.o This may be darwin specific as the linker is more picky than the linux one. As soon as the cause is identified, the two attached testcases can be added to the testsuite. Cheers Paul
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #18 from Paul Thomas --- Author: pault Date: Fri Dec 9 11:55:27 2016 New Revision: 243478 URL: https://gcc.gnu.org/viewcvs?rev=243478&root=gcc&view=rev Log: 2016-12-09 Paul Thomas PR fortran/44265 * gfortran.h : Add fn_result_spec bitfield to gfc_symbol. * resolve.c (flag_fn_result_spec): New function. (resolve_fntype): Call it for character result lengths. * symbol.c (gfc_new_symbol): Set fn_result_spec to zero. * trans-decl.c (gfc_sym_mangled_identifier): Include the procedure name in the mangled name for symbols with the fn_result_spec bit set. (gfc_finish_var_decl): Mark the decls of these symbols appropriately for the case where the function is external. (gfc_get_symbol_decl): Mangle the name of these symbols. (gfc_create_module_variable): Allow them through the assert. (gfc_generate_function_code): Remove the assert before the initialization of sym->tlink because the frontend no longer uses this field. * trans-expr.c (gfc_map_intrinsic_function): Add a case to treat the LEN_TRIM intrinsic. (gfc_trans_string_copy): Deal with Wstringop-overflow warning that can occur with constant source lengths at -O3. 2016-12-09 Paul Thomas PR fortran/44265 * gfortran.dg/char_result_14.f90: New test. * gfortran.dg/char_result_15.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_result_14.f90 trunk/gcc/testsuite/gfortran.dg/char_result_15.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #17 from Dominique d'Humieres --- > However, for reasons that I cannot see at the moment, the len_trim > is not doing the trimming :-( Seems related to the problem I have reported in comment 8.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #16 from Paul Thomas --- Created attachment 38917 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38917&action=edit Further development of the patch This patch cures the problem described at the end of comment #1. The change in trans-expr.c does the job. However, for reasons that I cannot see at the moment, the len_trim is not doing the trimming :-( MODULE Fruits IMPLICIT NONE ! PRIVATE ! PUBLIC :: Get CONTAINS subroutine fruity3 print *, get(4) end FUNCTION Get(i) RESULT(s) CHARACTER(*), PARAMETER :: names(4) = [ & 'Apple ', & 'Orange ', & 'Mango ', & 'Pear ' ]; INTEGER, INTENT(IN) :: i CHARACTER(LEN_trim(names(i))) :: s ! s = names(i) print *, len(s) END FUNCTION Get subroutine fruity2 print *, get(3) end END MODULE Fruits PROGRAM WheresThatbLinkingConstantGone USE Fruits IMPLICIT NONE ! WRITE (*, "('Eat the tasty ',A)") Get(1) call fruity call fruity2 call fruity3 contains subroutine fruity print *, get(2) end END PROGRAM WheresThatbLinkingConstantGone outputs Eat the tasty5 Apple 6 Orange 5 Mangoe 4 Pearoe I am sure that the problem is now trivial... A task for tomorrow. Paul
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #15 from paul.richard.thomas at gmail dot com --- Dear Ian, Aaah, OK. I was rather impressed by what you had done with the first bug :-) For some reason, one of the symbols is not being committed. I will try and figure out why. Cheers Paul On 18 June 2016 at 17:28, ian_harvey at bigpond dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 > > --- Comment #14 from Ian Harvey --- > I wouldn't know where to start with respect to the internal compiler error. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #14 from Ian Harvey --- I wouldn't know where to start with respect to the internal compiler error.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #13 from Dominique d'Humieres --- Created attachment 38722 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38722&action=edit Test case Test case I have prepared for this PR before I saw the problem reported in comment 8. The test succeeds with the new patch in comment 9.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #12 from Paul Thomas --- (In reply to Ian Harvey from comment #10) > The patch discussed in #5 applies changes to the wrong location in > trans-decl.c. Corrected patch attached. > > With this latest patch I see no variation in check-fortran test results. Dear Ian, I agree. However, the remaining bug in comment #1 is still there. Do you feel up to trying to fix it? Best regards Paul
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #11 from Paul Thomas --- (In reply to Ian Harvey from comment #10) > The patch discussed in #5 applies changes to the wrong location in > trans-decl.c. Corrected patch attached. > > With this latest patch I see no variation in check-fortran test results. Dear Ian, I was looking to make the same change. I'll apply your patch this afternoon and will check that it deals with the corner cases. Cheers Paul
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #10 from Ian Harvey --- The patch discussed in #5 applies changes to the wrong location in trans-decl.c. Corrected patch attached. With this latest patch I see no variation in check-fortran test results.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #9 from Ian Harvey --- Created attachment 38708 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38708&action=edit Updated patch against r23740
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #8 from Dominique d'Humieres --- While trying to package the patch in comment 5, I stumbled on the following problem in 32 mode: the following code MODULE Fruits IMPLICIT NONE PRIVATE PUBLIC :: Get CONTAINS FUNCTION Get(i) RESULT(s) CHARACTER(len=7), PARAMETER :: names(3) = [ & 'Apple ', & 'Orange ', & 'Mango ' ]; INTEGER, INTENT(IN) :: i CHARACTER(LEN_TRIM(names(i))) :: s ! s = names(i) print *, len(s) END FUNCTION Get END MODULE Fruits PROGRAM WheresThatbLinkingConstantGone USE Fruits IMPLICIT NONE integer :: i i = len(Get(1)) print *, i END PROGRAM WheresThatbLinkingConstantGone outputs at run time 5 5 when compiled with -m64, but 5 7 when compiled with -m32 (x86_64-apple-darwin15). The function Get(i) works as expected when used as a contained proc or through an interface.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #7 from Vittorio Zecca --- Still in 5.3.0
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #6 from Dominique d'Humieres --- > Variant: If one adds a > subroutine test() > print *, get(1) > end subroutine test > in the module itself, one gets an ICE: > > foo.f90:18:0: internal compiler error: in gfc_generate_function_code, > at fortran/trans-decl.c:4378 The ICE is still there with the patch. It is at the same location as for the test in comment 2 of pr44348 and the one in pr66494.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 Dominique d'Humieres changed: What|Removed |Added Attachment #22202|0 |1 is obsolete|| --- Comment #5 from Dominique d'Humieres --- Created attachment 3 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3&action=edit Updated patch I have updated the patch on revision r229946. I have a regression for gfortran.dg/pr65045.f90. Without the patch the errors are ... /opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90:11:6: end if! { dg-error "Expecting END BLOCK statement" } 1 Error: Expecting END BLOCK statement at (1) /opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90:13:8: print*,i ! { dg-error "not appropriate for an expression" } 1 Error: Symbol 'i' at (1) is not appropriate for an expression With the patch I have two more errors /opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90:11:6: end if! { dg-error "Expecting END BLOCK statement" } 1 Error: Expecting END BLOCK statement at (1) /opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90:12:3: end block i 1 Error: Expecting END PROGRAM statement at (1) /opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90:13:8: print*,i ! { dg-error "not appropriate for an expression" } 1 Error: Symbol at (1) is not appropriate for an expression f951: Error: Unexpected end of file in '/opt/gcc/p_work/gcc/testsuite/gfortran.dg/pr65045.f90' I don't understand why the patch changes the errors, but the test can be easily adjusted.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 Dominique d'Humieres changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #4 from Dominique d'Humieres --- *** Bug 50406 has been marked as a duplicate of this bug. ***
[Bug fortran/44265] Link error with reference to parameter array in specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #3 from Ian Harvey 2010-10-29 23:32:29 UTC --- (In reply to comment #2) > Created attachment 22202 [details] > Possible patch for PR44265 Apologies - I wrote several paragraphs of reasonably coherent explanation, but it got lost when I added the attachment. The attached set of patches introduces a new flag for gfc_symbol that is used to indicate when an entity is referenced in a specification expression for a function result; testing of that condition for module procedure local entities and setting of the flag in resolve.c; and changes to the assembly associated with the entity such that the object code for calling procedures in other program units can reference the entity. The test for the need to export the entity is probably too inclusive. The assembly name for the entity is of the form __modname_MOD__procname_PROC_entityname. Note that ->module for a gfc_symbol for a module procedure entity can either be NULL (when the hosting module is being compiled) or a zero length string (when a program unit that USE's the module is being compiled). I am not sure whether that is by design or accident - I have assumed by design. Perhaps Tobias had alternative approaches in mind but I am not familiar enough with the gfortran sources to know what he was talking about. This does not fix the failed assertion around a non-null ->tlink when a subroutine has an argument whose length uses such a specification expression.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #2 from Ian Harvey 2010-10-29 23:20:42 UTC --- Created attachment 22202 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22202 Possible patch for PR44265
[Bug fortran/44265] Link error with reference to parameter array in specification expression
--- Comment #1 from burnus at gcc dot gnu dot org 2010-05-25 09:50 --- CONFIRM (No regression: GCC 4.1/4.2/4.3 reject the code ["names" invalid in expression] while 4.4/4.5/4.6 show either the link error or ICE. Other compilers simply work.) One has the local parameter: CHARACTER(*), PARAMETER :: names(3) = ... And the characteristics of the result variable INTEGER, INTENT(IN) :: i CHARACTER(LEN_TRIM(names(i))) :: s which depend on the argument. (While "len(names(i))" is constant, "len_trim(names(i))" is not.) Thus, I see two possibilities: Mark the return length (in .MOD) as unknown (which g95 and NAG f95 seemingly do) - or to properly handle the PARAMETER. Looking at gfortran's .mod file, one finds: 4 'names' '' 'names' 6 ((PARAMETER UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN ... Thus, the symbol is already saved. * * * Variant: If one adds a subroutine test() print *, get(1) end subroutine test in the module itself, one gets an ICE: foo.f90:18:0: internal compiler error: in gfc_generate_function_code, at fortran/trans-decl.c:4378 -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code, rejects- ||valid Last reconfirmed|-00-00 00:00:00 |2010-05-25 09:50:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265