Recent changes to bugs

Building ofp 0.8.3 from source

Michael Pfeiffer — Mon, 14 Dec 2015 09:59:47 -0000

In order to extend ofp, I need to build ofp from source.
Using my own build of ofp, using original 0.8.3 source code of ofp,
I get a parsing error for the file test.f (see attachment):

test.f line 9:11 missing T_DIGIT_STRING at '4'
test.f line 9:15 no viable alternative at input 'tempVar'

There is no error using the ofp 0.8.3 jar file that can be downloaded
from SF project site.

My build environment:
- Linux Mint 17.2 Rafaela
- java version "1.7.0_85"
OpenJDK Runtime Environment (IcedTea 2.6.1) (7u85-2.6.1-5ubuntu0.14.04.1)
OpenJDK Client VM (build 24.85-b03, mixed mode, sharing)
- antlr-3.4-complete-no-antlrv2.jar.

Is this the correct version of ANTLR?

Any help would be appreciated, how to build ofp 0.8.3 from source
producing the same jar file that can be downloaded from your
SF project site.

Kind Regards
Michael

DI Michael Pfeiffer
Industrial Researcher
SAE
Software Competence Center Hagenberg GmbH
Softwarepark 21, A-4232Hagenberg, Austria
UID: ATU 48056909 - FN: 184145b, Landesgericht Linz
Tel. +43 7236 3343-893
Fax +43 7236 3343-888
mailto:michael.pfeiffer@scch.at
http://www.scch.at/

parser fails on statement function followed by variable decl

Jean Utke — Wed, 06 Mar 2013 23:40:50 -0000

for the attached code the parser fails with:
stmtFctn.f90 line 14:2 no viable alternative at input 'double'

Even though I know that statement functions are obsolescent,
this stems from an application. So I haven't made this up to
annoy people and break the parser :-)

parser fails on module named "ASSIGNMENT"

Jean Utke — Fri, 20 Apr 2012 15:59:12 -0000

output is:
RoseTests/Module> openFortranParser moduleNamedAssignment.f90
moduleNamedAssignment.f90 line 1:7 no viable alternative at input 'ASSIGNMENT'
moduleNamedAssignment.f90 line 12:1 no viable alternative at input 'call'

I updated the parser today to changeset: 77800e0f8f7f857585e2a5d24ea65707b544f3c1

Multiplication by negative number fails

rlander — Tue, 13 Dec 2011 17:35:47 -0000

A multiplication with a negative number which is not enclosed by round brackets fails to parse.
Tested with the latest version from git repository.

Example:

PROGRAM multiply_by_negative
INTEGER :: i
i = 1*-1
END PROGRAM

ROSE: program with only end statement fails

Craig E Rasmussen — Sun, 13 Nov 2011 01:07:25 -0000

This is an easy bug to reproduce as a program with only "end" fails.

regression test
----------------
end
----------------

Output from ROSE:

Assertion failed: (astScopeStack.front()->get_endOfConstruct()->get_line() != astScopeStack.front()->get_startOfConstruct()->get_line()), function c_action_end_program_stmt, file ../../../../rose-0.9.5a-16734/src/frontend/OpenFortranParser_SAGE_Connection/FortranParserActionROSE.C, line 16035.
Abort trap

Add Fortran 2008 keywords to prefix-spec rule

Craig E Rasmussen — Mon, 17 Oct 2011 21:24:05 -0000

prefix-spec was not updated for F2008 syntax. For example

impure subroutine bar
end subroutine

parser java exception on format string

Jean Utke — Fri, 23 Sep 2011 16:10:50 -0000

The attached example fails with:
> openFortranParser --verbose form1.f90
*******************************************
args[1]: form1.f90
R -2:start-of-file: filename=form1.f90 path=/sandbox/Argonne/hg/ForTests/OFP_tests/form1.f90
Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: 235
at java.lang.String.charAt(String.java:694)
at fortran.ofp.parser.java.FortranLexicalPrepass.getCharString(FortranLexicalPrepass.java:1477)
at fortran.ofp.parser.java.FortranLexicalPrepass.getCharStringEditDesc(FortranLexicalPrepass.java:1522)
at fortran.ofp.parser.java.FortranLexicalPrepass.parseFormatString(FortranLexicalPrepass.java:1539)
at fortran.ofp.parser.java.FortranLexicalPrepass.parseFormatString(FortranLexicalPrepass.java:1651)
at fortran.ofp.parser.java.FortranLexicalPrepass.fixupFormatStmt(FortranLexicalPrepass.java:1785)
at fortran.ofp.parser.java.FortranLexicalPrepass.matchIOStmt(FortranLexicalPrepass.java:1869)
at fortran.ofp.parser.java.FortranLexicalPrepass.matchLine(FortranLexicalPrepass.java:2517)
at fortran.ofp.parser.java.FortranLexicalPrepass.performPrepass(FortranLexicalPrepass.java:2774)
at fortran.ofp.FrontEnd.call(FrontEnd.java:339)
at fortran.ofp.FrontEnd.main(FrontEnd.java:299)

tested on:
commit b7386ffa41c941201ad75a5f51f17f8495fde33f
Author: rasmussn <rasmussn@y-128-165-148-117.lanl.gov>
Date: Wed Sep 14 16:47:21 2011 -0600

builds fail with GNU make v. 3.82

Jean Utke — Fri, 23 Sep 2011 12:55:24 -0000

For changeset b7386ffa41c941201ad75a5f51f17f8495fde33f

the make invocation fails with:
cd /sandbox/Argonne/git/fortran-parser/src/fortran/ofp; make
make[1]: Entering directory `/sandbox/Argonne/git/fortran-parser/src/fortran/ofp'
cd parser ; make
make[2]: Entering directory `/sandbox/Argonne/git/fortran-parser/src/fortran/ofp/parser'
cd java ; make
make[3]: Entering directory `/sandbox/Argonne/git/fortran-parser/src/fortran/ofp/parser/java'
Makefile:161: *** mixed implicit and normal rules. Stop.

The problem comes from the evaluation of the make variables in this Makefile in the following sequence:
....
DATE=`date "+20%y%m%d"`
...
ALT_JARFILE=OpenFortranParser-$(DATE).jar
....and line 161:
$(BUILDDIR)/$(ALT_JARFILE): $(CLASS_FILES)

and here DATE isn't evaluated (yet) when the error is reported. Instead I assume the "%" in tbe string is interpreted as a suffix start.
Hence the error message.
Resetting "DATE" to some other string constant makes the problem disappear.

ROSE: Error is assignment of character array

Craig E Rasmussen — Wed, 14 Sep 2011 22:41:08 -0000

ROSE spews extra output (and sometimes aborts) during a character by character array assignment, e.g.,

character(16) :: array(1)
do c = 1, 16
array(1)(c:c) = val_array(c)
end do

--------ROSE OUTPUT---------
resetSourcePosition: sourceLocatedNode = 0x1199e4230 = SgPntrArrRefExp = array_ref_of_array_ref_of_var_ref_of_array_at_expr_list_exp_integer_value_exp_1_at_subscript_exp_var_ref_of_c_var_ref_of_c_integer_value_exp_1
Inside of Sg_File_Info::display(get_filenameString() == NULL_FILE)
isTransformation = false
isCompilerGenerated = false
isOutputInCodeGeneration = true (output in code generator)
isShared = false
isFrontendSpecific = false
isSourcePositionUnavailableInFrontend = true (source position unavailable in frontend)
isCommentOrDirective = false
isToken = false
filename = NULL_FILE
line = 0 column = 0
resetSourcePosition: sourceLocatedNode = 0x1199ff750 = SgAssignOp = undefined_expression_name
Inside of Sg_File_Info::display(get_filenameString() == NULL_FILE)
isTransformation = false
isCompilerGenerated = false
isOutputInCodeGeneration = true (output in code generator)
isShared = false
isFrontendSpecific = false
isSourcePositionUnavailableInFrontend = true (source position unavailable in frontend)
isCommentOrDirective = false
isToken = false
filename = NULL_FILE
line = 0 column = 0
Error: (endOfConstruct == startOfConstruct) lastStatement->get_endOfConstruct()->get_line() = 0
Error: (endOfConstruct == startOfConstruct) astScopeStack.front()->get_endOfConstruct()->get_line() = 0
Assertion failed: (astScopeStack.front()->get_endOfConstruct()->get_line() != astScopeStack.front()->get_startOfConstruct()->get_line()), function c_action_block, file ../../../../rose-latest/src/frontend/OpenFortranParser_SAGE_Connection/FortranParserActionROSE.C, line 10127.
Abort trap

'character () function f' does not parse

Scott Warren — Tue, 23 Aug 2011 21:28:25 -0000

When a function is declared with an initial type of 'character*(*)', the parser gives the following error message:
no viable alternative at input 'f'
Such a declaration is legal -- see Fortran 90 Specification (N692) 5.1.1.5 rule R509, list item (3).

If the alternative syntax 'character(len=*)' is used, the function parses correctly.