[Bug fortran/44265] Link error with reference to parameter array in specification expression

[dominiq at lps dot ens.fr]

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

[marxin at gcc dot gnu.org]

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

[zeccav at gmail dot com]

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

[iains at gcc dot gnu.org]

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

[iains at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

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

[dominiq at lps dot ens.fr]

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=edit
Assembly for char_result_16 with -flto on darwin

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[pault at gcc dot gnu.org]

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=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

[pault at gcc dot gnu.org]

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=gcc=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

[dominiq at lps dot ens.fr]

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

[pault at gcc dot gnu.org]

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=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

[paul.richard.thomas at gmail dot com]

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

[ian_harvey at bigpond dot com]

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

[dominiq at lps dot ens.fr]

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=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

[pault at gcc dot gnu.org]

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

[pault at gcc dot gnu.org]

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

[ian_harvey at bigpond dot com]

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

[ian_harvey at bigpond dot com]

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=edit
Updated patch against r23740

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[dominiq at lps dot ens.fr]

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

[zeccav at gmail dot com]

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

[dominiq at lps dot ens.fr]

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

[dominiq at lps dot ens.fr]

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=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

[dominiq at lps dot ens.fr]

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

[ian_harvey at bigpond dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265

--- Comment #2 from Ian Harvey ian_harvey at bigpond dot com 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

[ian_harvey at bigpond dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265

--- Comment #3 from Ian Harvey ian_harvey at bigpond dot com 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

[burnus at gcc dot gnu dot org]

--- 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