March 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

Re: [Ad-dev] [openAD] #180: transformFile.py does not declare active type for implicitly typed variables
by OpenAD 23 Mar '11

23 Mar '11

#180: transformFile.py does not declare active type for implicitly typed variables ------------------------------+--------------------------------------------- Reporter: utke | Owner: hlcm Type: defect | Status: closed Priority: major | Milestone: AD for SAS Component: SourceProcessing | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Changes (by hlcm): * status: assigned => closed * resolution: => fixed Comment: Fixed to correctly identify and modify active variables from common blocks with http://mercurial.mcs.anl.gov/ad/SourceProcessing/rev/51832d50ac28 Fixed to add type declarations for active vars from common blocks/equivalences which are implicitly typed with http://mercurial.mcs.anl.gov/ad/SourceProcessing/rev/6fd06d8c0a20 -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/180#comment:5> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 0

[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] #274: front-end flips the order of the AND arguments
by OpenAD 18 Mar '11

18 Mar '11

#274: front-end flips the order of the AND arguments ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: Component: Open64 front end | Keywords: ------------------------------+--------------------------------------------- test case is andConditionOrder.f90 leads to a SEGV -- Ticket URL: <http://trac.mcs.anl.gov/projects/openAD/ticket/274> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 0