This patch add support of intrinsics Fortran 2008 EXECUTE_COMMAND_LINE.
The patch contains both the lowering and the runtime code and works on
both Windows and Linux. The patch contains a list of commits, to convey
the authorship and the history of changes. Some implementation specifics
or status has been added to `flang/docs/Intrinsics.md`.
I have provided a summary of the usage and the options required for the
`EXECUTE_COMMAND_LINE intrinsic`. The intrinsic supports both a
synchronous
(by default) and an asynchronous option.
| System | Mode | Implemention |
|---------|-------|---------------------------|
| Linux | Sync | std::system() |
| Windows | Sync | std::system() |
| Linux | Async | fork() |
| Windows | Async | CreateProcess |
Support for the SYSTEM GNU extension will be added in a separate PR.
Co-authored with @jeffhammond
---------
Signed-off-by: Jeff Hammond <jeff.science@gmail.com>
Co-authored-by: Jeff Hammond <jeff.science@gmail.com>
Co-authored-by: Yi Wu <yiwu02@wdev-yiwu02.arm.com>
Fortran 2023 subclause 13.7.2.3.8 discusses input rounding only in the
context of decimal-to-binary conversion. There is no mention of rounding
for hexadecimal floating-point input conversion. At least one Fortran
compiler seems to have interpreted this silence as implying no rounding.
(Note that this is not the same thing as rounding to zero (RZ), which
would return +/-HUGE() for overflow.)
Nearly every Fortran compiler supports the extension of NAMELIST input
into a storage sequence identified by its initial scalar array element.
For example,
&GROUP A(1) = 1. 2. 3. /
should be processed as if the input had been
&GROUP A(1:) = 1. 2. 3. /
Fixes llvm-test-suite/Fortran/gfortran/regression/namelist_24.f90.
The compiler doesn't USE-associate names of intrinsic procedures from
modules (in the absence of ONLY:), so that the associating scope doesn't
get populated with names of intrinsics that were used only in
declarations (e.g., SELECTED_REAL_KIND). A recent bug report (below)
shows that we should modify that policy in the case of names that appear
in explicit INTRINSIC attribute statements. The behaviors of other
Fortran compilers are not consistent and the requirements of the
standard are not clear; this fix follows the precedent set by gfortran
and nvfortran.
Fixes https://github.com/llvm/llvm-project/issues/72084.
At present, when building static or shared libraries, Flang adds
`-lFortran_main.a` (or `/WHOLEARCHIVE:Fortran.*.lib` pon Windows) to the
link line. This leads to the problem that `_QQmain` and
`_QQEnvironmentDefaults` (as of the time of this PR) are symbols marked
as used, while `main` is being defined. This should not happen and this
PR fixes this by detecting if `-shared` or `-static` is used on the
Flang command line and removing the static `Fortran_main` library.
---------
Co-authored-by: kkwli <kkwli@users.noreply.github.com>
This document describes the aspects of Fortran descriptor management
in the offload data environment and how this semantics can be
represented using MLIR OpenACC dialect.
In the document I tried to clarify some parts of the OpenACC
specification that seemed unclear to me, e.g. where the spec allowed different
interpretations (in my opinion) or did not specify the actual runtime
behavior. I tried to demonstrate how this ambiguity can affect user
programs with examples.
The document proposes using `attachRecipe` on the data operations
to represent the non-trivial pointer attachment semantics for variables
represented by descriptors. The recipe provides the actual
implementation of the pointer attachment, e.g. we can call an F18 offload runtime
function that will perform all necessary checks and actions.
It is unclear at this point if we want to expose the implementation
details in FIR, otherwise, the recipe could have contained more low
level acc operations such as is_present lookups, host to device
memory copies, etc.
Adjust the depth (number of #) for some sections.
Move an underscore prefix to a suffix in an example to let the Fortran
parser in the documentation generator pass.
Fixes section depth and removes annotation of source as HLFIR since this
is not currently understood by the lexer. Fixing these issues help
reduce warnings in the documentation CI for LLVM.
Adding this section ensures that the documentation generated by
mlir-tblgen for all the FIR operations are at the correct depth.
FIROperations are at depth 3, the new section is at depth 2. This fixes
the "Non-consecutive header level increase; H1 to H3" warning in
FIRLangRef.md.
Fortran free form line continuation with '&' works with this compiler
even across the end of an included source file, as it does with most
other Fortran compilers. This extension should be documented.
A NULL() pointer without MOLD= cannot be allowed to be associated with
an assumed-rank dummy argument, as its rank is not well-defined and
neither the RANK() intrinsic function or the SELECT RANK construct will
work in the callee.
Change the separator in the `uniqueCGIdent` method to `X`. This change
is required to enable OpenMP offloading for the NVPTX target, as dots
are not valid identifiers in PTX and `uniqueCGIdent` is used to mangle
some literals. Follow up patches will change the remainder of `.`
appearances in names to `X` and add support for the NVPTX target.
As an extension, accept the redundant use of the CONTIGUOUS attribute
when applied to scalars and to simply contiguous objects, with a
portability warning.
…fter macro expansion
When compiler directives (!$omp) and/or their continuations (!$omp &)
are produced by macro expansion, handle those continuations. Also allow
a continuation marker (&) to appear in a macro actual argument.
As is already supported as a common extension for intrinsic functions
like DIM, allow distinct kinds of integer actual arguments to the
MIL-STD bit intrinsic functions IAND, IEOR, and IOR, with the kind of
the result being the largest of the kinds of the operands. (Though one
could make a case that IAND should return the smallest kind of its
operands, that's not what other compilers do.)
Some compilers allow the `$acc routine(<name>)` to be placed at the
program unit level. To be compatible, this patch enables the use of acc
routine at this level. These acc routine directives must have a name.
I would like to start a discussion about the ways for modifying
the current trampolines approach for Fortran internal procedures
used as actual arguments or pointer targets.
As Peter Klausler noted before the current approach implies security
risks due to writeable and executable stack requirement. We may need
to agree on a new scheme that does not have this issue.
Relax the parser to accept scalar integer expression in addition to
scalar logical expression. The parser now accepts scalar expression and
the semantic checks its type.
Fortran allows forward references to type names, which can lead to
ambiguity when coupled with host association, as in:
module m
type ambiguous; integer n; end type
contains
subroutine s
type(ambiguous), pointer :: variable
type t
type(ambiguous), pointer :: component
end type
type ambiguous; real x; end type
end
end
Some other compilers resolve to a host association, some resolve to a
forward reference. This compiler will now emit an error.
Follow up up of https://github.com/llvm/llvm-project/pull/67693
- Zero initialize uninitialized components of saved derived type entity
with a default initial value.
- Zero initialize uninitialized storage of common blocks with a member
with an initial value.
- Zero initialized uninitialized saved equivalence
This removes all the cases where fir.global are created with an initial
value that results in an undef in LLVM for part of the global, leading
in surprising LLVM optimizations at -O2 for Fortran folks that expects
there saved variables to be zero initialized if there is no explicit or
default initial value.
This is not standard but is vastly expected by existing code.
This was implemented by https://reviews.llvm.org/D149877 for simple
scalars, but MLIR lacked a generic way to deal with aggregate types
(arrays and derived type).
Support was recently added in
https://github.com/llvm/llvm-project/pull/65508. Leverage it to zero
initialize all types.
…mmy argument
Several compilers accept a null pointer (with or without a MOLD=) as an
actual argument for association with an INTENT(IN) allocatable dummy
argument. At runtime, the allocatable dummy argument appears to be in
the unallocated state. This seems useful, unambiguous, unlikely to
invalidate conforming code, and works with Intel, NAG, & XLF, so it
should be supported with an optional portability warning in this
compiler as well.
The Fortran standards require (F'2023 C745) that a derived type with the
SEQUENCE attribute have at least one component. No Fortran compiler
actually enforces this constraint. Accept this usage with a warning.
Some compilers accept `!$acc data` without any clauses. For portability
reason, this patch relaxes the strict error to a simple portability warning.
Reviewed By: razvanlupusoru, vzakhari
Differential Revision: https://reviews.llvm.org/D159019
This reverts commit 02fa9fc018db5b757a4ce129d85d64efefc8645c.
Commit message and content does not match. Revert to commit with
a proper commit message.
Some compilers accept `!$acc end loop` associated with an `!$acc loop`
directive. This patch updates the acc loop parser to accept it as well.
The parser is also updated to be stricter on the following statement
to match the OpenACC combined construct parser.
The rewrite canonicalization is not a rewrite anymore and the naming
will be updated in a follow up patch for the Loop and Combined constructs.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D159015
This is a big refactor of the clang driver's option handling to use
the Visibility flags introduced in https://reviews.llvm.org/D157149.
There are a few distinct parts, but they can't really be split into
separate commits and still be made to compile.
1. We split out some of the flags in ClangFlags to ClangVisibility.
Note that this does not include any subtractive flags.
2. We update the Flag definitions and OptIn/OptOut constructs in
Options.td by hand.
3. We introduce and use a script, update_options_td_flags, to ease
migration of flag definitions in Options.td, and we run that on
Options.td. I intend to remove this later, but I'm committing it so
that downstream forks can use the script to simplify merging.
4. We update calls to OptTable in the clang driver, cc1as, flang, and
clangd to use the visibility APIs instead of Include/Exclude flags.
5. We deprecate the Include/Exclude APIs and add a release note.
*if you are running into conflicts with this change:*
Note that https://reviews.llvm.org/D157150 may also be the culprit and
if so it should be handled first.
The script in `clang/utils/update_options_td_flags.py` can help. Take
the downstream side of all conflicts and then run the following:
```
% cd clang/include/clang/Driver
% ../../../utils/update_options_td_flags.py Options.td > Options.td.new
% mv Options.td.new Options.td
```
This will hopefully be sufficient, please take a look at the diff.
Differential Revision: https://reviews.llvm.org/D157151
At least one other Fortran compiler supports the use of unrestricted intrinsic
functions as specific procedures in generic interfaces, and the usage seems
to be both useful and unambiguous. Support it with a portability warning.
Fixes llvm-test-suite/Fortran/gfortran/regression/pr95500.f90.
Differential Revision: https://reviews.llvm.org/D157333
The prescanner performs implicit line continuation when it looks
like the parenthesized arguments of a call to a function-like macro
may span multiple lines. In an attempt to work more like a
Fortran-oblivious C preprocessor, the prescanner will act as if
the following lines had been continuations so that the function-like
macro could be invoked.
This still seems like a good idea, but a recent bug report on
LLVM's GitHub issue tracker shows one way in which it could trigger
inadvertently and mess up a program. So this patch makes the
conditions for implicit line continuation much more strict.
First, the leading parenthesis has to have been preceded by an
identifier that's known to be a macro name. (It doesn't have to
be a function-like macro, since it's possible for a keyword-like
macro to expand to the name of a function-like macro.) Second,
no macro definition can ever have had unbalanced parentheses in
its replacement text.
Also cleans up some parenthesis recognition code to fix some
issues found in testing, so that a token with leading or trailing
spaces can still be recognized as a parenthesis or comma.
Fixes https://github.com/llvm/llvm-project/issues/63844.
Differential Revision: https://reviews.llvm.org/D155499
