| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Accommodate operations with VALUE dummy arguments in the runtime support
for the REDUCE intrinsic function by splitting most entry points into
Reduce...Ref and Reduce...Value variants.
Further work will be needed in lowering to call the ...Value entry
points.
|
|
LBOUND and SHAPE runtime were added with an API that avoids making a
dynamic allocation for the small result storage. Update the UBOUND API
that was already there and used in lowering outside of the assumed-rank
case.
Add tests for the assumed-rank case.
|
|
Co-authored-by: David Parks <dparks@nvidia.com>
|
|
|
|
|
|
Add SHAPE runtime API (will be used for assumed-rank, lowering is
generating other cases inline).
I tried to make it in a way were there is no dynamic allocation in the
runtime/deallocation expected to be inserted by inline code for arrays
that we know are small (lowering will just always stack allocate a rank
15 array to avoid dynamic stack allocation or heap allocation).
|
|
Needed for SELECT RANK implementation. I want to stay away from
generating the `rank > 0 && ...` logic in FIR codegen for now.
|
|
When passing assumed-rank around, the lower bounds, dynamic type and
attribute must sometimes be updated to match the dummy attributes. See
https://github.com/llvm/llvm-project/blob/main/flang/docs/AssumedRank.md#annex-1---descriptor-temporary-for-the-dummy-arguments
for more details.
Doing it inline would require generating many instructions and block CFG
at the LLVM IR dialect level in codegen. Go for a simple runtime API
instead.
A matching fir.rebox_assumed_rank operation will be created and will
allow for easier future optimizations when inlining is done in FIR.
|
|
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode (`set_property(TARGET <target>
PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE
generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
|
|
The number of operations dedicated to CUF grew and where all still in
FIR. In order to have a better organization, the CUF operations,
attributes and code is moved into their specific dialect and files. CUF
dialect is tightly coupled with HLFIR/FIR and their types.
The CUF attributes are bundled into their own library since some
HLFIR/FIR operations depend on them and the CUF dialect depends on the
FIR types. Without having the attributes into a separate library there
would be a dependency cycle.
|
|
association. (#90642)
The new operation is just an abstract attribute that is attached to
[hl]fir.declare operations of dummy arguments of a subroutine.
Dummy arguments of the same subroutine refer to the same
fir.dummy_scope, so they can be recognized as such during FIR AliasAnalysis.
Note that the fir.dummy_scope must be specific to the runtime
instantiation of a subroutine, so any MLIR inlining/cloning should duplicate and
unique it vs using the same fir.dummy_scope for different runtime instantiations.
This is why I made it an operation rather than an attribute.
The new operation uses a write effect on DebuggingResource, same as
[hl]fir.declare, to avoid optimizing it away.
|
|
(#90406)
…ted. (#89998)" (#90250)
This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.
This change removes calls to the deprecated member functions. It does
not mark the functions deprecated yet and does not disable the
deprecation warning in TypeSwitch. This seems to cause problems with
MSVC.
|
|
(#89998)" (#90250)
This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.
This change is causing build failures on a bot
https://lab.llvm.org/buildbot/#/builders/216/builds/38157
|
|
See https://mlir.llvm.org/deprecation and
https://discourse.llvm.org/t/preferred-casting-style-going-forward.
|
|
List-directed output editing of REAL values will minimize the number of
digits that are emitted by calculating a decimal value that, if read
back in to a REAL variable of the same kind, would compare equal.
This behavior is causing some confusion when applied to list-directed
output of large REAL(2) values. Specifically, the value HUGE(0._2)
(which is 0x7bff in hex) is exactly 65504, but is edited to 65500. by
list-directed output, which selects F0 editing, minimizes the value to
6.55e4, and then formats it without the exponent.
This small patch changes that behavior for cases where the output of
digit-minimized F editing has no digits after the decimal point and
zeroes need to be emitted before it due to the decimal exponent. Digit
minimization is disabled in this case and the exact digits are emitted
instead.
|
|
We support 'A' output editing for INTEGER and REAL as an extension; it
turns out to be used as well for LOGICAL in application code.
|
|
Re-land https://github.com/llvm/llvm-project/pull/88395
Two build-bots were broken by the old version:
- https://lab.llvm.org/buildbot/#/builders/285/builds/245
- https://lab.llvm.org/buildbot/#/builders/21/builds/96988
The problem in both cases was that the compiler did not support
`std::filesystem` (which I use in the unit test).
I have removed the dependency upon std::filesystem because there isn't
an easy way to add the right linker options so that this is supported
correctly in all build environments [1]
[1] https://gitlab.kitware.com/cmake/cmake/-/issues/17834
---
This is a GNU extension:
https://gcc.gnu.org/onlinedocs/gfortran/ACCESS.html
Used in SALMON:
https://salmon-tddft.jp/download.html
Unfortunately the intrinsic takes a file path to operate on so there
isn't an easy way to make the test robust. The unit test expects to be
able to create, set read write and execute permissions, and delete files
called
std::filesystem::temp_directory_path() / <test_name>.<pid>
The test will fail if a file already exists with that name.
I have not implemented the intrinsic on Windows because this is wrapping
a POSIX system call and Windows doesn't support all of the permission
bits tested by the intrinsic. I don't have a Windows machine easily
available to check if Gfortran implements this intrinsic on Windows.
|
|
Reverts llvm/llvm-project#88395
This broke the powerpc buildbot. That build doesn't support using
`std::filesystem` in flang unit tests.
|
|
This is a GNU extension:
https://gcc.gnu.org/onlinedocs/gfortran/ACCESS.html
Used in SALMON:
https://salmon-tddft.jp/download.html
Unfortunately the intrinsic takes a file path to operate on so there
isn't an easy way to make the test robust. The unit test expects to be
able to create, set read write and execute permissions, and delete files
called
`std::filesystem::temp_directory_path() / <test_name>.<pid>`
The test will fail if a file already exists with that name.
I have not implemented the intrinsic on Windows because this is wrapping
a POSIX system call and Windows doesn't support all of the permission
bits tested by the intrinsic. I don't have a Windows machine easily
available to check if Gfortran implements this intrinsic on Windows.
|
|
SLES 15 comes with a GCC 7.5 as default, which does not support the
C++17 `<charconv>` header. This results in build errors when trying to
run `check-flang`.
This patch addresses that and uses the older `std::stol` for the string
-> number conversion to allow the SLES 15 buildbot
(https://lab.llvm.org/staging/#/builders/193) to turn green.
|
|
Straightforward computation of `A − FLOOR (A / P) * P` should
produce NaN, when P is infinity. The -menable-no-infs lowering
can still use the relaxed operations sequence.
|
|
Supports the REDUCE() transformational intrinsic function of Fortran
(see F'2023 16.9.173) in a manner similar to the existing support for
SUM(), PRODUCT(), &c. There are APIs for total reductions to scalar
results, and APIs for partial reductions that reduce the rank of the
argument by one.
This implementation requires more functions than other reductions
because the various possible types of the user-supplied OPERATION=
function need to be elaborated.
Once the basic API in reduce.h has been approved, later patches will
implement lowering.
REDUCE() is primarily for completeness, not portability; only one other
Fortran compiler implements this F'2018 feature today, and only some
types work correctly with it.
|
|
Excess hexadecimal digits were too significant for rounding purposes,
leading to inappropriate rounding away from zero for some modes.
|
|
Runtime unit tests used `new[]` to allocate memory, which then was
released using `free`.
This was detected by address sanitizer.
|
|
When` SmallVector<char>` is used as a backing storage, it can't be
assumed to end with a \x0. When creating a `StringRef` from it, pass the
length explicitly.
This was detected by address sanitizer.
|
|
When the result of real input editing underflows to zero, return -0.
when the input field had a minus sign.
|
|
The newly introduced `CUDAAttribute` is meant for CUDA attributes
associated with variable. In order to not clash with the future
attribute for function/subroutine, rename `CUDAAttribute` to
`CUDADataAttribute`.
|
|
This is a first simple patch to introduce a new FIR attribute to carry
the CUDA variable attribute information to hlfir.declare and fir.declare
operations. It currently lowers this information for local variables.
The texture attribute is omitted since it is rejected by semantic and
will not make its way to MLIR.
This new attribute is added as optional attribute to the hlfir.declare
and fir.declare operations.
|
|
functions (#78289)
This patch forwards the target CPU and features information from the
Flang frontend to MLIR func.func operation attributes, which are later
used to populate the target_cpu and target_features llvm.func
attributes.
This is achieved in two stages:
1. Introduce the `fir.target_cpu` and `fir.target_features` module
attributes with information from the target machine immediately after
the initial creation of the MLIR module in the lowering bridge.
2. Update the target rewrite flang pass to get this information from the
module and pass it along to all func.func MLIR operations, respectively
as attributes named `target_cpu` and `target_features`. These attributes
will be automatically picked up during Func to LLVM dialect lowering and
used to initialize the corresponding llvm.func named attributes.
The target rewrite and FIR to LLVM lowering passes are updated with the
ability to override these module attributes, and the `CodeGenSpecifics`
optimizer class is augmented to make this information available to
target-specific MLIR transformations.
This completes a full flow by which target CPU and features make it all
the way from compiler options to LLVM IR function attributes.
|
|
Compiler was rewriting SIZE(PACK(x, MASK)) to COUNT(MASK). It was
wrapping the COUNT call without a KIND argument (leading to INTEGER(4)
result in the characteristics) in an Expr<ExtentType> (implying
INTEGER(8) result), this lead to inconsistencies that later hit verifier
errors in lowering.
Set the KIND argument to the KIND of ExtentType to ensure the built
expression is consistent.
This requires giving access to some safe place where the "kind" name can
be saved and turned into a CharBlock (count has a DIM argument that
require using the KIND keyword here). For the FoldingContext that belong
to SemanticsContext, this is the same string set as the one used by
SemanticsContext for similar purposes.
|
|
Calls std::system() function and pass the command,
cmd on Windows or shell on Linux.
Command parameter is required, exitstatus is optional.
call system(command)
call system(command, exitstatus)
It calls `execute_command_line` runtime function with `wait` set to true.
---------
Co-authored-by: Yi Wu <yiwu02@wdev-yiwu02.arm.com>
|
|
An Ew.0(Ee) or Ew.0(Ee) output edit descriptor with a scale factor of
zero is an error condition, unless the output edit descriptor was
originally Gw.0(Ee), list-directed, or just E0/D0 with no .d part.
Fixes https://github.com/llvm/llvm-project/issues/78390.
|
|
up by init process (#77944)
When using `setsid()` in a child process created by `fork()`, a new
session is created, and the child becomes a session leader. If the
parent process terminates before the child, the child becomes an orphan
and is adopted by the `init` process. The `init` process will eventually
clean up the child process once it exits.
However, killing the parent does not automatically kill the child; the
child will continue running until it exits.
Proper cleanup involves waiting for the child process to exit using
`wait()` or `waitpid()` in the parent process to avoid zombie processes,
but this approach is not valid for `EXECUTE_COMMAND_LINE` with async
mode.
Fix: https://github.com/llvm/llvm-project/issues/77803
|
|
If `generateLLVMIR()` fails, we still continue using the module we
failed to generate which causes a seg fault if LLVM code-gen failed for
some reason or another. This commit fixes this issue.
Re-applies PR #78269 and adds LLVM and MLIR dependencies that were
missed in the PR. The missing libs were: `LLVMCore` & `MLIRIR`.
This reverts commit 4fc75062745eb5232ea60c37b9ffe61177efa12a.
|
|
(#78667)
This reverts commit 99cae9a44fca4cfbd6ee82f196051cbdf6571fa1.
Temporarily until I reproduce and fix a linker issue:
```
FAILED: tools/flang/unittests/Frontend/FlangFrontendTests
...
/usr/bin/ld: tools/flang/unittests/Frontend/CMakeFiles/FlangFrontendTests.dir/CodeGenActionTest.cpp.o: undefined reference to symbol '_ZN4llvm11LLVMContextC1Ev'
/usr/bin/ld: /work1/omp-nightly/build/git/trunk18.0/build/llvm-project/lib/libLLVMCore.so.18git: error adding symbols: DSO missing from command line
```
|
|
|
|
The template function call CheckDescriptorEqInt((exitStat.get(), 127) is
deduced to have INT_T equal to std::int32_t instead of std::int64_t, but
the length descriptor points to a 64-byte storage. The comparison does
not work in a big endian.
Co-authored-by: Mark Danial <mark.danial@ibm.com>
|
|
The `_POSIX_SOURCE` macro is defined without a value on AIX. Change the check to `defined(_POSIX_SOURCE)`.
|
|
As NAMELIST output is a variant of list-directed output, its editing
must produce leading spaces on (most) output records to effect carriage
control. These spaces are required by the language standard and
implemented by nearly all other Fortran compilers (except GNU).
Fixes https://github.com/llvm/llvm-project/issues/76798.
|
|
Clean up recently-added code to avoid warnings and to eliminate a
needless dependence from the Fortran runtime support library on C++
runtimes.
|
|
This patch fixes:
flang/unittests/Runtime/CommandTest.cpp:702:14: error: variable
length arrays are a C99 feature [-Werror,-Wvla-extension]
|
|
18af032c0e16252effeb6dfd02113812388f1d31 broke the Solaris build:
```
/vol/llvm/src/llvm-project/dist/flang/runtime/extensions.cpp:60:24: error: use of undeclared identifier 'LOGIN_NAME_MAX'
60 | const int nameMaxLen{LOGIN_NAME_MAX + 1};
| ^
/vol/llvm/src/llvm-project/dist/flang/runtime/extensions.cpp:61:12: warning: variable length arrays in C++ are a Clang extension [-Wvla-cxx-extension]
61 | char str[nameMaxLen];
| ^~~~~~~~~~
/vol/llvm/src/llvm-project/dist/flang/runtime/extensions.cpp:61:12: note: initializer of 'nameMaxLen' is unknown
/vol/llvm/src/llvm-project/dist/flang/runtime/extensions.cpp:60:13: note: declared here
60 | const int nameMaxLen{LOGIN_NAME_MAX + 1};
| ^
```
`flang/unittests/Runtime/CommandTest.cpp` has the same issue.
As documented in Solaris 11.4 `limits.h(3HEAD)`, `LOGIN_NAME_MAX` can be
undefined. To determine the value, `sysconf(3C)` needs to be used
instead.
Beside that portable method, Solaris also provides a non-standard
`LOGNAME_MAX` which could be used, but I've preferred the standard route
instead which would support other targets with the same issue.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
|
|
(#71222)
reference to gfortran fdate
https://gcc.gnu.org/onlinedocs/gfortran/FDATE.html
usage:
```fortran
CHARACTER(32) :: time
CALL fdate(time)
WRITE(*,*) time
```
fdate is used in the ECP proxy application
https://proxyapps.exascaleproject.org/app/minismac2d/
https://github.com/Mantevo/miniSMAC/blob/f90446714226eeef650b78bce06ca4967792e74d/ref/smac2d.f#L1570
`fdate` now produce the same result on flang, compare to gfortran, where
If the length is too short to fit completely, blank return.
```fortran
character(20) :: string
call fdate(string)
write(*, *) string, "X"
```
```bash
$ ../build-release/bin/flang-new test.f90
$ ./a.out
X
```
If length if larger than it requires(24), fill the rest of buffer space.
```fortran
character(30) :: string
call fdate(string)
write(*, *) string, "X"
```
```bash
$ ../build-release/bin/flang-new test.f90
$ ./a.out
Wed Nov 15 16:59:13 2023 X
```
The length value is hardcoded, because:
```c++
// Day Mon dd hh:mm:ss yyyy\n\0 is 26 characters, e.g.
// Tue May 26 21:51:03 2015\n\0
```
---------
Co-authored-by: Yi Wu <yiwu02@wdev-yiwu02.arm.com>
|
|
implementation (#74077)
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>
|
|
|
|
runtime test case (NFC) (#76990)
The shift2 array only has 1 dimension but the lower bound for a second
dimension is being set causing a seg fault on AIX.
Co-authored-by: Mark Danial <mark.danial@ibm.com>
|
|
When rounding what otherwise would have been a result that underflowed
to zero up (RU) or down (RD) to the least magnitude nonzero subnormal
number, ensure that the original exponent value doesn't perturb the
result.
|
|
The Fortran standard says that overflow input cases in some rounding
modes (RZ, RD, RU) should round to a "representable" number. Some
Fortran compilers interpret this to mean +/-HUGE(), some as +/-Inf.
Follow the precedent of gfortran and the Intel compilers.
|
|
When the result of NEAREST() has an exponent less than that of the
argument (e.g., NEAREST(1.,-1.) and NEAREST(-1.,1.)), the result was
wrong, because the increment value uses the result of SPACING() in terms
of the argument. Fix by just calling into the C runtime routine
std::nextafter().
|
|
A zero 'd' digit count in EX output editing has a meaning that's
distinct from other numeric output editing descriptors, and I missed
this in my initial implementation of the feature. d==0 means that the
runtime should emit hexadecimal digits after the (hexa)decimal point
until all of the rest of them would be zero.
|
