February 2011 - Ad-dev - mailman3.cels.anl.gov

[openAD] #200: introduce scope per CFG node
by OpenAD 18 Nov '14

18 Nov '14

#200: introduce scope per CFG node -------------------------+-------------------------------------------------- Reporter: utke | Owner: snarayan Type: enhancement | Status: new Priority: major | Milestone: Component: xaif | Keywords: -------------------------+-------------------------------------------------- for C++, with default scope being the same scope as the top level cfg scope for C/fortran -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/200> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 5

[openAD] #220: COMMON block symbol reference ambiguity in whirl
by OpenAD 22 Feb '13

22 Feb '13

#220: COMMON block symbol reference ambiguity in whirl --------------------------+------------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: Component: OpenADFortTk | Keywords: --------------------------+------------------------------------------------- for the following situation: subroutine foo () common /g/ v ... call bar() end subroutine subroutine bar() common /g/ v/ ... end subroutine the global whirl symbol table has 2 entries for 'v' (and also 'g'), one for each PU in which v is used. The association is done via the base ST of 'v' first to its corresponding 'g' and then that one's corresponding base symbol is either 'bar' or 'foo'. Normally the uses of the different incarnations do not overlap. However, the side effect analysis reports cumulative side effects in "foo" including sideeffects of 'bar' on bar's version of 'v' such that in foo now implicitly separate references occur (for checkpointing code) of both 'v' instance and that in turn leads to a duplication of the common block declaration in the unparser because there is no logic that can turn bar::v into the equivalent foo::v to avoid the bogus reference. This will have to be fixed either in OpenADFortTk or in whirl2f. -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/220> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 5

[openAD] #245: DATA stmt: allow (object , value) pairs to not be separated by comma
by OpenAD 18 Apr '11

18 Apr '11

#245: DATA stmt: allow (object , value) pairs to not be separated by comma ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: enhancement | Status: new Priority: major | Milestone: Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- for a complete implementation of the syntax spec (R532) which says the comma between the pairs is optional -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/245> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 4

[openAD] #233: parser fails on labeled do
by OpenAD 05 Apr '11

05 Apr '11

#233: parser fails on labeled do ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- test case is PrePost/TestSources/UnStruct_controlflow_loop4.free.f90 -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/233> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 1

[openAD] #213: postProcess.py needs to add value selector (and do nothing else) for original function definitions that have been turned into subroutines
by OpenAD 31 Mar '11

31 Mar '11

#213: postProcess.py needs to add value selector (and do nothing else) for original function definitions that have been turned into subroutines ------------------------------+--------------------------------------------- Reporter: lyonsam | Owner: utke Type: defect | Status: new Priority: major | Milestone: scale1 Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- The issue is this: you know how we have postprocess and transformfile? I have a situation where there's a function in centrm (in centrm/psget_I.f90) that gets subroutinized by the preprocessor, so that both the function and the new subroutine go through the tool. As is usually the case when we do this, the subroutine will have active statements whereas the function will not (because we've replaced all the function calls that we've seen with subroutine calls, so the function isn't used in an active context). So far so good. In this case, though, the function uses a module variable that happens to be active, like {{{ passive1 = active*passive2 }}} where we would need {{{ passive1 = active%v*passive2 }}} So here's what we need: for function units, the postprocessor should do exactly what transformfile does (like adding the %v whenever an active variable is referenced), and none of the stuff that the postprocessor does on non-function units. -- Ticket URL: <http://trac.mcs.anl.gov/projects/openAD/ticket/213> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 2

[openAD] #238: allow Brackets [] used for array constructor
by OpenAD 23 Mar '11

23 Mar '11

#238: allow Brackets [] used for array constructor ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/238> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 2

[openAD] #262: function2subroutine - incorrect hoisting of variables
by OpenAD 21 Mar '11

21 Mar '11

#262: function2subroutine - incorrect hoisting of variables ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: AD for SAS Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/262> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 7

[openAD] #254: fix up initialization flag for postprocessing so it doesn't require reverse mode
by OpenAD 21 Mar '11

21 Mar '11

#254: fix up initialization flag for postprocessing so it doesn't require reverse mode ---------------------------------+------------------------------------------ Reporter: utke | Owner: hcm Type: defect | Status: new Priority: major | Milestone: Component: multiple components | Keywords: ---------------------------------+------------------------------------------ The fix committed as http://mercurial.mcs.anl.gov/ad/RegressionOpenAD/rev/c7231724e2a4 works but I don't agree with what it does because the postprocessor options we accept shouldn't be restricted to adjoint and I don't understand why initialization would have to be tied to reverse mode. IOW - I think rather than changing the test script I would instead permit the post processor to do the initialization bits. A subsequent question that was still to be verified was if there could be cases where initialization of local variables was also needed in forward mode. so http://mercurial.mcs.anl.gov/ad/RegressionOpenAD/rev/c7231724e2a4 should be undone and replaced by a fix in SourceProcessing -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/254> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 2

[openAD] #269: make CrossCountryInterface self-contained and move to angel
by OpenAD 24 Feb '11

24 Feb '11

#269: make CrossCountryInterface self-contained and move to angel -------------------------+-------------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: Component: xaifBooster | Keywords: -------------------------+-------------------------------------------------- this should clear up the mutual dependency: angel build refers to xaifBooster header files and xaifBooster build refers to libangel.a -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/269> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 0

[openAD] #268: OA: missing active variables
by OpenAD 11 Feb '11

11 Feb '11

#268: OA: missing active variables --------------------------------------+------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: Component: OpenAnalyis (old branch) | Keywords: --------------------------------------+------------------------------------- Attached are two pieces of code whose traversal order through the data dependencies triggers a different outcome based on how deep in the recursion the condition: --- // Actual or formal parameters without any outgoing edges shouldn't be // activated. if (nonParentSuccessors == 0 && !isVariedBefore && !isSelfDependent() && ( parenEType == CALL_EDGE || parenEType == RETURN_EDGE) && !mDUG->isDependent(getProc(), getSym()) ) { unsetVaried(); --- is tested and subsequently "unsetVaried" is called. The trace for the good case has the traversal for fooout along the return edge deeper in the recursion, see : markVaried 8 entering for FOO::FOOOUT -v->"p_(43)\nPOUT"->"FOO(45)\nFOOOUT"[label="C(47915221307392)\np_\n-> FOO", style=dashed]; and later unsetVaried:FOO::FOOOUT unsetVaried("FOO(45)\nFOOOUT") <- markVaried 8 leaving for FOO::FOOOUT in the attached trace_ok.txt so that the :"unsetVaried" happens there but is undone later in the traversal, see: markVaried 5 entering for FOO::FOOOUT -v->"FOO(44)\nFOOIN"->"FOO(45)\nFOOOUT"[label="F\nFOO"]; <- markVaried 5 leaving for FOO::FOOOUT =========================== For the "fail" case all I changed was the assignment order before the call to trigger the recursion to FIRST go down the path from POUT to FOOUT instead of PIN->FOOIN->FOOUT.... (see trace_fail.txt) markVaried 4 entering for FOO::FOOOUT -v->"p_(42)\nPOUT"->"FOO(45)\nFOOOUT"[label="C(47437752258560)\np_\n-> FOO", style=dashed]; and the upon unwinding the recursion: unsetVaried:FOO::FOOOUT unsetVaried("FOO(45)\nFOOOUT") <- markVaried 4 leaving for FOO::FOOOUT and after that nothing else comes about to fix it and FOOUT remains "not varied". -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/268> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 2