Ticket #224 (accepted defect)

Opened 4 years ago

Last modified 4 years ago

open64 does not distinguish 1st and 2nd nesting level of SRs

Reported by: utke Owned by: utke
Priority: major Milestone: scale1
Component: Open64 front end Keywords:
Cc: mcgovej@…

Description

Open64 parser does not mark up bar as being nested in foo for
module m

contains

subroutine foo ()

....
contains

subroutine bar()

....

Attachments

nesting.f90 Download (351 bytes) - added by utke 4 years ago.
source
nesting.w2f.f Download (1.3 KB) - added by utke 4 years ago.
plain whirl2f output
nesting.sxp Download (17.4 KB) - added by utke 4 years ago.
s-expression
nesting.Modif.sxp Download (17.5 KB) - added by utke 4 years ago.
manually modified s-expression
nesting.Modif.s2w.w2f.f Download (1.3 KB) - added by utke 4 years ago.
whirl2f output based on manually modified s-expression

Change History

  Changed 4 years ago by utke

  • status changed from new to accepted

  Changed 4 years ago by utke

There are various parts to this problem. In whirl it appears that at least:
1. the flag in the pu_table that indicates foo has a nested routine is not set; should be:
<pre>

(2 (ty ".proc." 29 1) 3 0 (flg "PU_F90_LANG") 0 (flg "PU_NEED_UNPARSED,PU_UPLEVEL,PU_IS_NESTED_FUNC,PU_IS_INLINE_FUNCTION"))

</pre>
but is only
<pre>

(2 (ty ".proc." 29 1) 3 0 (flg "PU_F90_LANG") 0 (flg "PU_NEED_UNPARSED,PU_IS_NESTED_FUNC,PU_IS_INLINE_FUNCTION"))

</pre>

2. The whirl nodes are out of order, i.e. bar is listed before foo. If we switch it and adjust the flags the output is almost correct except that foo & bar are closed with only one END statetement which is likely a problem specific to whirl2f and has nothing to do with the whirl
representation.

Changed 4 years ago by utke

source

Changed 4 years ago by utke

plain whirl2f output

Changed 4 years ago by utke

s-expression

Changed 4 years ago by utke

manually modified s-expression

Changed 4 years ago by utke

whirl2f output based on manually modified s-expression

  Changed 4 years ago by utke

illustration provided in attached files

follow-up: ↓ 5   Changed 4 years ago by utke

The following test case illustrate the symptoms further:
OpenADFortTk/Regression/TestSources/sideEffectNested2.f90
(the deepest level routine is elevated but that makes the used variable out-of scope -> compiler error)

xand
OpenADFortTk/Regression/TestSources/sideEffectNested4.f90
The example compiles and produces the correct output but the XAIF representation is incorrect in the side effiect lists of foo2

<xaif:SideEffectReference vertex_id="1">

<xaif:SymbolReference vertex_id="1" scope_id="5" symbol_id="L_X_1"/>

</xaif:SideEffectReference>

Where the scope_id=5 is clearly wrong

in reply to: ↑ 4   Changed 4 years ago by utke

  • milestone set to scale1

Replying to utke:

The following test case illustrate the symptoms further:
OpenADFortTk/Regression/TestSources/sideEffectNested2.f90
(the deepest level routine is elevated but that makes the used variable out-of scope -> compiler error)

xand
OpenADFortTk/Regression/TestSources/sideEffectNested4.f90
The example compiles and produces the correct output but the XAIF representation is incorrect in the side effiect lists of foo2

This last part is fixed by  http://mercurial.mcs.anl.gov/ad/OpenADFortTk/rev/f4acb6925a14

<xaif:SideEffectReference vertex_id="1">
<xaif:SymbolReference vertex_id="1" scope_id="5" symbol_id="L_X_1"/>
</xaif:SideEffectReference>

Where the scope_id=5 is clearly wrong

  Changed 4 years ago by utke

Note that in the attached example the local variables of foo are elevated to module variables in the output while the formal parameter is not.

==========
WORKAROUND
==========
So a possibe workaround is to at least pass to bar the same parameters that foo accepts and the output is semantically correct (although the syntax problem with potential
name clashes is not solved)
The solution is illustrated in
Open64/osprey1.0/tests/TestSources/nesting_workaround.f90

It illustrates the name clash between the foo's local variable i that is being elevated to a module variable and the program's p which then conflicts with the new module variable i so we have to add the only qualifier to solve the clash

  Changed 4 years ago by utke

see also #9

Note: See TracTickets for help on using tickets.