[openAD] #224: open64 does not distinguish 1st and 2nd nesting level of SRs
#224: open64 does not distinguish 1st and 2nd nesting level of SRs ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: Component: Open64 front end | Keywords: ------------------------------+--------------------------------------------- Open64 parser does not mark up bar as being nested in foo for module m contains subroutine foo () .... contains subroutine bar() .... -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/224> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components
#224: open64 does not distinguish 1st and 2nd nesting level of SRs ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: accepted Priority: major | Milestone: Component: Open64 front end | Keywords: ------------------------------+--------------------------------------------- Changes (by utke): * status: new => accepted -- Ticket URL: <http://trac.mcs.anl.gov/projects/openAD/ticket/224#comment:1> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components
#224: open64 does not distinguish 1st and 2nd nesting level of SRs ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: accepted Priority: major | Milestone: Component: Open64 front end | Keywords: ------------------------------+--------------------------------------------- Comment(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. -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/224#comment:2> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components
#224: open64 does not distinguish 1st and 2nd nesting level of SRs ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: accepted Priority: major | Milestone: Component: Open64 front end | Keywords: ------------------------------+--------------------------------------------- Comment(by utke): illustration provided in attached files -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/224#comment:3> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components
#224: open64 does not distinguish 1st and 2nd nesting level of SRs ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: accepted Priority: major | Milestone: Component: Open64 front end | Keywords: ------------------------------+--------------------------------------------- Comment(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 -- Ticket URL: <http://trac.mcs.anl.gov/projects/openAD/ticket/224#comment:4> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components
#224: open64 does not distinguish 1st and 2nd nesting level of SRs ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: accepted Priority: major | Milestone: scale1 Component: Open64 front end | Keywords: ------------------------------+--------------------------------------------- Changes (by utke): * milestone: => scale1 Comment: Replying to [comment:4 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
-- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/224#comment:5> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components
#224: open64 does not distinguish 1st and 2nd nesting level of SRs ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: accepted Priority: major | Milestone: scale1 Component: Open64 front end | Keywords: ------------------------------+--------------------------------------------- Comment(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 -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/224#comment:6> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components
#224: open64 does not distinguish 1st and 2nd nesting level of SRs ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: accepted Priority: major | Milestone: scale1 Component: Open64 front end | Keywords: ------------------------------+--------------------------------------------- Comment(by utke): see also #9 -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/224#comment:7> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components
participants (1)
-
OpenAD