August 2010 - 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] #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] #224: open64 does not distinguish 1st and 2nd nesting level of SRs
by OpenAD 12 Oct '10

12 Oct '10

#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

1 7

[openAD] #202: insufficient parsing of rewind statements
by OpenAD 09 Sep '10

09 Sep '10

#202: insufficient parsing of rewind statements ------------------------------+--------------------------------------------- Reporter: lyonsam | Owner: lyonsam Type: defect | Status: new Priority: minor | Milestone: Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- occuring in centrm/pxlib_read_M.f90 (we were able to get around this for now because we dont really need to transform this file): rewind ['(', 'linpxs', ')'] -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/202> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 4

[ADIC] #45: faulty expression translation xaif->sage
by ADIC 02 Sep '10

02 Sep '10

#45: faulty expression translation xaif->sage --------------------------+------------------------------------------------- Reporter: utke | Owner: norris Type: defect | Status: new Priority: major | Milestone: Component: XAIF parsing | Version: Keywords: | --------------------------+------------------------------------------------- For the Fortran branch at: /home/utke/HG_Branch/RoseFE/ADIC The backtranslation for a test example yields and incomplete expression for the partial derivative. The test file is attached. -- Ticket URL: <http://trac.mcs.anl.gov/projects/ADIC/ticket/45> ADIC <http://trac.mcs.anl.gov/projects/ADIC> ADIC: Automatic Differentiation for C and C++

1 4

[ADIC] #44: segv during reinterpret cast of SgNode instance address set from string in xaif
by ADIC 04 Aug '10

04 Aug '10

#44: segv during reinterpret cast of SgNode instance address set from string in xaif --------------------------+------------------------------------------------- Reporter: utke | Owner: norris Type: defect | Status: new Priority: major | Milestone: Component: XAIF parsing | Version: Keywords: | --------------------------+------------------------------------------------- This is placeholder to collect info about this problem. Symptom: Program received signal SIGSEGV, Segmentation fault. 0x00002aaab1f7192b in __dynamic_cast () from /usr/lib64/libstdc++.so.6 (gdb) where #0 0x00002aaab1f7192b in __dynamic_cast () from /usr/lib64/libstdc++.so.6 #1 0x00002aaaac2cf691 in isSgStatement(SgNode*) () from /sandbox/Argonne/Apps/rose_inst/lib/librose.so.0 #2 0x00000000005d8169 in adic::SgXAIF::DFSVisitor_XAIF2Sage::onStartElement ( this=0x7fffffffaff0, e=0x2aaae49187f0, empty=true) at ../ADIC/xaif/XAIFVisitors.cpp:296 #3 0x00000000005aee30 in adic::SgXAIF::DFSTraversal::visit ( this=0x7fffffffb9b0, e=0x2aaae49187f0) at ../ADIC/xaif/XAIFGraphTraversals.cpp:119 #4 0x00000000005af0aa in adic::SgXAIF::DFSTraversal::visit ( this=0x7fffffffb9b0, e=0x2aaae4665e60) at ../ADIC/xaif/XAIFGraphTraversals.cpp:136 #5 0x00000000005af4a4 in adic::SgXAIF::DFSTraversal::visit ( this=0x7fffffffb9b0, e=0x2aaae4744050) at ../ADIC/xaif/XAIFGraphTraversals.cpp:157 #6 0x00000000005af0aa in adic::SgXAIF::DFSTraversal::visit ( this=0x7fffffffb9b0, e=0x2aaae408a7e0) at ../ADIC/xaif/XAIFGraphTraversals.cpp:136 #7 0x00000000005af0aa in adic::SgXAIF::DFSTraversal::visit ( this=0x7fffffffb9b0, e=0x2aaae4081d10) at ../ADIC/xaif/XAIFGraphTraversals.cpp:136 #8 0x00000000005ae780 in adic::SgXAIF::DFSTraversal::traverse ( this=0x7fffffffb9b0, e=0x2aaae4081d10) at ../ADIC/xaif/XAIFGraphTraversals.cpp:56 #9 0x000000000060e6b7 in main (myargc=3, myargv=0x7fffffffd3c8) at ../ADIC/main/ADIC.cpp:492 (gdb) p staddr $1 = 18446744073243085568 (gdb) p stmtAddress $2 = "46913461308160" I run on 64 bit opensuse 11.2 with gcc 4.4.1 and have ROSE (pre-release beta version: 0.9.5a) --- using EDG C/C++ front-end version: edg-3.3 --- using OFP Fortran parser version: ofp-0.7.2 and rose svn revision: 779 -- Ticket URL: <http://trac.mcs.anl.gov/projects/ADIC/ticket/44> ADIC <http://trac.mcs.anl.gov/projects/ADIC> ADIC: Automatic Differentiation for C and C++

1 4