Todo List

Class Sg_File_Info: isOutputInCodeGeneration() is orthogonal to isCompilerGenerated and isTransformation(). Currently IR nodes that are marked as isTransformation() are output, but these need to be marked as also being isOutputInCodeGeneration() so that orthogonality of the concepts is maintained.

Class Sg_File_Info: It is possible to call get_file_info() on a SgFileInfo object and this needs to be fixed because it does not make any sense. This is because get_file_info is defined as a virtual function on SgNode. Not sure this is a great design, but maybe it just needs a local implementation of a private get_file_info() member function so that it can't be called (can be hidden).

Class Sg_File_Info: Should there be a simpler way to copy a SgFileInfo object than: "new Sg_File_Info(*fileInfo);" or "fileInfo->copy();"; likely not!

Class Sg_File_Info

Define the subset of IR nodes which would all have:

Sg_File_Info
AstAttributeMechanism
SgNode (parent pointer)
This will make the documentation more intuative. The argument supporting this is that we operate on those IR nodes that correspond to the visual representation of the source code (so we can exclude SgSymbols, and SgTypes). Having the same subset of IR nodes permits a simpler documentation of the API and intuition as to where it applies. A likely subset would be:
SgLocatedNodes
SgFile
SgDirectory (questionable)
SgInitializedName
SgBaseClass
SgTemplateArgument
SgTemplateParameter

Class Sg_File_Info: Remove the functions: isCompilerGeneratedNodeToBeUnparsed(), setCompilerGeneratedNodeToBeUnparsed(), and unsetCompilerGeneratedNodeToBeUnparsed() from where they are called.

Class Sg_File_Info

Consider putting the endOfConstruct information into the single Sg_File_Info object. Currently the SgLocatedNode stores two Sg_File_Info objects, one for the beginning and the end of each construct. This would save significant space in the AST. Additional information in the Sg_File_Info could be:

offset from starting line number to the end of construct
flag for if end of construct is located in the same file as the start of construct

Class Sg_File_Info: Consider using "short int" instead of "int" for the file_id, line, and col (and maybe the classificationBitField) to reduce the size of the data structure. Padding is not a significant issue since data structures are allocated in contiguious memory (except for padding to at least the nearest byte if bit field widths are used.

Member Sg_File_Info::hasPositionInSource () const: figure out what this does, it appears to be called in two places (attachment of comments and CPP directives (attachPreprocessingInfo.C) and marking template specializations for output (markTemplateSpecializationsForOutput.C)).

Class SgAsmStmt: This should not be a SgDeclaration (should be a regular SgStatement). Where "asm" is used in declarations (e.g. "int x asm("ax") = 0;") this is a SgVariableDeclaration. A asm statment is really just another kind of statement (e.g "asm ("template",output operand, input operand);"). This sort of statement is not a declaration (as I understand it). This will be fixed in a later release.

Class SgAssignInitializer: Double check the accuracy of this description.

Class SgBoolValExp: The name "SgBoolValExp" should be "SgBoolVal" to be consistant with the names of all other classes derived from SgValueExp.

Class SgClassNameRefExp: Need to figure out some examples of whare this is used.

Member SgConstructorInitializer::p_associated_class_unknown: Enforce p_declaration is valid pointer when p_associated_class_unknown is false within AST consistency tests.

Class SgDeclarationStatement

Current issues to look at:

Current classes derived from SgDeclarationStatement and the SgInitializedName class have ways of generating names, qualified names, and mangled names, but we lack a uniform mechanism to generate mangled qualified names. The implementation is not uniform within the IR and this is a problem for applications which must generate unique names for C++ constructs. Specific to functions names:
- We have:
  1. get_name()
  2. get_qualified_name()
  3. get_mangled_name()
- While we need (on ALL SgDeclarationStatement IR nodes):
  1. get_name()
  2. get_qualified_name()
  3. get_mangled_name()
  4. get_qualified_mangled_name()

Class SgDeleteExp: I believe we can associate the destructors from the class with delete operators.

Member SgDeleteExp::p_need_global_specifier: Check if this bool data member is used and/or required.

Class SgDirectory: Consider adding a SgFileInfo data member to be uniform with SgFile.

Class SgDoubleVal: Add string to this class so that the exact value can be held in the AST.

Class SgDoWhileStmt: The conditional test should be an expression (different from a SgWhileStmt), see test2005_114.C for examples and details.

Member SgDoWhileStmt::p_condition: This should be changed to be a SgExpression (to follow the C++ standard). We also have the condition specified before the body within the ROSETTA specification and this causes the traversal to travers the condition and body in the wrong order (for do-while, the traversal should be body forst and condition second). See test2005_114.C for more details and example code (example of strange loops).

Class SgExpression: Consider placing the VARARGS expression nodes into a common base class derived from SgExpression.

Class SgExpression: I have removed the access functions from the explicit storage of type information in SgExpression objects as phase 1 of a 2 phase approach to eliminate the storage of the type in the SgExpression IR nodes. This type should be computed where required. This would avoid it being held redundently. This mechanism is being redone internally. Some IR nodes will have likely have to store there type explicaitly (function expressions for example, though it might be better computed through the symbol). It is not clear it this computing of the type will be better than stroing of the type explicitly. It might be required for SgBinaryOp IR nodes to store the type if it is not clearly from either the lhs or rhs (if no simple rule exists).

Class SgExpression: SgScopeOp is deprecated and will be removed in a future version of ROSE. It is a hold over from support for CC++ which is not supported in SAGE III anymore.

Class SgExpression: SgRefExp is deprecated and will be removed in a future version of ROSE. It is not used anywhere within SAGE III and I don't know why it is there.

Class SgExpression: Need to find an example of where SgClassNameRefExp is used. It is build in the EDG/Sage III translation, but not in a way that it is obvious that it is still used within Sage III. So this may have to be removed at a latr date.

Class SgExpression: To support Fortran parser we need an IR node which will represent the ambiguity of an array access or function call expression. These are then resolved within the AST after parsing (requires AST Fixup rule).

Class SgExpression: Fortran support requires support for function call using: "foo(temp=*<label>)" this might force the development of a label expression to support this. Code using this compiles with gfortran, so it appears to be F90.

Class SgExprListExp: Consider that get_type() returns a SgDefalutType and should return the SgType associated with the last expression in the list.

Class SgFile: The ROSEAttributesListContainerPtr p_preprocessorDirectivesAndCommentsList should be implemented a list instead of a pointer to a list. This might require a list copy in the internal hand,ing, but would simplify the design and there is not the same memory constraint of having a pointer to a list vs. a list here because the list is almost always valid (most source code incluses at least one comment or CPP directive) and there is only one SgFile object per source file (so there are relatively few SgFile nodes in even a very large AST).

Class SgFile: This IR nodes now has a Sg_File_Info pointer, however it needs to be made consistant with the filename that is returned from SgFile::get_fileName().

Class SgFile: The default constructor for SgFile sets the SgGlobal pointer to NULL and perhaps it would be better if it set it to a valid SgGlobal object then we would have a better defined empty list of declarations.

Class SgFile: Yarden has suggested we provide a way to modify the link line that would be generated to support the backend compilation. I think we should have a list of strings that could be added to the link line (appended to the end would be the simplist). Else we need a virtual function that could be overloaded to customize the control over the link command generation (however we want to discourage the derivation of user defined IR nodes from existing IR nodes since this would break some of the internal mechanisms that use the memory pools).

Class SgFloatVal: Add string to this class so that the exact value can be held in the AST.

Class SgForInitStatement: Evaluate if this should be derived from SgSupport, like other "list" based IR nodes.

Class SgForInitStatement: Evaluate if we should even have this IR node. If the SgVariableDeclaration were to be fixed to really use the list of SgInitializedName objects where multiple variables are declared in the same variable declaration then we might not need this (I think). And if it didn't exist it would make the use of the SgForStatement a little bit simpler.

Class SgForStatement: The conditional in this test is currently an expression, but should be a SgConditional or a SgStatement (e.g. so that it can be a variable declaration).

Class SgForStatement: Now that the test is a SgStatement, perhaps the name of the field should be "test" instead of "test_expr".

Class SgFunctionDeclaration: Need to mark function declarations appearing in the file rose_edg_required_macros_and_functions.h as compiler generated since they are either builtin functions for gcc and g++ or those those builtin function that gcc and g++ required and which EDG fails to include as builtin when compiling with EDG's GNU_COMPATABILITY_MODE (current default for ROSE).

Class SgFunctionDeclaration: Need to better handle fiend injection rules, currently the SgFunctionSymbol for a friend function is placed into the global scope. It likely should be the outer scope for a non-defining declaration and the class scope for a defining declaration. But the exact rules for this are more complex. So the location of the SgFunctionSymbol in the symbol table of SgGlobal is a poor approximation.

Class SgFunctionParameterList: Check scopes of variables in function parameter list, should point to function definition, if the function definition exists, else they are undefined. If they are undefined then we still have to have something for them to point to, we could propose that this be the scope of the function declaration (I think this is what is done). The test in the tutorial tests this and it seems to be correct.

Class SgFunctionParameterList: Not clear if this should be a declaration statement (might make more sense derived from SgSupport, or perhaps from SgLocatedNode (with other IR nodes that are currently derived from SgSupport, see SgLocatedNode for details).

Class SgFunctionParameterList: If this should be a SgDeclarationStatement (and there is a reasonable argument for this) then perhaps the declaration containing any default parameters should be the defining declaration, independent of the defining declaration of the associated function declaration.

Class SgFunctionRefExp: Figure out why SgMemberFunctionRefExp is required instead of just SgFunctionRefExp.

Class SgFunctionRefExp: Make the use of a SgMemberFunctionSymbol in a SgFunctionRefExp an error. The result will not unparse correctly (suggested by Jeremiah).

Class SgFunctionTypeTable: Evaluate if this should be derived from SgSupport (consistant with SgSymbolTable).

Class SgFunctionTypeTable: Evaluate if we might like to have the p_function_type_table be a SgSymbolTable rather than a pointer to a SgSymbolTable (see implementation note).

Class SgGlobal: Cleanup interface which presently has multiple append,prepend, insert functions. It might be best to eliminate them and use STL directly.

Class SgIfStmt: The unparse function "unparseIfStmt" associated with this IR node is implemented using a loop. I think this should be changed to be more conventional and structural (consistant with the design of the rest of the unparsing).

Class SgLabelStatement: Review if we want to have the label statement reference it's associated statement (it would be a redundent reference, since the next statement is already in the list of statements for the scope).

Class SgLocatedNode: The AstAttributeMechanism type should be handed as other IR nodes with it's own memory pool, except that in all cases where it would be used, it would be a base class to a user-defined derived type and thus would not fix in our memory pool.

Class SgLocatedNode: Consider name change of "SgLocatedNode" to "SgSourceNode".

Class SgLocatedNode

Consider moving some of the IR nodes currently in SgSupport to this IR node. IR nodes that might be moved would include:

Class SgLongDoubleVal: Add string to this class so that the exact value can be held in the AST.

Class SgModifierNodes: Fortran support for modifiers is required: see section 5.2, 5.3 in Fortran 2003 standard. Note that type modifiers can be used as statements.

Class SgName: Define a string conversion operator so that we can handle "SgName name; string s = name;" This would start the process of internally having SgName contain a C++ style string.

Class SgName: Change SgName to store a C++ style std::string, instead of a C style char*.

Class SgName: Some of the member functions defined in this class will be removed (head(), tail(), etc.) because they represent low level string handling which is best done on a C++ style string more directly using C++ string operators.

Class SgNamespaceDeclarationStatement: Consider having a function which could generate a list of all the SgNamespaceDeclarationStatement IR nodes that match the same namspace. This would make a good first project for a new student.

Class SgNamespaceDeclarationStatement: Include a graph to show how scopes are handled within the AST.

Class SgNamespaceDefinitionStatement: Cleanup interface which presently has multiple append,prepend, insert functions. It might be best to eliminate them and use STL directly.

Class SgNamespaceSymbol: It might be that we should have a SgNamespaceAliasSymbol so that namespace aliasing can be better supported. We can consider this for future work.

Class SgNewExp: Provide some examples to detail the difference between placement, constructor, and builtin arguments.

Class SgNewExp: I believe we can associate the constructors from the class with new operators.

Member SgNewExp::p_placement_args: Provide some examples to detail the difference between placement, constructor, and builtin arguments (these are rarely used in C++).

Member SgNewExp::p_constructor_args: Provide some examples to detail the difference between placement, constructor, and builtin arguments.

Member SgNewExp::p_builtin_args: Provide some examples to detail the difference between placement, constructor, and builtin arguments.

Class SgNode

The "AstAttributeMechanism attribute;" field should be fixed:

The attribute within this class is not added using ROSETTA and is one of the last (if not the last) variable to NOT be added to the IR nodes using ROSETTA. Because it is not added using ROSETTA, it is a special case (and we hate special cases) in the file I/O (by Jochen) and perhaps elsewhere. This variable should be added using ROSETTA!
Access functions need to be built for the "AstAttributeMechanism attribute;" field and it needs to be moved to be a private data member.
It should be moved to only those IR nodes were it makes sense, e.g. excluded from:
1. SgName
2. SgModifier (and all derived modifier IR nodes)
3. SgUnparse_Info
4. SgSymbolTable

Class SgNode: Consider eliminating the set_freepointer() function since only the internal memory allocation mechanisms should use it (and they are forced to access the data member directly since they traverse the memory pools directly and member function can onl be called on allocated object initialized vi the new operator (with a proper constructor call, so that the this pointer is set properly)). Perhaps we don't need access functions for this data member at all.

Member SgNode::unparseToCompleteString (): This function needs a better name since it is unclear what the "complete" string is.

Member SgNode::unparseToCompleteString (): This function needs a better name since it is unclear what the "complete" string is.

Member SgNode::unparseToCompleteString (): This function needs a better name since it is unclear what the "complete" string is.

Member SgNode::unparseToCompleteString (): This function needs a better name since it is unclear what the "complete" string is.

Class SgOptions: Review if we really want to keep this class.

Class SgProject: Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Class SgProject: Implement a "-dumpversion" for compatability with GNU (icc does the same).

Class SgRefExp: Double check this description.

Class SgReturnStmt: Check that when return (SgReturnStatement) is implicit, it should be marked as compiler generated. Actually we only include returns in the AST which are explicit, so this is not a problem.

Class SgScopeStatement

Where current derived IR nodes from SgScopeStatement contain SgBasicBlock objects, we should consider having them contain SgStatement objects instead of SgBasicBlock. This would avoid current normalizations which are cute, but perhaps unwelcome. We need to discuss and rule on this detail. An alternative would be to let there be a SgBasicBlock and mark it as compiler-generated if it does not appear in the original source code. then the unparser (code generator) could be made to avoid output of the SgBasicblock (and enforce that the number of statements in the block is not greater than one). Effected IR nodes include:

SgCatchOptionStmt (should contain SgStatement)
SgDoWhileStmt (should contain SgStatement)
SgForStatement (should contain SgStatement)
SgIfStmt (should contain true and false SgStatement)
SgSwitchStatement (should contain SgStatement)
SgWhileStmt (should contain SgStatement)
these are currently correct:
SgFunctionDefinition (should contain a SgBasicBlock)
SgGlobal (constains a list of declarations (SgDeclarationStatement objects))
SgNamespaceDefinitionStatement (constains a list of declarations (SgDeclarationStatement objects))
SgClassDefinition (constains a list of declarations (SgDeclarationStatement objects))

Class SgSizeOfOp: Need to implement support in EDG/SageIII translation for this operator.

Class SgStatement

There are a number of statements that contain a SgBasicBlock where they should contain a SgStatement. In each case changing the data member to be a SgStatement will unfortunately change the constructor parameter list and thus the ROSE API. So these changes have to be organized a a point where it is clear we will be changing some details of the ROSE API (prior to external release). Problem IR nodes are:

Class SgStatement: Fortran support for modifiers can be used as statement (must be added to IR): see section 5.2, 5.3 in Fortran 2003 standard. Note that type modifiers can be used as statements.

Class SgStatement: Fortran support requires statements in section 6.3.

Class SgStatement: Fortran support requires for "where" and "forall" statements.

Class SgStatement: Fortran support requires for case statement ranges (gnu extension for C, but standard in Fortran).

Class SgStatement: Fortran support requires statements in section 8.1.4, 8.1.5.

Class SgStatement: Fortran support requires statements in section 15 (modifiers for ISO_C_BINDING).

Class SgSwitchStatement: FIXED: The conditional test should be a SgStatement so that a declaration can be used, it is currently an SgExpression (specifically a SgExpressionRoot).

Class SgSwitchStatement: The body of the SgSwitch should really be a SgStatement not a SgBasicBlock. DuffsDevice can be modified to should an example of this but there are also much more trivial examples. See comment about this in the SgStatement todo list.

Class SgSymbol: Consider derivation of SgEnumSymbol, SgClassSymbol, and SgTypedefSymbol from a common SgTypeSymbol. Then supporting functions for SgTypeSymbol would lookup any of these type based symbols.

Class SgSymbolTable: The rose_hash_multimap should perhaps be included as a data member instead of implemented as a pointer. We should consider this detail.

Class SgSymbolTable: We should decide if we want to give Symbol Tables a name or not, it seems that we rarely if ever do this so perhaps we should not have such a field.

Member SgSymbolTable::p_no_name: generate a list of instances where symbols don't have names. (Namespaces don't have to have a name for example).

Class SgTemplateArgument: Move this be a SgLocatedNode since it should have a position in the source code.

Class SgTemplateDeclaration: Template declarations marked as friend don't seem to be marked as friend internally.

Class SgTemplateDeclaration: The scope of a SgTemplateDeclaration should be a SgTemplateInstantiationDefn, since it could be associated which more than one definition. What we need, and don't have yet, is a SgTemplateDefinition to accompany the SgTemplateDeclaration then a SgTemplateDeclaration could have a SgTemplateDefinition for a parent and or scope when it is a member function or namespace or global scope (typically), otherwise.

Class SgTemplateDeclaration: Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Member SgTemplateDeclaration::p_string: Check the accuracy of this statement in the unparser!

Class SgTemplateInstantiationDecl: Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Class SgTemplateInstantiationDirectiveStatement: Consider tranversing instantated templates instantiated by an explicit instanntatiation directive.

Class SgTemplateInstantiationFunctionDecl: Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Class SgTemplateInstantiationMemberFunctionDecl: Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Class SgThrowOp: Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Class SgThrowOp: Consider that get_type() returns a SgDefalutType and should return the SgType associated with the last expression in the list (research details of the list of pointers in the C++ throw operator).

Class SgType

Several classes derived from SgType are not used and can be removed:

SgTypeUnknown (Used by SageInterface to specify references to undeclared variables)
SgUnknownMemberFunctionType

Class SgType: The signed types (except for signed char) are not used in SAGE III and do not exist in C or C++. These IR nodes should be removed, specifically SgTypeSignedShort, SgTypeSignedInt, SgTypeSignedLong.

Class SgType: For Fortran support we need to add the kind, length data member to specify the width. To support handling of kind, length parameters we should use the information about the target backend compiler and map kind information to bit widths (not a high priority).

Class SgType: Labels appear to be used as types in "foo(*,*)", see example from Chris (LANL, 4/19/2007).

Class SgTypedefDeclaration

There are a few data members in this field that don't appear to be used (should be removed if not required):

p_declaration: have not seen it be used anywhere (I think it is used when a declartion is explicit in the typedef, check this out, might be part of older mechanism before defining and nondefining declarations were developed to provide a uniform mechanism for all declarations)
p_parent_scope: this is a SgSymbol, but I don't know why it is stored explicitly.

Member SgTypedefDeclaration::p_parent_scope: We can remove this.

Member SgTypedefSeq::p_typedefs: It might be better for this to be a list of SgTypedefTypes

Member SgTypedefSeq::p_typedefs: Think about if we could also store a reference to all pointers and reference types where they share a common base_type.

Member SgUnaryOp::p_expression_type: This value is only used for the SgCastExp, we will move it to that IR node when we are ready to change the interface for the SgExpressions (and SgUnaryExp IR nodes).

Class SgUsingDirectiveStatement: Explain difference between using declaration and using directive.

Class SgValueExp: We should add a SgComplexValue IR nodes for C99 support of complex constants. At the moment these are internally represented as SgFloatValue, SgDoubleValue, or SgLongDoubleValue IR nodes.

Class SgVariableDeclaration: Finish explaination of variable declaration, relationship to variable definition, and the scope issue.

Class SgVariableDeclaration: template static variable declaration are instantiated and this is at least sometimes an error (at least when not part of a transformation). See test2005_69.C for example of this problem.

Member SgVariableDeclaration::p_variableDeclarationContainsBaseTypeDefiningDeclaration: Provide an example of where p_variableDeclarationContainsBaseTypeDefiningDeclaration is true and where it is false.

Class SgVariableDefinition: If a SgVariableDefinition is built internally as part of a SgVariableDeclaration it should be marked as compiler generated if the "extern" keyword was not used in the SgVariableDeclaration. This needs to be looked into.

Class SgVariableDefinition: Constant folding happens when the bitfield is a variable and the variable name is lost. This IR nodes needs to be modified to alternatively store the associated SgExpression (in case it is a root of an expression tree).

Class SgVariableSymbol: Need to figure out if it is such a great idea of a single symbol to be in two scopes or if it would be better to use two different symbols (since there are two different SgInitializedName object built (the last one referencing the previous one through the p_prev_decl_item pointer)).

Class SgVariableSymbol: The get_type() function can return NULL when the get_definition() is NULL. I think we should have assertiosn to make sure that get_definition is a valid pointer and that get_type() should not return NULL.

Class SgVarRefExp

Test to verify that each variable reference is associated with the inner most scoped variable with that name, except where name qualified. Applies most easily to local variables. The same test could be used for function references, actually all references.

Make sure that declarations appear before variable references.

Class StringUtility: Finish documentation!

Class StringUtility: Finish documentation!

Class StringUtility: Finish documentation!

File graphProcessing.h: utilize BOOST visitors to take advantage of the BOOST graph structures abilities

Member mangleExpression: Find a better way to deal with general template expression arguments.

Member SageInterface::appendArg (SgFunctionParameterList *, SgInitializedName *): function type , function symbol also need attention.

Group frontendSageUtilityFunctions

A number of additional things to do:

Pull scope handling out of EDG/Sage III translation so that is is made available to anyone else building the Sage III IR from scratch (which when it gets non-trivial, involves the manipulation of scopes).
Other stuff ...

Group ROSE_ProgramTransformationGroup: Add Constant folding since we currently unfold all folded expressions in the code generation phase. This would be something that could be verified as well since it EDG has also computed the constant folded result and we have stored that explicitly as well as the expression tree from which it was folded. The proposed constant folding would also work on AST fragments constructed explicitly in ROSE from lower level mechanisms.

Group ROSE_ProgramTransformationGroup: The ROSE source code might be easier to organize if we have an include directory just for the included files from the transformations. Then use separate directories for the implementations (we want to always separate the implementation if possible from the header file and place it in a separate file. This would make it easier to add transformations and make the maintenance of the development tree a bit easier. As it is each new directory forces a new include path to be specified and a new library to be generated (in /config/Makefile.for.ROSE.includes.and.libs).

Group queryLib: 1. Finish documentation!
2. Make the source code directory structure for Query lib match the documentation.
3. Make the library more exstensible (perhaps designed like the PDF and DOT libraries).

Group localNodeQueryLib: Finish documentation!

Group subtreeQueryLib: Finish documentation!

Group DOTGenerationStuff: Finish documentation!

Group PDFGenerationStuff: Finish documentation!

Group transformationSupportLib: Fixup interfaces in Sage III using code from the TransformationSupport class.

Page ROSE AST Copy Mechanism: Most types are shared, but named types are copied, and the copies need to have there declarations reset to the new AST.

Page ROSE AST Copy Mechanism: base class modifiers are shared and this should be fixed.

Page ROSE AST Copy Mechanism: Friend function in classes are not represented by symbols in the global scope. Not that this is always the rule, it is the default for ROSE and it is setup inconsistantly in the generated AST copy. See copytest2007_39.C.

Page ROSE AST Copy Mechanism: copytest2007_46.C is too difficult to figure out (likely because the SgTemplateArguments are shared).

Page ROSE AST Copy Mechanism: copytest2007_47.C is too complex and likely demonstrates an error.

Page ROSE AST Copy Mechanism: copytest2007_49.C is too complex and likely demonstrates an error.

Generated on Tue Jan 31 05:32:52 2012 for ROSE by

1.4.7