January 2012 - 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] #279: allocation of propagation variables is not done in the adjoint
by OpenAD 11 Jan '12

11 Jan '12

#279: allocation of propagation variables is not done in the adjoint -------------------------+-------------------------------------------------- Reporter: lyonsam | Owner: utke Type: defect | Status: new Priority: major | Milestone: Component: xaifBooster | Keywords: -------------------------+-------------------------------------------------- the allocation is mistakenly printed in the taping version -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/279> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 2

Re: [Ad-dev] [openAD] #104: xaif representation/unparsing of structure element access through an array yields wrong element
by OpenAD 06 Jan '12

06 Jan '12

#104: xaif representation/unparsing of structure element access through an array yields wrong element --------------------------+------------------------------------------------- Reporter: Utke | Owner: utke Type: defect | Status: accepted Priority: 3 | Milestone: Component: OpenADFortTK | Keywords: --------------------------+------------------------------------------------- Comment(by utke): underlying problem is the scalarized XAIF representation Can be fixed only in the Rose variant. -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/104#comment:4> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 0

[openAD] #281: non-inlinable intrinsices need to be isolated to a separate stetament each
by OpenAD 06 Jan '12

06 Jan '12

#281: non-inlinable intrinsices need to be isolated to a separate stetament each ------------------------------+--------------------------------------------- Reporter: utke | Owner: hlcm Type: enhancement | Status: new Priority: major | Milestone: Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- to apply the rules for a non-inlinable intrinsic I it has to be isolated to a sepaete statement y=I(x) where (x) must be a variable reference, not an expression involving other intrinsics. Test example see: Regression/testRoundTrip/examples/shapeReshape where shape () is not lifted as second argument of b = reshape(A,shape(b)) -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/281> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 0

Re: [Ad-dev] [openAD] #67: FR: handle non-inlinable intrinsics (deals with MIN/MAX/RESHAPE...)
by OpenAD 06 Jan '12

06 Jan '12

#67: FR: handle non-inlinable intrinsics (deals with MIN/MAX/RESHAPE...) ---------------------------+------------------------------------------------ Reporter: Utke | Owner: utke Type: enhancement | Status: accepted Priority: 3 | Milestone: Component: Miscellaneous | Resolution: Keywords: | ---------------------------+------------------------------------------------ Changes (by utke): * type: defect => enhancement -- Ticket URL: <http://trac.mcs.anl.gov/projects/openAD/ticket/67#comment:9> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 0

Re: [Ad-dev] [openAD] #67: FR: handle non-inlinable intrinsics (deals with MIN/MAX/RESHAPE...) (was: FR: handle non-inlinable intrinsics (deals with MIN/MAX))
by OpenAD 06 Jan '12

06 Jan '12

#67: FR: handle non-inlinable intrinsics (deals with MIN/MAX/RESHAPE...) ---------------------------+------------------------------------------------ Reporter: Utke | Owner: utke Type: defect | Status: accepted Priority: 3 | Milestone: Component: Miscellaneous | Resolution: Keywords: | ---------------------------+------------------------------------------------ -- Ticket URL: <http://trac.mcs.anl.gov/projects/openAD/ticket/67#comment:8> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 0