The check for whether a private component is accessible was depending on
determining whether the source range of the current scope was within the
source range of the module that the component was declared in. This
could fail if the current scope was of kind `ImpliedDos` and had no
source range.
The fix is to add `Scope::Contains` to check the relationship by
traversing the parent links. These are created when the Scope is so are
always reliable. The source range of a scope is built up over time.
Original-commit: flang-compiler/f18@d787108637
Reviewed-on: https://github.com/flang-compiler/f18/pull/1060
If the pure context check succeeds, call `WhyNotModifiable` to verify
the LHS can be modified.
Detect assignment to whole assumed-size array.
Change `IsVariable` to return false for a parameter or a component or
array reference whose base it a parameter.
When analyzing an assignment statement, report an error if the LHS is
a constant expression. Otherwise it might get folded and when we detect
the problem later the error will be confusing.
Handle Substring on LHS of assignment. Change ExtractDataRef and IsVariable
to work on a Substring.
Fix IsImpliedShape and IsAssumedSize predicates in ArraySpec.
Fix C709 check in check-declarations.cpp.
Original-commit: flang-compiler/f18@f2d2657aab
Reviewed-on: https://github.com/flang-compiler/f18/pull/1050
Have CheckDefinabilityInPureScope and CheckCopyabilityInPureScope return
false when their checks fail and report errors so that we will be able
to avoid reporting extra errors in those cases.
Original-commit: flang-compiler/f18@305a3470e5
Reviewed-on: https://github.com/flang-compiler/f18/pull/1050
Tree-same-pre-rewrite: false
One overload of WhyNotModifiable returned an optional message while the
other returns a unique_ptr. Change the latter to be consistent with the
former and other message-returning functions in this file.
Also, reorder the if clauses to reduce the level of indentation.
Original-commit: flang-compiler/f18@864e9cfc7e
Reviewed-on: https://github.com/flang-compiler/f18/pull/1050
Tree-same-pre-rewrite: false
As we loop through the Components, maintain a pointer to the current
DataRef rather than moving it. This is more efficient and the previous
behavior caused illegal memory accesses.
Original-commit: flang-compiler/f18@cede2971ff
Reviewed-on: https://github.com/flang-compiler/f18/pull/1050
Tree-same-pre-rewrite: false
* Change README to refer to LLVM_BUILD_DIR.
LLVM_INSTALL_TOOLS doesn't to install llvm-lit. However pointing to the cmake file in the build directory works fine, and lit and FileCheck will be picked up correctly this way.
Original-commit: flang-compiler/f18@3cbe344f82
Reviewed-on: https://github.com/flang-compiler/f18/pull/1033
The struct Temp is used in the function call createUniqueFile
which only takes in a file descriptor instead of a file handler.
In Unix these are the same thing, but in Windows they are different.
Therefore, the type of the member of struct Temp is changed
from file handler to file descriptor and when closing the file
the file descriptor is converted to a file handler.
Original-commit: flang-compiler/f18@a8edb328f7
Reviewed-on: https://github.com/flang-compiler/f18/pull/1036
When a misparsed FunctionReference was converted to a StructureConstructor,
the components accessed were not checked for accessibility.
The conversion happens in expression analysis so that where the accessibity
must be checked. So move `CheckAccessibleComponent` to `tools.h` so that it
can be shared by `resolve-names.cpp` and `expression.cpp`.
Add FindModuleContaining to help implement this and use it other places.
Check that an access-spec can only appear in a module.
Remove some unnecessary "semantics::" qualifiers.
Original-commit: flang-compiler/f18@99ce156e49
Reviewed-on: https://github.com/flang-compiler/f18/pull/1046
When something is parsed as an array element it was sometimes intended
to be a function call or structure constructor. So if the base name is
not found the errors can be confusing. This is an attempt to improve
them.
When the subscript list is empty, it was probably meant to be a function
call, so report that the name is not a function.
If the base is a scalar but there are subscripts, report that it is not
an array.
Original-commit: flang-compiler/f18@e2fd5333ff
Reviewed-on: https://github.com/flang-compiler/f18/pull/1039
Data statements contains expressions but they are not wrapped in one of
the kinds of parse tree nodes that are analyzed, like `parser::Expr`.
So potential errors were not discovered.
Change `ExprChecker` to handle `DataStmtConstant` and analyze any
expressions that are contained in it. Note that the analyzed form of
the expression is not yet saved in the parse tree.
Original-commit: flang-compiler/f18@8bdaf0a521
Reviewed-on: https://github.com/flang-compiler/f18/pull/1044
I've updated the compiler and test source with references to the contraints at
the points where they were enforced and tested. Many of these were already
implemented and required no code change. A few constraint checks were both
implemented and tested, and I only added references to the constraint
numbers in the compiler source and tests. Here are the things I had to
implement:
Constraint C716 states that, in a REAL constant, if both a kind-param and an
exponent letter appear, the exponent letter must be 'E'.
Constraints C715 and C719 require that a KIND value be actually implemented.
Constraint C722 requires that functions that return assumed-length character
types are external.
Constraint C726 disallows assumed lenght charater types for dummy arguments and
return types.
Original-commit: flang-compiler/f18@45998741e5
Reviewed-on: https://github.com/flang-compiler/f18/pull/1031
Tree-same-pre-rewrite: false
In a data statement like `data x / a(1) /`, `a(1)` may be an array
element or a structure constructor. It is parsed as an array element
so if it turns out `a` is a derived type it must be rewritten as a
strucutre constructor.
Original-commit: flang-compiler/f18@a2b2a330e7
Reviewed-on: https://github.com/flang-compiler/f18/pull/1024
Some versions of clang that we are building with don't have
std::set::merge, even though it is part of C++17. Work around
that by using std::set::insert until we can count on merge being
available everywhere.
Original-commit: flang-compiler/f18@886ccc37fb
Reviewed-on: https://github.com/flang-compiler/f18/pull/1014
This script, when run on a checkout of the f18 repository, takes the
current origin/master and makes a branch called "new" with a rewritten
history;
The "new" branch has a flat git history (that is, a series of commits
with only one parent). Flattening is done for merge commits by taking
the content of the commit as it is at the merge commit.
Original-commit: flang-compiler/f18@d9871fa9eb
Reviewed-on: https://github.com/flang-compiler/f18/pull/854
`data x /a(1)/` is ambiguous. The data value may be an array element
or a structure constructor. We need to parse it as one of these and
then fix up the parse tree when it should have been the other one.
My PR 1012 changed the parser to identify this as an array element.
That makes this test invalid until we have the right parse tree fixup,
so I am disabling it for now.
Original-commit: flang-compiler/f18@72aa278f03
Reviewed-on: https://github.com/flang-compiler/f18/pull/1013
Check that masks and LHS of assignments in WHERE statements and
constructs have consistent shapes. They must all have the same rank and
any extents that are compile-time constants must match.
Emit a warning for assignments in FORALL statements and constructs where
the LHS does not reference each of the index variables.
Original-commit: flang-compiler/f18@8b04dbebcf
Reviewed-on: https://github.com/flang-compiler/f18/pull/1009
This DATA statement was getting a parsing error:
`data x /a(i)%b/`
The parser was expecting the ending '/' where the '%' was. The problem
was parsing `a(i)` as a structure constructor. Instead, move the
constant subobject case before structure constructor, but match it only
if not followed by '('. That is because in `data x /a(1)(2)/`, `a(1)` is
a valid structure constructor.
Also, remove the NamedConstant alternative from DataStmtRepeat. A named
constant is always parsed as a ConstantSubobject so it can never occur.
Original-commit: flang-compiler/f18@04a76b2726
Reviewed-on: https://github.com/flang-compiler/f18/pull/1012
This commit covers Semantic Constraints C882 - C887
C882 : It was partially Implemented. Finished the implementation
and added test case
C884 : Implemented and added test case
C883 : Implementation was there already. Added test case
C885, C886, C887 : Implementation was there already. Added test case for
data-repeat.
Original-commit: flang-compiler/f18@822129736b
Reviewed-on: https://github.com/flang-compiler/f18/pull/992
FORALL statements and constructs require a lot of the same checking
as DO CONCURRENT, so do the checks in DoChecker so that code can be
shared where possible. This requires some reorganization there.
Remove code from AssignmentChecker that did some of these checks.
Change names that contain `DoVar` or `DoVariable` to `IndexVar` to
reflect the fact that they may be DO or FORALL index variables.
Distinguish between the two when necessary with enum `IndexVarKind`.
Change some messages that referred to "concurrent-header" or
"concurrent-control" to specifically say "DO CONCURRENT" or "FORALL".
Original-commit: flang-compiler/f18@84752c492e
Reviewed-on: https://github.com/flang-compiler/f18/pull/989
Tree-same-pre-rewrite: false
Every analyzed assignment represented by `evaluate::Assignment` has
a LHS and RHS expression. These need to be checked uniformly in various
places. So change Assignment always to have those data members, with
the variant determining which kinds of assignment it is: intrinsic,
user-defined, or pointer.
Original-commit: flang-compiler/f18@fb87d16a86
Reviewed-on: https://github.com/flang-compiler/f18/pull/989
Tree-same-pre-rewrite: false
C709 An assumed-type entity shall be a dummy data object that does not
have the ALLOCATABLE, CODIMENSION, INTENT (OUT), POINTER, or VALUE
attribute and is not an explicit-shape array.
C710 An assumed-type variable name shall not appear in a designator or
expression except as an actual argument corresponding to a dummy
argument that is assumed-type, or as the first argument to the intrinsic
function IS_CONTIGUOUS, LBOUND, PRESENT, RANK, SHAPE, SIZE, or UBOUND,
or the function C_LOC from the intrinsic module ISO_C_BINDING.
C711 An assumed-type actual argument that corresponds to an assumed-rank
dummy argument shall be assumed-shape or assumed-rank.
For C709 I added code to check-declarations.cpp. For this, I had to
distinguish between polymorphic types and assumed-type types to
eliminate multiple messages on the same line.
C710 was already checked, but I added a notation in the source.
For C711 I added code to check-call.cpp and the test call15.f90.
Original-commit: flang-compiler/f18@4a703f2b5a
Reviewed-on: https://github.com/flang-compiler/f18/pull/985
This re-ordering allows building f18 with shared library using and LLVM build
with static libraries.
This reordering (that also made sens form an alphabetical point of view)
works here to do such "shared+archive" compiling because the current
dependency on LLVM is simple (only one f18 lib + an executable depends on LLVM).
As soon as two f18 libraries will depend on LLVM, one will have to use an LLVM
version built with -DBUILD_SHARED_LIBS=On if one wants to use this option
to compile f18.
Original-commit: flang-compiler/f18@bbbbe9c1aa
Reviewed-on: https://github.com/flang-compiler/f18/pull/994
This commit implements rule:
A loop iteration variable for a sequential loop in a parallel or
task generating construct is private in the innermost such construct
that encloses the loop.
A Simple example:
```
i = -1 <== Scope 0
j = -1
!$omp parallel <== Scope 1
print *,i,j <-- both are shared (Scope 0)
!$omp parallel <== Scope 2
print *,i,j <-- a) i is shared (Scope 0), j is private (Scope 2)
!$omp do <== Scope 3
do i=1, 10 <-- i is private (Scope 3)
do j=1, 10 <-- b) j is private (Scope 2, not 3!)
enddo
enddo
print *,i,j <-- c) i is shared (Scope 0), j is private (Scope 2)
!$omp end parallel
print *,i,j <-- both are shared (Scope 0)
!$omp end parallel
print *,i,j <-- both are shared (Scope 0)
end
```
Ideally the above rule solves a), b), and c) but a) is left as a TODO
because it is better to handle the data-sharing attribute conflicts
along with the rules for "Predetermined DSA on Clauses".
The basic idea is when visiting the `DoConstruct` node within an OpenMP
construct, if the do-loop is not associated (like `i` loop is associated
with `!$omp do`) AND the do-loop is in the parallel/task generating
construct, resolve the loop index to be private to that innermost construct.
In the above example, `j` loop is not associated (then it is sequential) and
the innermost parallel/task generating construct that encloses the `j` loop
is the `parallel` construct marked with `<== Scope 2`, so `j` is private
to that construct. To do that, I also need to change the prototype of those
`ResolveOmp*` functions to allow specifiying the `scope` because the new
symbol for `j` should be created in Scope 2 and all the `symbol` field of
`Name j` in that `parallel` construct should be fixed, such as c).
Original-commit: flang-compiler/f18@69a845283b
Reviewed-on: https://github.com/flang-compiler/f18/pull/976
The Pre-FIR Tree structure is a transient data structure that
is meant to be built from the parse tree just before lowering to
FIR and that will be deleted just afterwards. It is not meant to perfrom
optimization analysis and transformations. It only provides temporary
information, such as label target information or parse tree parent nodes,
that is meant to be used to lower the parse tree structure into
FIR operations.
A PFTBuilder class builds the Pre-Fir Tree from the parse-tree.
A pretty printer is available to visualize this data structure.
- Lit tests are added to:
1. that the PFT tree structure is as expected
2. that the PFT captures all intented nodes
- Cmake changes: Prevent warnings inisde LLVM headers when compiling flang
The issue is that some LLVM headers define functions where the usage of
the parameters depend on environment ifdef. See for instance Size in:
5f940220bf/llvm/include/llvm/Support/Compiler.h (L574)
Because flang is build with -Werror and -Wunused-parameter is default in
clang, this may breaks build in some environments (like with clang9 on macos).
A solution would be to add -Wno-unused-parameter to flang CmakLists.txt,
but it is wished to keep this warning on flang sources for quality purposes.
Fixing LLVM headers is not an easy task and `[[maybe_unused]]` is C++17 and
cannot be used yet in LLVM headers.
Hence, this fix simply silence warnings coming from LLVM headers by telling
CMake they are to be considered as if they were system headers.
- drone.io changes: remove llvm 6.0 from clang config in drone.io and link
flang with libstdc++ instead of libc++
llvm-dev resolved to llvm-6.0 in clang builds on drone.io. llvm 6.0 too old.
LLVM packages are linked with libstdc++ standard library whereas libc++ was
used for flang. This caused link time failure when building clang. Change
frone.io to build flang with libc++.
Note:
This commit does not reflect an actual work log, it is a feature based split of the
changes done in the FIR experimental branch. The related work log can be found in the
commits between:
864898cbe509d032abfe1172ec367dbd3dd92bc1
and
137c23da9c64cf90584cf81fd646053a69e91f63
Other changes come from https://github.com/flang-compiler/f18/pull/959 review.
Original-commit: flang-compiler/f18@edb0943bca
Reviewed-on: https://github.com/flang-compiler/f18/pull/959
An entity declared with the CLASS keyword shall be a dummy argument or
have the ALLOCATABLE or POINTER attribute.
Implementing this check revealed a problem in the test resolve44.cpp.
It also showed that we were doing semantic checking on the entities
created by the compiler for LOCAL and LOCAL_INIT locality-specs. So I
changed the creation of symbols associated with LOCAL and LOCAL_INIT
locality-specs to be host associated with the outer symbol rather than
new object entities. In the process, I also changed things so that the
`parser::Name` associated with the newly created symbols was set to the
symbol rather than being set to nullptr.
Original-commit: flang-compiler/f18@5dd0b0bbe8
Reviewed-on: https://github.com/flang-compiler/f18/pull/981
Use internal units for internal I/O state
Replace use of virtual functions
reference_wrapper
Internal formatted output to array descriptor
Delete dead code
Begin list-directed internal output
Refactorings and renamings for clarity
List-directed external I/O (character)
COMPLEX list-directed output
Control list items
First cut at unformatted I/O
More OPEN statement work; rename class to ExternalFileUnit
Complete OPEN (exc. for POSITION=), add CLOSE()
OPEN(POSITION=)
Flush buffers on crash and for terminal output; clean up
Documentation
Fix backquote in documentation
Fix typo in comment
Begin implementation of input
Refactor binary floating-point properties to a new header, simplify numeric output editing
Dodge spurious GCC 7.2 build warning
Address review comments
Original-commit: flang-compiler/f18@9c4bba11cf
Reviewed-on: https://github.com/flang-compiler/f18/pull/982
I implemented and added tests for constraints C703, C704, C705, C706,
and C796. In some cases, the code and/or test already existed, and all
I did was add a notation indicating the associated constraint.
Original-commit: flang-compiler/f18@49a64c4c23
Reviewed-on: https://github.com/flang-compiler/f18/pull/978
C702 (R701) A colon shall not be used as a type-param-value except in the
declaration of an entity that has the POINTER or ALLOCATABLE attribute.
I added code to the visitor for a TypeDeclarationStmt to check for the
'LEN' type parameter for strings and to loop over the type parameters
for derived types.
I also ran into a few situations where previous tests had erroneously
used a colon for type parameters without either the POINTER or
ALLOCATABLE attribute and fixed them up.
Original-commit: flang-compiler/f18@a1a95bfcd1
Reviewed-on: https://github.com/flang-compiler/f18/pull/973
This refers to three rules in OpenMP 4.5 Spec 2.15.1.1:
* The loop iteration variable(s) in the associated do-loop(s) of a do,
parallel do, taskloop, or distribute construct is (are) private.
* The loop iteration variable in the associated do-loop of a simd
construct with just one associated do-loop is linear with a linear-step
that is the increment of the associated do-loop.
* The loop iteration variables in the associated do-loops of a simd
construct with multiple associated do-loops are lastprivate.
A simple example:
```
implicit none
integer :: N = 1024
integer i, j, k
!$omp parallel do collapse(3)
do i=1, N <- i is private
do j=1, N <- j is private
do k=1, N <- k is private
enddo
enddo
enddo
end
```
If `collapse` clause is not present, the associated do-loop for construct
`parallel do` is only `i` loop. With `collapse(n)`, `i`, `j`, and `k` are
all associated do-loops and the loop index variables are private to the
OpenMP construct:
```
implicit none
!DEF: /MainProgram1/n ObjectEntity INTEGER(4)
integer :: n = 1024
!DEF: /MainProgram1/i ObjectEntity INTEGER(4)
!DEF: /MainProgram1/j ObjectEntity INTEGER(4)
!DEF: /MainProgram1/k ObjectEntity INTEGER(4)
integer i, j, k
!$omp parallel do collapse(3)
!DEF: /MainProgram1/Block1/i (OmpPrivate) HostAssoc INTEGER(4)
!REF: /MainProgram1/n
do i=1,n
!DEF: /MainProgram1/Block1/j (OmpPrivate) HostAssoc INTEGER(4)
!REF: /MainProgram1/n
do j=1,n
!DEF: /MainProgram1/Block1/k (OmpPrivate) HostAssoc INTEGER(4)
!REF: /MainProgram1/n
do k=1,n
end do
end do
end do
end program
```
This implementation assumes that the structural checks for do-loops
are done at this point, for example the `n` in `collapse(n)` should
be no more than the number of actual perfectly nested do-loops, etc..
Original-commit: flang-compiler/f18@572a57d3d0
Reviewed-on: https://github.com/flang-compiler/f18/pull/962
While working on PR 959, I instanciated a `common::TupleToVariant`
with ~50+ types inside the tuple. Clang would then crash after
1hr compilation with message:
"constexpr evaluation hit maximum step limit; possible infinite loop"
After investigating, it turned out clang handles very badly the way
`common::AreTypesDistinctHelper` was implemented.
Its "number of steps" was exponential with the number of types.
This fix makes this number quadratic which solves the issue.
Original-commit: flang-compiler/f18@4542cb5708
Reviewed-on: https://github.com/flang-compiler/f18/pull/968
Address review comments
Integer output data editing (I,B,O,Z)
Full integer output formatting
Stub out some work in progress
Progress on E output data editing
E, D, EN, and ES output editing done
Fw.d output editing
Real G output editing
G output editing for reals
Make environment a distinct module
CHARACTER and LOGICAL output editing
Minimal decimal representations for E0, F0, G0 editing
Move real output editing code into its own file
Fix/dodge some GCC build problems
Prep work for external I/O statement state
External HELLO, WORLD
Fix build problem with GCC
Add virtual destructors where needed
Add new test
Original-commit: flang-compiler/f18@c3f1774f8e
Reviewed-on: https://github.com/flang-compiler/f18/pull/950
The test still wasn't correct for structure components. If the last
part-ref is a non-array or a single array element, but the whole
ArrayRef has non-zero rank, it is not contiguous. Otherwise, if there
are subscripts on the last part-ref they can be checked normally.
Add some tests for cases that were previously failing, and also for
cases with vector subscripts.
Original-commit: flang-compiler/f18@aa0a088732
Reviewed-on: https://github.com/flang-compiler/f18/pull/961
You cannot call an IMPURE procedure in a DO CONCURRENT construct. One
way that can happen is if an entity with an IMPURE FINAL procedure gets
deallocated. Similar to the checks for deallocating coarrays, there are
three ways that an entity can get deallocated that are applicable to DO
CONCURRENT constructs -- an actual DEALLOCATE statement, block exit, and
assignment.
This change depends on the utility function `HasImpureFinal()` in tools.h to
determine if an entity has a derived type with an IMPURE FINAL
procedure. In the course of testing this change, I realized that this
check is incorrect, but the code specific to DO CONCURRENT is
independent of the check, so I might as well implement it.
Original-commit: flang-compiler/f18@d2294ff511
Reviewed-on: https://github.com/flang-compiler/f18/pull/954
This is an extended framework based on the previous work that addresses
the NR on OpenMP directives/clauses (b2ea520). In this change:
* New `OmpVisitor` is created (ResolveNamesVisitor derives from it) to
create necessary scopes for certain OpenMP constructs. This is along
with the regular Fortran NR process.
* Old `OmpVisitor` is adjusted and converted to a standalone visitor--
`OmpAttributeVisitor`. This is used to walk through the OpenMP constructs
and do the NR for variables on the OpenMP directives or data references
within the OpenMP constructs. "Do the NR" here means that based on the NR
results of the regular Fortran NR, fix the symbols of `Names` related
to the OpenMP constructs. Note that there is an `OmpContext` in this
visitor (similar to the one in `OmpStructureChecker`), this is necessary
when dealing with the nested OpenMP constructs in the future.
Given an OpenMP code:
```
real*8 a, b
a = 1.
b = 2.
!$omp parallel private(a)
a = 3.
b = 4.
!$omp end parallel
print *, a, b
end
```
w/o -fopenmp:
```
real*8 a, b
!REF: /MainProgram1/a
a = 1.
!REF: /MainProgram1/b
b = 2.
!!!! OMP parallel
!REF: /MainProgram1/a
a = 3.
!REF: /MainProgram1/b
b = 4.
!!!! OMP end parallel
!REF: /MainProgram1/a
!REF: /MainProgram1/b
print *, a, b
end
```
w/ -fopenmp:
```
real*8 a, b
!REF: /MainProgram1/a
a = 1.
!REF: /MainProgram1/b
b = 2.
!$omp parallel private(a) <-- new Symbol for 'a' created
!DEF: /MainProgram1/Block1/a (OmpPrivate) HostAssoc REAL(8)
a = 3. <-- fix the old symbol with new Symbol in parallel scope
!REF: /MainProgram1/b
b = 4. <-- do nothing because by default it is shared in this scope
!$omp end parallel
!REF: /MainProgram1/a
!REF: /MainProgram1/b
print *, a, b
end
```
Please note that this is a framework update, there are still many
things on the TODO list for finishing the NR for OpenMP (based on
the `OpenMP-semantics.md` design doc), which will be on top of this
framework.
Some TODO items:
- Create a generic function to go through all the rules for deciding
`predetermined`, `explicitly determined`, and `implicitly determined`
data-sharing attributes. (This is the next biggest part)
- Handle `Array Sections` and `Array or Structure Element`.
- Take association into consideration for example Pointer association,
`ASSOCIATE` construct, and etc.
- Handle all the name resolution for directives/clauses that have
`parser::Name`.
* N.B. Extend `AddSourceRange` to apply to current and parent scopes
- motivated by a few cases that need to call `AddSourceRange`
for current & parent scopes; the extension should be safe
- global scope is not included
Original-commit: flang-compiler/f18@0c3c39d30e
Reviewed-on: https://github.com/flang-compiler/f18/pull/940
Updated CMake files accordingly, using better regex
Updated license headers to match new extension and fit within 80 columns
Updated other comments within files that referred to the old extension
Original-commit: flang-compiler/f18@ae7721e611
Reviewed-on: https://github.com/flang-compiler/f18/pull/958
Change Traverse to visit the actual arguments of structure constructors.
Change FindImpureCallHelper to visit the actual arguments of a call to a
pure procedure in case one of them makes a call to an impure function.
Original-commit: flang-compiler/f18@81a5488ee6
Reviewed-on: https://github.com/flang-compiler/f18/pull/951
We were always return false when testing a component for simple
contiguity. Change to check that the component is an array that is
simply continguous. Also treat a scalar component of scalar as simply
contiguous.
A pointer with bounds remapping to a complex part is a similar case
so add a test for that too.
Original-commit: flang-compiler/f18@27d76da2a4
Reviewed-on: https://github.com/flang-compiler/f18/pull/952
internal formatted WRITE with no data list items.
Improve argument names in io-api.h
Bump up error number to not conflict with errno values
Use Fortran::runtime::io namespace
Add wrapper around malloc/free, allow use of unique_ptr with wrapper
IoErrorHandler
Revamp FormatContext, use virtual member functions
Update comment syntax, allow for old C
12HHELLO, WORLD
Remove files not yet ready for review
Use std::forward
Fix gcc build warnings
Fix redundant filename in license boilerplate
Reduce runtime dependence on compiler binary libraries, fixing shared lib builds
Original-commit: flang-compiler/f18@839a91f1d6
Reviewed-on: https://github.com/flang-compiler/f18/pull/946
Perform checks on bounds-spec and bounds-remapping in a pointer
assignment statement:
- check that the rank of the bounds specified matches the rank of the
pointer
- for bounds-spec, check that the pointer rank matches the target rank
- for bounds-remapping:
- check that the target is rank 1 or simply contiguous
- check that there are sufficient elements on the RHS for the bounds
specified, when it can be determined at compile time
Move more of the pointer-specific checking from `assignment.cc`
to `pointer-assignment.cc`.
Original-commit: flang-compiler/f18@7489b35392
Reviewed-on: https://github.com/flang-compiler/f18/pull/944
Use early returns to reduce the indentation.
Check LHS is a pointer as early as possible.
A PointerAssignmentStmt can only have a typedAssignment that
represents a PointerAssignment. So assert that is the case and
don't worry about the other cases.
Original-commit: flang-compiler/f18@bdf3d3a292
Reviewed-on: https://github.com/flang-compiler/f18/pull/944
Tree-same-pre-rewrite: false
Have it wrap an optional Assignment so that we can distinguish between
unanalyzed and analyzed with error.
Change analysis of PointerAssignmentStmt to proceed with bounds even
if the DataRef or Expr has an error. Otherwise any bounds expressions
won't be analyzed in that case.
In GetExpr() and GetAssignment() if we get an internal error due to an
unanalyzed expression, dump the parse tree for the expression so we have
some context for the error. They should only be called after the
expression analysis phase. At that point, every expression and assignment
should be analyzed, though some may have resulted in errors(indicated by
returning `nullptr`).
Original-commit: flang-compiler/f18@3b865d7703
Reviewed-on: https://github.com/flang-compiler/f18/pull/944
Tree-same-pre-rewrite: false
This is easier to use when including an expression in an error message
and also useful when debugging for dumping expressions.
Fix up several places that no longer need to use a temporary
std::stringstream.
Also change some references to `operator<<` in `formatting.cc` and
`symbol.cc` that became ambiguous with this change.
Original-commit: flang-compiler/f18@25dc49b6e9
Reviewed-on: https://github.com/flang-compiler/f18/pull/944
Tree-same-pre-rewrite: false
When checking if the target of a pointer assignment is valid, we
weren't following associations. E.g. we complained about the assignment
below if `b` had the TARGET attribute but `c` did not:
```
associate(a => b%c)
p => a
end associate
```
The fix is to change `GetSymbolVector()` to follow associations in
creating the chain of symbols from a designator.
Add tests for this, and also some other cases where TARGET is on the
derived type variable rather than the component (which worked but didn't
have tests).
Original-commit: flang-compiler/f18@c81c6baedd
Reviewed-on: https://github.com/flang-compiler/f18/pull/937
Call `CheckPointerAssignment()` when analyzing a pointer assignment
statement. NOTE: the cases with bounds-spec and bounds-remapping are
still to be done.
Perform checks on pointer symbols in `check-declarations.cc`.
Check for pointer to generic intrinsic in `semantics/expression.cc`.
Add the other required pointer assignment checks to `pointer-assignment.cc`.
Original-commit: flang-compiler/f18@3dc5fd6d9e
Reviewed-on: https://github.com/flang-compiler/f18/pull/928
This replaces IsUnrestrictedSpecificIntrinsicFunction and returns
information that allows the caller to distinguish between restricted
and unrestricted intrinsics.
The new case in `resolve46.f90` used to get an internal error.
Original-commit: flang-compiler/f18@4cb1ee10b9
Reviewed-on: https://github.com/flang-compiler/f18/pull/928
Tree-same-pre-rewrite: false
`DynamicType::AsFortran` was using mixed case for intrinic type names.
Make it upper case for consistency with TYPE(...) and CHARACTER when a
length is present and other error messages.
Original-commit: flang-compiler/f18@e16909d67f
Reviewed-on: https://github.com/flang-compiler/f18/pull/928
Tree-same-pre-rewrite: false
Create `pointer-assignment.{h,cc}` for pointer assignment checking.
It doesn't share with assignment checking so it should be its own file.
Move the code into semantics namespace.
Original-commit: flang-compiler/f18@1658aba81f
Reviewed-on: https://github.com/flang-compiler/f18/pull/928
Tree-same-pre-rewrite: false
At the time we finish processing an array-spec in `resolve-names.cc`,
we don't know if the entity is going to be declared ALLOCATABLE later
so we can't check for validity there. In the new test in `resolve58.f90`
(based on issue flang-compiler/f18#930) we were reporting an error on `b` and not on `a`
when it should be the reverse.
The fix is to move array-spec checking to `check-declarations.cc`,
after name resolution is complete.
Fixesflang-compiler/f18#930.
Original-commit: flang-compiler/f18@c596d2fef7
Reviewed-on: https://github.com/flang-compiler/f18/pull/933
The configuration for the tests are in lit.* files.
The lit tests rely on the presence of llvm-lit,FileCheck, not and count.
When building LLVM add:
-DLLVM_INSTALL_UTILS=On at the cmake command.
LLVM_LIT is found by setting LLVM_EXTERNAL_LIT in f18 CMakeLists.txt.
This patch:
* Uses LLVM_EXTERNAL_LIT
* Adds regression tests configurations
* Adds a proof of concept regression test
The regression test needs to have the Utils build in LLVM.
This is done by adding:
-DLLVM_INSTALL_UTILS=On
to the LLVM build cmake.
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Original-commit: flang-compiler/f18@a58c6067a1
Reviewed-on: https://github.com/flang-compiler/f18/pull/861
This fixes an issue where the Dump function definitions in dump.cc
were relying on the forward declaration of operator<< for CharBlock
which was marked inline and only present in char-block.h.
This is not allowed under section 6.2.10 of the C++17 standard, and
caused a compilation failure when building with clang 9 as this was
inlining every use of the function and therefore not generating an
outlined definition for linking.
Original-commit: flang-compiler/f18@3ad75d123b
Reviewed-on: https://github.com/flang-compiler/f18/pull/916
I added a traveral framework to find actual arguments in expressions.
For arguments that are DO variables being passed to dummy arguments with
INTENT(OUT), I emit an error message. For INTENT(INOUT), I emit a
warning.
Original-commit: flang-compiler/f18@815dbed75c
Reviewed-on: https://github.com/flang-compiler/f18/pull/918
Assumed-type dummy arguments can only be used as actual arguments. If
they are used in other contexts it is an error. Change argument analysis
to handle these differently depending on the context. `allowAssumedType`
is set when the argument can be assumed-type. These expressions now all
get `typedExpr` set to `nullopt`.
Change `AnalyzeSectionSubscripts` to analyze all of the subscripts
even if one has an error. This ensures they all get analyzed expressions
(or `nullopt` in case of error).
Fix a bug analyzing `BoundsRemapping`: the lower bound was analyzed
twice and the upper bound not at all.
These change mean that `typedExpr` is set in all known cases.
Fixesflang-compiler/f18#915.
Original-commit: flang-compiler/f18@679ef69905
Reviewed-on: https://github.com/flang-compiler/f18/pull/923
Tim Keith