This patch updates the final test that can be shared between the old and
the new Flang drivers and that has not been ported yet. %f18 (always
expanded as `f18`) is replaced with %flang_fc1 (expanded as either `f18`
or `flang-new -fc1`, depending on `FLANG_BUILD_NEW_DRIVER`).
This test should've been updated in https://reviews.llvm.org/D100309,
but I missed it then. That's because this test contains non-ascii
characters and `grep -I %f18` (as well as other grep-like tools) skips
it because it's interpreted as a data/binary file. In fact, it's just a
text file with non-ascii chars.
Since this is an obvious omission from D100309 (reviewed, accepted and
merged), I'm sending this without a review to reduce the noise on
Phabricator.
The single source file reduction.cpp is a little large in
terms of both source lines and generated text bytes, so
split SUM, PRODUCT, FINDLOC, and MAXLOC/MAXVAL/MINLOC/MINVAL
off into their own C++ source files that share a set of
implementation function templates now in a common header.
Differential Revision: https://reviews.llvm.org/D101111
Switching from `%f18` to `%flang_fc1` in LIT tests added in
https://reviews.llvm.org/D91159. This way these tests are run with the
new driver, `flang-new`, when enabled (i.e. when
`FLANG_BUILD_NEW_DRIVER` is set).
Differential Revision: https://reviews.llvm.org/D101078
Andrezj W. @ Arm discovered that the runtime derived type table
building code in semantics was detecting fatal errors in the tests
that the f18 driver wasn't printing. This patch fixes f18 so that
these messages are printed; however, the messages were not valid user
errors, and the rest of this patch fixes them up.
There were two sources of the bogus errors. One was that the runtime
derived type information table builder was calculating the shapes of
allocatable and pointer array components in derived types, and then
complaining that they weren't constant or LEN parameter values, which
of course they couldn't be since they have to have deferred shapes
and those bounds were expressions like LBOUND(component,dim=1).
The second was that f18 was forwarding the actual LEN type parameter
expressions of a type instantiation too far into the uses of those
parameters in various expressions in the declarations of components;
when an actual LEN type parameter is not a constant value, it needs
to remain a "bare" type parameter inquiry so that it will be lowered
to a descriptor inquiry and acquire a captured expression value.
Fixing this up properly involved: moving some code into new utility
function templates in Evaluate/tools.h, tweaking the rewriting of
conversions in expression folding to elide needless integer kind
conversions of type parameter inquiries, making type parameter
inquiry folding *not* replace bare LEN type parameters with
non-constant actual parameter values, and cleaning up some
altered test results.
Differential Revision: https://reviews.llvm.org/D101001
This patch adds semantic checks for the General Restrictions of the
Allocate Directive.
Since the requires directive is not yet implemented in Flang, the
restriction:
```
allocate directives that appear in a target region must
specify an allocator clause unless a requires directive with the
dynamic_allocators clause is present in the same compilation unit
```
will need to be updated at a later time.
A different patch will be made with the Fortran specific restrictions of
this directive.
I have used the code from https://reviews.llvm.org/D89395 for the
CheckObjectListStructure function.
Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Reviewed By: clementval, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D91159
We were erroneously not taking into account the constant values of LEN type
parameters of parameterized derived types when checking for argument
compatibility. The required checks are identical to those for assignment
compatibility. Since argument compatibility is checked in .../lib/Evaluate and
assignment compatibility is checked in .../lib/Semantics, I moved the common
code into .../lib/Evaluate/tools.cpp and changed the assignment compatibility
checking code to call it.
After implementing these new checks, tests in resolve53.f90 were failing
because the tests were erroneous. I fixed these tests and added new tests
to call03.f90 to test argument passing of parameterized derived types more
completely.
Differential Revision: https://reviews.llvm.org/D100989
This patch adds `-fget-definition` to `flang-new`. The semantics of this
option are identical in both drivers. The error message in the
"throwaway" driver is updated so that it matches the one from
`flang-new` (which is auto-generated and cannot be changed easily).
Tests are updated accordingly. A dedicated test for error handling was
added: get-definition.f90 (for the sake of simplicity,
getdefinition01.f90 no longer tests for errors).
The `ParseFrontendArgs` function is updated so that it can return
errors. This change is required in order to report invalid values
following `-fget-definition`.
The actual implementation of `GetDefinitionAction::ExecuteAction()` was
extracted from f18.cpp (i.e. the bit that deals with
`-fget-definition`).
Depends on: https://reviews.llvm.org/D100556
Differential Revision: https://reviews.llvm.org/D100558
We were erroneously emitting error messages for assignments of derived types
where the associated objects were instantiated with non-constant LEN type
parameters.
I fixed this by adding the member function MightBeAssignmentCompatibleWith() to
the class DerivedTypeSpec and calling it to determine whether it's possible
that objects of parameterized derived types can be assigned to each other. Its
implementation first compares the uninstantiated values of the types. If they
are equal, it then compares the values of the constant instantiated type
parameters.
I added tests to assign04.f90 to exercise this new code.
Differential Revision: https://reviews.llvm.org/D100868
Define APIs for, and implement, these three more recently-introduced
standard reduction transformational intrinsic functions to the runtime.
Differential Revision: https://reviews.llvm.org/D100863
This is just a small update that makes sure that errors arising from
parsing command-line options are captured more visibly. Also, all
parsing methods will now consistently return either a bool ("may fail")
or void ("never fails").
An instance of `InputKind` coming from `-x` is added to
`FrontendOptions` rather then being returned from `ParseFrontendArgs`.
It's currently not used, but we will require it shortly. In particular,
once code-generation is available we will use it to differentiate
between LLVM IR and Fortran input. `FrontendOptions` is a very suitable
place to keep it.
This changes don't affect the error reporting in the driver. In this
respect these are non-functional-changes. However, it will simplify
things in the forthcoming patches in which we may need a better error
tracking/recovery mechanism.
Differential Revision: https://reviews.llvm.org/D100556
This is similar to https://reviews.llvm.org/D100309, i.e. `%f18` is
replaced with `%flang_new`.
resolve105.f90 wasn't in tree when D100309 was worked on, so it's
updated here instead.
label14.f90 requires `-fsyntax-only`. I didn't notice that when
submitting D100309, hence updating it now instead. `-fsyntax-only` is
required to prevent `%f18` from calling an external compiler (which then
fails and returns a non-zero exit code).
Differential Revision: https://reviews.llvm.org/D100655
This patch updates most of the remaining regression tests (~400) to use
`flang-new` rather then `f18` when `FLANG_BUILD_NEW_DRIVER` is set.
This allows us to share more Flang regression tests between `f18` and
`flang-new`. A handful of tests have not been ported yet - these are
currently either failing or not supported by the new driver.
Summary of changes:
* RUN lines in tests are updated to use `%flang_fc1` instead of `%f18`
* option spellings in tests are updated to forms accepted by both `f18` and
`flang-new`
* variables in Bash scripts are renamed (e.g. F18 --> FLANG_FC1)
The updated tests will now be run with the new driver, `flang-new`,
whenever it is enabled (i.e when `FLANG_BUILD_NEW_DRIVER` is set).
Although this patch touches many files, vast majority of the changes are
automatic:
```
grep -IEZlr "%f18" flang/test/ | xargs -0 -l sed -i 's/%f18/%flang_fc1/g
```
Differential Revision: https://reviews.llvm.org/D100309
An empty NAME= should mean that there is no C binding, not the
binding that would result from BIND(C) without a NAME=.
See 18.10.2p2.
Differential Revision: https://reviews.llvm.org/D100494
Two sites in io-api.cpp pass the wrong Boolean flag value to
signify that a new anonymous unit is a formatted file.
Differential Revision: https://reviews.llvm.org/D100419
Debug the input path for READ statements with END= labels;
don't emit errors when the program can handle them.
BeginReadingRecord() member functions have been made
"bool" for more convenient handling of error cases,
and some code in IoErrorHandler has been cleaned up.
Differential Revision: https://reviews.llvm.org/D100421
An OPEN statement that affects an already connected unit
without changing its external file is required to have
STATUS="OLD" or default STATUS=. The code was eliciting
spurious runtime errors in situations where an OPEN statement
pertained to an existing unit number but did not need to have
STATUS="OLD'.
Differential Revision: https://reviews.llvm.org/D100352
We were not instantiating procedure pointer components. If the instantiation
contained errors, we were not reporting them. This resulted in internal errors
in later processing.
I fixed this by adding code in .../lib/Semantics/type.cpp in
InstantiateComponent() to handle a component with ProcEntityDetails. I also
added several tests for various good and bad instantiations of procedure
pointer components.
Differential Revision: https://reviews.llvm.org/D100341
`%flang-new` was introduced in the early days of the new driver to make
a clear distinction between the tests for the current and the new
driver. We have since introduced `%flang` (compiler driver) and
`%flang_fc1` (frontend driver) as the long term solution. This has allowed
us to share tests between `flang-new` and `f18`. This patch replaces
all uses of `%flang-new` with `%flang` and `%flang_fc1`.
Some tests are reformatted so that all tests look uniform and are easier
to follow. Where possible, `! REQUIRES: new-flang-driver` is deleted so
that more tests can be shared with `f18`. To facilitate this,
`f{no-}implicit-none` are introduced in `f18` with semantics identical
to `flang-new`.
Two tests are deleted rather than updated:
* flang/test/Frontend/print-preprocess-C-file.f90
* flang/test/Frontend/print-preprocessed-file.f90
Instead, there is plenty of preprocessor tests in
flang/test/Preprocessing/.
Differential Revision: https://reviews.llvm.org/D100174
With the typo ($S instead of %s), the driver was expecting
input from stdin. In such cases, it prints:
```
Enter Fortran source
Use EOF character (^D) to end file
```
This was piped to FileCheck. Together with the available `CHECK-NOT`
statement, this was sufficient for the test to pass (incorrectly).
This patch makes sure that the provided input file is used instead of
stdin.
Differential Revision: https://reviews.llvm.org/D100301
F18 is using the type codes for C's "least" int types to encode
the various kinds of Fortran's LOGICAL intrinsic type; update
the IsLogical() predicate accordingly. (This member function
isn't yet used anywhere, so this patch is nearly an NFC.)
Differential Revision: https://reviews.llvm.org/D100323
With clang 11 on macos we were getting this warning:
```
flang/runtime/random.cpp:61:30: error: non-constant-expression cannot be narrowed from type 'unsigned long long' to 'runtime::GeneratedWord' (aka 'unsigned int') in initializer list [-Wc++11-narrowing]
GeneratedWord word{(generator() - generator.min()) & rangeMask};
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
flang/runtime/random.cpp:99:5: note: in instantiation of function template specialization 'runtime::Generate<double, 53>' requested here
Generate<CppTypeFor<TypeCategory::Real, 8>, 53>(harvest);
^
```
Changing the type of `rangeMask` fixes it.
Differential Revision: https://reviews.llvm.org/D100320
F18 supports the standard intrinsic function SELECTED_REAL_KIND
but not its synonym in the standard module IEEE_ARITHMETIC
named IEEE_SELECTED_REAL_KIND until this patch.
Differential Revision: https://reviews.llvm.org/D100066
Add APIs, initial non-coarray implementations, and unit
tests for the intrinsic subroutines for pseudo-random
number generation.
Differential Revision: https://reviews.llvm.org/D100064
For pernicious test cases with explicit non-constant actual
type parameter expressions in components, e.g.:
type :: t(k)
integer, kind :: k
type(t(k+1)), pointer :: p
end type
we should detect the infinite recursion and complain rather
than looping until the stack overflows.
Differential Revision: https://reviews.llvm.org/D100065
Check for two or more symbols that define a data object or entry point
with the same interoperable BIND(C) name.
Differential Revision: https://reviews.llvm.org/D100067
Call static functions using the class name (fir::NameUniquer).
Add function for mangling derivedTypes.
All the name mangling functions that are ultimately called are
tested in unittests/Optimizer/InternalNamesTest.cpp.
Differential Revision: https://reviews.llvm.org/D99967
This patch adds two debugging options in the new Flang driver
(flang-new):
*fdebug-unparse-no-sema
*fdebug-dump-parse-tree-no-sema
Each of these options combines two options from the "throwaway" driver
(left: f18, right: flang-new):
* `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema`
* `-fdebug-dump-parse-tree -fdebug-no-semantics` -->
`-fdebug-dump-parse-tree-no-sema`
There are no plans to implement `-fdebug-no-semantics` in the new
driver. Such option would be too powerful. Also, it would only make
sense when combined with specific frontend actions (`-fdebug-unparse`
and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised
options listed above. Each of these is implemented through a dedicated
FrontendAction (also added).
The new frontend actions are implemented in terms of a new abstract base
action: `PrescanAndSemaAction`. This new base class was required so that
we can have finer control over what steps within the frontend are
executed:
* `PrescanAction`: run the _prescanner_
* `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new
in this patch)
* `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the
_semantic checks_
This patch introduces `PrescanAndParseAction::BeginSourceFileAction`.
Apart from the semantic checks removed at the end, it is similar to
`PrescanAndSemaAction::BeginSourceFileAction`.
Differential Revision: https://reviews.llvm.org/D99645
The -fdebug-dump-provenance flag is meant to be used with
needProvenanceRangeToCharBlockMappings set to true. This way, extra
mapping is generated that allows e.g. IDEs to retrieve symbol's scope
(offset into cooked character stream) based on symbol's source code
location. This patch makes sure that this option is set when using
-fdebug-dump-provenance.
With this patch, the implementation of -fdebug-dump-provenance in
`flang-new -fc1` becomes consistent with `f18`. The corresponding LIT
test is updated so that it can be shared with `f18`. I refined it a bit
so that:
* it becomes a frontend-only test
* it's stricter about the expected output
Differential Revision: https://reviews.llvm.org/D98847
This patch adds support for the `-cpp` and `-nocpp` flags. The
implemented semantics match f18 (i.e. the "throwaway" driver), but are
different to gfortran. In Flang the preprocessor is always run. Instead,
`-cpp/-nocpp` are used to control whether predefined and command-line
preprocessor macro definitions are enabled or not. In practice this is
sufficient to model gfortran`s `-cpp/-nocpp`.
In the absence of `-cpp/-nocpp`, the driver will use the extension of
the input file to decide whether to include the standard macro
predefinitions. gfortran's documentation [1] was used to decide which
file extension to use for this.
The logic mentioned above was added in FrontendAction::BeginSourceFile.
That's relatively late in the driver set-up, but this roughly where the
name of the input file becomes available. The logic for deciding between
fixed and free form works in a similar way and was also moved to
FrontendAction::BeginSourceFile for consistency (and to reduce
code-duplication).
The `-cpp/-nocpp` flags are respected also when the input is read from
stdin. This is different to:
* gfortran (behaves as if `-cpp` was used)
* f18 (behaves as if `-nocpp` was used)
Starting with this patch, file extensions are significant and some test
files had to be renamed to reflect that. Where possible, preprocessor
tests were updated so that they can be shared between `f18` and
`flang-new`. This was implemented on top of adding new test for
`-cpp/-nocpp`.
[1] https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D99292
We were not folding type parameter inquiries for the form 'var%typeParam'
where 'typeParam' was a KIND or LEN type parameter of a derived type and 'var'
was a designator of the derived type. I fixed this by adding code to the
function 'FoldOperation()' for 'TypeParamInquiry's to handle this case. I also
cleaned up the code for the case where there is no designator.
In order to make the error messages correctly refer to both the points of
declaration and instantiation, I needed to add an argument to the function
'InstantiateIntrinsicType()' for the location of the instantiation.
I also changed the formatting of 'TypeParamInquiry' to correctly format this
case. I also added tests for both KIND and LEN type parameter inquiries in
resolve104.f90.
Making these changes revealed an error in resolve89.f90 and caused one of the
error messages in assign04.f90 to be different.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D99892
Problem:
On SystemZ we need to open text files in text mode. On Windows, files opened in text mode adds a CRLF '\r\n' which may not be desirable.
Solution:
This patch adds two new flags
- OF_CRLF which indicates that CRLF translation is used.
- OF_TextWithCRLF = OF_Text | OF_CRLF indicates that the file is text and uses CRLF translation.
Developers should now use either the OF_Text or OF_TextWithCRLF for text files and OF_None for binary files. If the developer doesn't want carriage returns on Windows, they should use OF_Text, if they do want carriage returns on Windows, they should use OF_TextWithCRLF.
So this is the behaviour per platform with my patch:
z/OS:
OF_None: open in binary mode
OF_Text : open in text mode
OF_TextWithCRLF: open in text mode
Windows:
OF_None: open file with no carriage return
OF_Text: open file with no carriage return
OF_TextWithCRLF: open file with carriage return
The Major change is in llvm/lib/Support/Windows/Path.inc to only set text mode if the OF_CRLF is set.
```
if (Flags & OF_CRLF)
CrtOpenFlags |= _O_TEXT;
```
These following files are the ones that still use OF_Text which I left unchanged. I modified all these except raw_ostream.cpp in recent patches so I know these were previously in Binary mode on Windows.
./llvm/lib/Support/raw_ostream.cpp
./llvm/lib/TableGen/Main.cpp
./llvm/tools/dsymutil/DwarfLinkerForBinary.cpp
./llvm/unittests/Support/Path.cpp
./clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
./clang/lib/Frontend/CompilerInstance.cpp
./clang/lib/Driver/Driver.cpp
./clang/lib/Driver/ToolChains/Clang.cpp
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D99426
We were not folding type parameter inquiries for the form 'var%typeParam'
where 'typeParam' was a KIND or LEN type parameter of a derived type and 'var'
was a designator of the derived type. I fixed this by adding code to the
function 'FoldOperation()' for 'TypeParamInquiry's to handle this case. I also
cleaned up the code for the case where there is no designator.
In order to make the error messages correctly refer to both the points of
declaration and instantiation, I needed to add an argument to the function
'InstantiateIntrinsicType()' for the location of the instantiation.
I also changed the formatting of 'TypeParamInquiry' to correctly format this
case. I also added tests for both KIND and LEN type parameter inquiries in
resolve104.f90.
Making these changes revealed an error in resolve89.f90 and caused one of the
error messages in assign04.f90 to be different.
Differential Revision: https://reviews.llvm.org/D99892
Move #include <complex.h> to complex-reduction.h, where
it is needed in MSVC builds.
Exclude code that requires a native 128-bit integer type from
compilation by MSVC.
Differential Revision: https://reviews.llvm.org/D99806
A recent patch exposed an assumption that "long double" is (at least)
an 80-bit floating-point type, which of course it is not in MSVC.
Also get it right for non-x87 floating-point.
Due to architectural variation on the C++ functions std::ceil, std::floor,
and std::trunc, diable some new Fortran unit tests for now that depending
on specifical results for IEEE floating-point edge cases of infinities
and NaNs.
The new source file flang/runtime/complex-reduction.c contains
a portability work-around that implicitly assumed that a recent
version of clang would be used; this patch changes the code and
should be portable to older clangs and any other C compilers that
don't support the standard CMPLXF/CMPLX/CMPLXL macros.
Add runtime APIs, implementations, and tests for ALL, ANY, COUNT,
MAXLOC, MAXVAL, MINLOC, MINVAL, PRODUCT, and SUM reduction
transformantional intrinsic functions for all relevant argument
and result types and kinds, both without DIM= arguments
(total reductions) and with (partial reductions).
Complex-valued reductions have their APIs in C so that
C's _Complex types can be used for their results.
Some infrastructure work was also necessary or noticed:
* Usage of "long double" in the compiler was cleaned up a
bit, and host dependences on x86 / MSVC have been isolated
in a new Common/long-double header.
* Character comparison has been exposed via an extern template
so that reductions could use it.
* Mappings from Fortran type category/kind to host C++ types
and vice versa have been isolated into runtime/cpp-type.h and
then used throughout the runtime as appropriate.
* The portable 128-bit integer package in Common/uint128.h
was generalized to support signed comparisons.
* Bugs in descriptor indexing code were fixed.
Differential Revision: https://reviews.llvm.org/D99666
f18 was emitting a bogus error message about the lack of a TARGET
attribute when a pointer was initialized with a component of a
variable that was a legitimate TARGET.
Differential Revision: https://reviews.llvm.org/D99665
When writing tests for a previous problem, I ran across situations where the
compiler was failing calls to CHECK(). In these situations, the compiler had
inconsistent semantic information because the programs were erroneous. This
inconsistent information was causing the calls to CHECK().
I fixed this by avoiding the code that ended up making the failed calls to
CHECK() and making sure that we were only avoiding these situations when the
associated symbols were erroneous.
I also added tests that would cause the calls to CHECK() without these changes.
Differential Revision: https://reviews.llvm.org/D99342
The standard interoperability routine CFI_establish() does not
accept a zero-length CHARACTER type. Since these can be valid
results of intrinsic function references, work around the design
of CFI_establish() in the wrapper routine that calls it.
Differential Revision: https://reviews.llvm.org/D99296
On macos, `size_t` is `unsigned long` while `size_t - int64_t` is
`unsigned long long` so std::min requires an explicit type to compile.
Differential Revision: https://reviews.llvm.org/D99340
Folding of LOGICAL intrinsic procedure was missing in the front-end causing
crash when using it in parameter expressions.
Simply fold LOGICAL calls to evaluate::Convert<T>.
Differential Revision: https://reviews.llvm.org/D99346
Before the conversion to LLVM-IR dialect and ultimately LLVM IR, FIR is
partially rewritten into a codegen form. This patch adds that pass, the
fircg dialect, and the small set of Ops in the fircg (sub) dialect.
Fircg is not part of the FIR dialect and should never be used outside of
the (closed) conversion to LLVM IR.
Authors: Eric Schweitz, Jean Perier, Rajan Walia, et.al.
Differential Revision: https://reviews.llvm.org/D98063
The I/O runtime library code was failing to retain data in a buffer
from the current output record when flushing the buffer; this is
fatally wrong when the corresponding file cannot be repositioned,
as in the case of standard output to the console. So refine the
Flush() member function to retain a specified number of bytes,
rearrange the data as necessary (using existing code for read frame
management after moving it into a new member function), and add
a big comment to the head of the file to clarify the roles of the
various data members in the management of contiguous frames in
circular buffers.
Update: added a unit test.
Differential Revision: https://reviews.llvm.org/D99198
Binding labels start as expressions but they have to evaluate to
constant character of default kind, so they can be represented as an
std::string. Leading and trailing blanks have to be removed, so the
folded expression isn't exactly right anyway.
So all BIND(C) symbols now have a string binding label, either the
default or user-supplied one. This is recorded in the .mod file.
Add WithBindName mix-in for details classes that can have a binding
label so that they are all consistent. Add GetBindName() and
SetBindName() member functions to Symbol.
Add tests that verifies that leading and trailing blanks are ignored
in binding labels and that the default label is folded to lower case.
Differential Revision: https://reviews.llvm.org/D99208
Binding labels start as expressions but they have to evaluate to
constant character of default kind, so they can be represented as an
std::string. Leading and trailing blanks have to be removed, so the
folded expression isn't exactly right anyway.
So all BIND(C) symbols now have a string binding label, either the
default or user-supplied one. This is recorded in the .mod file.
Add WithBindName mix-in for details classes that can have a binding
label so that they are all consistent. Add GetBindName() and
SetBindName() member functions to Symbol.
Add tests that verifies that leading and trailing blanks are ignored
in binding labels and that the default label is folded to lower case.
Differential Revision: https://reviews.llvm.org/D99208
To match an interface or trait, users currently have to use the `MatchAny` tag. This tag can be quite problematic for compile time for things like the canonicalizer, as the `MatchAny` patterns may get applied to *every* operation. This revision adds better support by bucketing interface/trait patterns based on which registered operations have them registered. This means that moving forward we will only attempt to match these patterns to operations that have this interface registered. Two simplify defining patterns that match traits and interfaces, two new utility classes have been added: OpTraitRewritePattern and OpInterfaceRewritePattern.
Differential Revision: https://reviews.llvm.org/D98986
* Added a sanity check with `Clang_FOUND` to verify that find_package
succeeded
* Made sure that find_package won't use any of CMake's standard paths
to guarantee that only the path provided with CLANG_DIR is considered
(implemented through NO_DEFAULT_PATH)
* Made the call to get_filename_component more explicit (so that it is
clear what the base directory is)
* Updated comments to clarify what CLANG_DIR means
Differential Revision: https://reviews.llvm.org/D99088
When writing tests for a previous problem, I ran across situations where we
were not producing error messages for declarations of specific procedures of
generic interfaces where every other compiler I tested (except nvfotran) did.
I added a check to CheckExtantExternal() and renamed it since it now checks for
erroneous extant symbols generally.
I also removed a call to this function from processing for ENTRY statements,
since it seemed unnecessary and its presence caused bogus error messages.
I also added some tests for erroneous declarations where we were not producing
error messages.
Differential Revision: https://reviews.llvm.org/D99111
If you specify a specific procedure of a generic interface that has the same
name as both the generic interface and a preceding derived type, the compiler
would fail an internal call to CHECK(). I fixed this by testing for this
situation when processing specific procedures. I also added a test that will
cause the call to CHECK() to fail without this new code.
Differential Revision: https://reviews.llvm.org/D99085
This patch fixes a bug to allow ordered construct within a non-worksharing loop, also adds more sema checks.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D98733
Replace semantics::SymbolSet with alternatives that clarify
whether the set should order its contents by source position
or not. This matters because positionally-ordered sets must
not be used for Symbols that might be subjected to name
replacement during name resolution, and address-ordered
sets must not be used (without sorting) in circumstances
where the order of their contents affects the output of the
compiler.
All set<> and map<> instances in the compiler that are keyed
by Symbols now have explicit Compare types in their template
instantiations. Symbol::operator< is no more.
Differential Revision: https://reviews.llvm.org/D98878
Create test fixture for runtime tests which enables verification
of failure cases. Test some runtime IO APIs for failure cases.
Support testing efforts in D98303. Expand on effort discussed
in D98601.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D98652
Adds support for `-fget-symbols-sources` in the new Flang driver. All
relevant tests are updated to use the new driver when
`FLANG_BUILD_NEW_DRIVER` is set.
`RUN` lines in tests are updated so `-fsyntax-only`
comes before `-fget-symbols-sources`. That's because:
* both `-fsyntax-only` and `-fget-symbols-sources` are
action flags, and
* the new driver, flang-new, will only consider the right-most
action flag.
In other words, this change is needed so that the tests work with both
`f18` (requires both flags) and `flang-new` (only considers the last
action flag).
Differential Revision: https://reviews.llvm.org/D98191
Added basic parsing/sema/serialization support for interop directive.
Support for the 'init' clause.
Differential Revision: https://reviews.llvm.org/D98558
1. Generate the mapping for clauses between the parser class and the
corresponding clause kind for OpenMP and OpenACC using tablegen.
2. Add a common function to get the OmpObjectList from the OpenMP
clauses to avoid repetition of code.
Reviewed by: Kiranchandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D98603
In parser::AllCookedSources, implement a map from CharBlocks to
the CookedSource instances that they cover. This permits a fast
Find() operation based on std::map::equal_range to map a CharBlock
to its enclosing CookedSource instance.
Add a creation order number to each CookedSource. This allows
AllCookedSources to provide a Precedes(x,y) predicate that is a
true source stream ordering between two CharBlocks -- x is less
than y if it is in an earlier CookedSource, or in the same
CookedSource at an earlier position.
Add a reference to the singleton SemanticsContext to each Scope.
All of this allows operator< to be implemented on Symbols by
means of a true source ordering. From a Symbol, we get to
its Scope, then to the SemanticsContext, and then use its
AllCookedSources reference to call Precedes().
Differential Revision: https://reviews.llvm.org/D98743
`parser::AllocateObject` and `parser::PointerObject` can be represented
as typed expressions once analyzed. This simplifies the work for parse-tree
consumers that work with typed expressions to deal with allocatable and
pointer objects such as lowering.
This change also makes it easier to add typedExpr in the future by
automatically handling nodes that have this member when possible.
Changes:
- Add a `mutable TypedExpr typedExpr` field to `parser::PointerObject` and `parser::AllocateObject`.
- Add a `parser::HasTypedExpr<T>` helper to better share code relating to typedExpr in the parse tree.
- Add hooks in `semantics::ExprChecker` for AllocateObject and PointerObject nodes, and use
ExprOrVariable on it to analyze and set the tyedExpr field during
expression analysis. This required adding overloads for `AssumedTypeDummy`.
- Update check-nullify.cpp and check-deallocate.cpp to not re-analyze the StructureComponent but to
use the typedExpr field instead.
- Update dump/unparse to use HasTypedExpr and use the typedExpr when there is one.
Differential Revision: https://reviews.llvm.org/D98256
Implement INDEX in the runtime, reusing some infrastructure
(with generalization and renaming as needed) put into place
for its cousins SCAN and VERIFY.
I did not implement full Boyer-Moore substring searching
for the forward case, but did accelerate some advancement on
mismatches.
I (re)implemented unit testing for INDEX in the new gtest
framework, combining it with the tests that have recently
been ported to gtest for SCAN and VERIFY.
Differential Revision: https://reviews.llvm.org/D98553
The build was putting .mod files for intrinsic modules in
tools/flang/include/flang but the install puts them in include/flang,
as does the out-of-tree build. This confused things for the driver.
This change makes the build consistent with the install and simplifies
the flang script accordingly.
Also, clean up the cmake commands for building the .mod files.
Differential Revision: https://reviews.llvm.org/D98522
An older version of a function (Fortran::semantics::FindFunctionResult) was
left in flang/lib/Semantics/tools.cpp, and this breaks the static library
build due to a conflict with the intended final version in another
file and library. Remove the old code.
Differential Revision: https://reviews.llvm.org/D98568
Fortran permits a reference to a function whose result is a pointer
to be used as a definable variable in any context where a
designator could appear. This patch wrings out remaining bugs
with such usage and adds more testing.
The utility predicate IsProcedurePointer(expr) had a misleading
name which has been corrected to IsProcedurePointerTarget(expr).
Differential Revision: https://reviews.llvm.org/D98555
Make error message descriptors on runtime DE/ALLOCATE API calls constant.
Fix a bug in error message truncation/padding.
Differential Revision: https://reviews.llvm.org/D98551
Andrzej Warzynski