Under current configuration, the permission of `flang` after installation is 700.
This could bring a problem for system administrators who build and install flang
for other users, which only the user who builds LLVM can execute it, and others
can not. In this patch, the explicit permission setting in the `install` command
is removed, and let CMake determine what perssion to be used like other components.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D87783
According to section 9.4.1, paragraph 3,
If the starting point is greater than the ending point, the substring has
length zero
But the compilers code for substring processing was failing a call to `CHECK()`
in this case. I fixed this by just setting the number of items in the
resulting string to 0 for this situation.
Differential Revision: https://reviews.llvm.org/D87799
MSVC tries to expand templates that are in the false-branch of a `if constexpr` construct. In this case, the condition checks whether a tuple has at least one element and then is trying to access it using `std::get<0>`, which fails when the tuple has 0 elements.
The workaround is to extract that case into a separate method.
This patch is part of the series to make flang compilable with MS Visual Studio <http://lists.llvm.org/pipermail/flang-dev/2020-July/000448.html>.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D87728
Adds a new GettingInvolved page to documentation which provides details about
mailing list, chats and calls.
Adds a sidebar page which provides common links on
all documentation pages.
The links include:
- Getting Started
- Getting Involved
- Github Repository
- Bug Reports
- Code Review
Depends on https://reviews.llvm.org/D87242
Reviewed By: richard.barton.arm
Differential Revision: https://reviews.llvm.org/D87270
The Fortran standard discusses BZ mode (treat blanks as zero digits)
explicitly in its effect on the editing of the digits prior to the
exponent part, but doesn't mention it in description of the
exponent part. Other compilers honor BZ mode in the exponent,
so we should do so too. So "1 e 1 " is 1.E11 in BZ mode.
Differential Revision: https://reviews.llvm.org/D87653
C-style /*comments*/ are removed during preprocessing directive
tokenization, but Fortran !comments need to be specifically
allowed.
Fixes LLVM bugzilla 47466.
Differential Revision: https://reviews.llvm.org/D87638
A type name in an IMPLICIT declaration that was later used in a PARAMETER
statement caused problems because the default symbol scope had not yet been
initialized. I avoided dereferencing in the situation where the default scope
was uninitialized and added a test that triggers the problem.
Also, once I corrected the bad dereference, the compiler was putting out
misleading error messages. The underlying error us due to violating section
7.5.10, paragraph 4, which states:
A structure constructor shall not appear before the referenced type is
defined.
I fixed this by testing to see if a type that is used in a structure
constructor is forward referenced.
Differential Revision: https://reviews.llvm.org/D87535
The std::string holding the content of a CookedSource no longer
needs to be exposed in its API after the recent work that allows
the parsing context to hold multiple instances of a CookedSource.
So clean the API. These changes were extracted from some work in
progress that was made easier by the API changes.
Differential Revision: https://reviews.llvm.org/D87635
Now backends spell out which namespace they want to be in, instead of relying on
clients #including them inside already-opened namespaces. This also means that
cppNamespaces should be fully qualified, and there's no implicit "::mlir::"
prepended to them anymore.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D86811
Change the analyzed form of type-bound assignment to match that of call
statements. Resolve the binding name to a specific subprogram when
possible by using `GetBindingResolution`. Otherwise leave it as a
type-bound procedure call.
Differential Revision: https://reviews.llvm.org/D87541
Integer case values were being compared as unsigned by operator<
on evaluate::value::Integer. Change that to signed so that overlap
can be detected correctly.
Explicit CompareUnsigned and BLT are still available if unsigned
comparison is needed.
Fixes https://bugs.llvm.org/show_bug.cgi?id=47309
Differential Revision: https://reviews.llvm.org/D87595
A type name in an IMPLICIT declaration that was later used in a PARAMETER
statement caused problems because the default symbol scope had not yet been
initialized. I avoided dereferencing in the situation where the default scope
was uninitialized and added a test that triggers the problem.
Differential Revision: https://reviews.llvm.org/D87535
Define Fortran::Semantics::Scope::GetName in the header so it is available
to Fortran::Evaluate::Tool::AttachDeclaration without a circular dependency
introduced in 82edd42.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D87505
Add a new index page to be the Flang documentation mainpage instead of
Overview.md, which jumps straight into the compiler Design. The index file
needs to be in .rst format to use the toctree directive to create table of
contents.
Also use the sphinx_markdown_tables extension to generate html tables form
markdown.
A number of additional style changes to the existing docs were needed to make
this work well:
* Convert all headings to the # style, which works better with toctree's
titlesonly option. Ensure that there is only one top-level heading per
document.
* Add a title to documents that don't have one for rendering on the index.
* Convert the grammar docs from .txt to .md. for better rendering
* Fixed broken link to a section in another document - sphinx does not seem to
support anchor links in markdown files.
Depends on D87226
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D87242
Summary:
This is the first patch implementing the new Flang driver as outlined in [1],
[2] & [3]. It creates Flang driver (`flang-new`) and Flang frontend driver
(`flang-new -fc1`). These will be renamed as `flang` and `flang -fc1` once the
current Flang throwaway driver, `flang`, can be replaced with `flang-new`.
Currently only 2 options are supported: `-help` and `--version`.
`flang-new` is implemented in terms of libclangDriver, defaulting the driver
mode to `FlangMode` (added to libclangDriver in [4]). This ensures that the
driver runs in Flang mode regardless of the name of the binary inferred from
argv[0].
The design of the new Flang compiler and frontend drivers is inspired by it
counterparts in Clang [3]. Currently, the new Flang compiler and frontend
drivers re-use Clang libraries: clangBasic, clangDriver and clangFrontend.
To identify Flang options, this patch adds FlangOption/FC1Option enums.
Driver::printHelp is updated so that `flang-new` prints only Flang options.
The new Flang driver is disabled by default. To enable it, set
`-DBUILD_FLANG_NEW_DRIVER=ON` when configuring CMake and add clang to
`LLVM_ENABLE_PROJECTS` (e.g. -DLLVM_ENABLE_PROJECTS=“clang;flang;mlir”).
[1] “RFC: new Flang driver - next steps”
http://lists.llvm.org/pipermail/flang-dev/2020-July/000470.html
[2] “RFC: Adding a fortran mode to the clang driver for flang”
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html
[3] “RFC: refactoring libclangDriver/libclangFrontend to share with Flang”
http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
[4] https://reviews.llvm.org/rG6bf55804924d5a1d902925ad080b1a2b57c5c75c
co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Reviewed By: richard.barton.arm, sameeranjoshi
Differential Revision: https://reviews.llvm.org/D86089
When we define a derived type that extends another derived type, we can then
create a structure constructor that contains values for the fields of both the
child type and its parent. The compiler's internal representation of that
value contains the name of the parent type where a component name would
normally appear. This caused an assert during contant folding.
There are three cases for components that appear in structure constructors.
The first is the normal case of a component appearing in a structure
constructor for its type.
The second is a component of the parent (or grandparent) type appearing in a
structure constructor for the child type.
The third is the parent type component, which can appear in the structure
constructor of its child.
There are also cases where the component can be arrays.
I created the test case folding12.f90 that covers all of these cases and
modified the code to handle them.
Most of my changes were to the "Find()" method of the type
"StructureConstructor" where I added code to cover the second and third cases
described above. To handle these cases, I needed to create a
"StructureConstructor" for the parent type component and return it. To handle
returning a newly created "StructureConstructor", I changed the return type of
"Find()" to be "std::optional" rather than an ordinary pointer.
This change supersedes D86172.
Differential Revision: https://reviews.llvm.org/D87151
Change how generic operators and assignments are checked for
distinguishable procedures. Because of how they are invoked, available
type-bound generics and normal generics all have to be considered
together. This is different from how generic names are checked.
Move common part of checking into DistinguishabilityHelper so that it
can be used in both cases after the appropriate procedures have been
added.
Cache result of Procedure::Characterize(Symbol) in a map in
CheckHelper so that we don't have to worry about passing the
characterized Procedures around or the cost of recomputing them.
Add MakeOpName() to construct names for defined operators and assignment
for using in error messages. This eliminates the need for different
messages in those cases.
When the procedures for a defined operator or assignment are undistinguishable,
include the type name in the error message, otherwise it may be ambiguous.
Add missing check that procedures for defined operators are functions
and that their dummy arguments are INTENT(IN) or VALUE.
Differential Revision: https://reviews.llvm.org/D87341
For out of tree builds, the user generally needs to specify LLVM_DIR and
MLIR_DIR on the command line so that the correct LLVM and MLIR
installations are picked up.
If the provided paths are absolute, everything works fine, however for
buildbots it is customary to work with relative paths, and that makes it
difficult for CMake to find the right modules to include.
This patch changes CMakeLists.txt to convert LLVM_DIR and MLIR_DIR to
absolute paths before adding them to CMAKE_MODULE_PATH. The inputs are
assumed to be relative to the source directory (llvm-project/flang).
Differential Revision: https://reviews.llvm.org/D87083
Msvc crashes with "INTERNAL COMPILER ERROR" when iterating over an `std::initializer_list` in a constexpr constructor. Explicitly use the iterator instead.
This patch is part of the series to [[ http://lists.llvm.org/pipermail/flang-dev/2020-July/000448.html | make flang compilable with MS Visual Studio ]].
Reviewed By: isuruf
Differential Revision: https://reviews.llvm.org/D86425
These are owned by an instance of a new class AllCookedSources.
This removes the need for a Scope to own a string containing
a module's cooked source stream, and will enable errors to be
emitted when parsing module files in the future.
Differential Revision: https://reviews.llvm.org/D86891
The DumpSymbolsSources() routine ordered its output by the addresses
of the names of the symbols, and was susceptible to variation across
environments. Fixed by using a multimap using the values of the names.
Differential Revision: https://reviews.llvm.org/D87035
Fixed some version information in flang/f18:
- fixed the behavior of the -v switch: this flag enables verbosity with used with arguments, but just displays the version when used alone (related to this bug: https://bugs.llvm.org/show_bug.cgi?id=46017)
- added __FLANG, __FLANG_MAJOR__, __FLANG_MINOR__ and __FLANG_PATCHLEVEL__ (similar to their __F18* counterparts) for compatibility purpose
Reviewed By: AlexisPerry, richard.barton.arm, tskeith
Differential Revision: https://reviews.llvm.org/D84334
Don't use just 128-bit integer as the type for integer
CASE statement constants. Use the actual type of the
literal constants that appeared.
Differential Review: https://reviews.llvm.org/D86875
Conformance checking of the shapes of the operands of
array expressions can't, of course, always be done at
compilation time; but when the shapes are known and
nonconformable, we should catch the errors that we can.
Differential Revision: https://reviews.llvm.org/D86887
Change the expression representation TypeParamInquiry from being
a class that's templatized on the integer KIND of its result into
a monomorphic representation that results in a SubscriptInteger
that can then be converted.
This is a minor simplification, but it's worth doing because
it is believed to also be a work-around for bugs in the MSVC
compiler with overload resolution that affect the expression
traversal framework.
Differential Revision: https://reviews.llvm.org/D86551
Compilation of the following program currently generates a warning message:
i = 1
if (i .eq. 0) then
write(6, 200) i
200 format (I8)
end if
write(6, 200) i
end
x.f90:6:9: Label '200' is not in scope
write(6, 200) i
^^^^^^^^^^^^^^^
Whereas branch targets must conform to the Clause 11.1.2.1 program
requirement "Transfer of control to the interior of a block from
outside the block is prohibited, ...", this doesn't apply to format
statement references.
When an error is associated with a symbol, it was marked with a flag
from Symbol::Flag. The problem with that is that you need a mutable
symbol to do that. Instead, store the set of error symbols in the
SemanticsContext. This allows for some const_casts to be eliminated.
Also, improve the internal error that occurs if SetError is called
but no fatal error has been reported.
Differential Revision: https://reviews.llvm.org/D86740
This patch fix the prasing for the gang-arg values for the gang clause. It also adds
some clause validity tests for the loop construct.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D86584
The tile clause in OpenACC 3.0 imposes some restriction. Element in the tile size list are either * or a
constant positive integer expression. If there are n tile sizes in the list, the loop construct must be immediately
followed by n tightly-nested loops.
This patch implement these restrictions and add some tests.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D86655
This applies the same fix that D84748 did for macro definitions.
Appropriate include path is now automatically set for all libraries
which link against gtest targets, which avoids the need to set
include_directories in various parts of the project.
Differential Revision: https://reviews.llvm.org/D86616
A number of I/O syntax rules involve variables that will be written to,
and must therefore be definable. This includes internal file variables,
IOSTAT= and IOMSG= specifiers, most INQUIRE statement specifiers, a few
other specifiers, and input variables. This patch checks for
these violations, and implements several additional I/O TODO constraint
checks.
Differential Revision: https://reviews.llvm.org/D86557
When an illegal character appears in Fortran source (after
preprocessing), catch and report it in the prescanning phase
rather than leaving it for the parser to cope with.
Differential Revision: https://reviews.llvm.org/D86553
Accept and represent "global" compiler directives that appear
before and between program units in a source file.
Differential Revision: https://reviews.llvm.org/D86555
If the label field is empty, and macro replacement occurs,
the rescanned text might be misclassified as a comment card
if it happens to begin with a C or a D. Insert a leading
space into these otherwise empty label fields.
Fixes https://bugs.llvm.org/show_bug.cgi?id=47173
If an error has occurred a symbol may have a DeclTypeSpec but no
valid DynamicType. There is no need to compute the size of erroneous
symbols.
Also, we only need to process object entities and procedure entities.
All other kinds of symbols can be skipped.
This fixes another problem revealed by https://bugs.llvm.org/show_bug.cgi?id=47265
Differential Revision: https://reviews.llvm.org/D86484
A specification expression can reference an implicitly declared variable
in the host procedure. Because we have to process specification parts
before execution parts, this may be the first time we encounter the
variable. We were assuming the variable was implicitly declared in the
scope where it was encountered, leading to an error because local
variables may not be referenced in specification expressions.
The fix is to tentatively create the implicit variable in the host
procedure because that is the only way the specification expression can
be valid. We mark it with the flag `ImplicitOrError` to indicate that
either it must be implicitly defined in the host (by being mentioned in
the execution part) or else its use turned out to be an error.
We need to apply the implicit type rules of the host, which requires
some changes to implicit typing.
Variables in common blocks are allowed to appear in specification expressions
(because they are not locals) but the common block definition may not appear
until after their use. To handle this we create common block symbols and object
entities for each common block object during the `PreSpecificationConstruct`
pass. This allows us to remove the corresponding code in the main visitor and
`commonBlockInfo_.curr`. The change in order of processing causes some
different error messages to be emitted.
Some cleanup is included with this change:
- In `ExpressionAnalyzer`, if an unresolved name is encountered but
no error has been reported, emit an internal error.
- Change `ImplicitRulesVisitor` to hide the `ImplicitRules` object
that implements it. Change the interface to pass in names rather
than having to get the first character of the name.
- Change `DeclareObjectEntity` to have the `attrs` argument default
to an empty set; that is the typical case.
- In `Pre(parser::SpecificationPart)` use "structured bindings" to
give names to the pieces that make up a specification-part.
- Enhance `parser::Unwrap` to unwrap `Statement` and `UnlabeledStatement`
and make use of that in PreSpecificationConstruct.
Differential Revision: https://reviews.llvm.org/D86322
Need to build sphinx using below flags to Cmake
`-DLLVM_ENABLE_SPHINX=ON -DSPHINX_WARNINGS_AS_ERRORS=OFF`.
Generate html docs using cmake target
`docs-flang-html`
Generated html files should be at `build/tools/flang/docs/html`.
Patch in series from the dicussion on review
https://reviews.llvm.org/D85828
After this patch the markdown docmentation must be written using guide in-
`llvm/docs/MarkdownQuickstartTemplate.md`
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D86131
Valentin Clement