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.
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>
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.
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`.
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/f904467142/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>
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>
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.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
A tricky case in Fw.d output editing is when the value needs to be
rounded either to a signed zero or away from zero to a power of ten
(1.0, 0.1, &c.). A bug report for LLVM on GitHub (#74274) exposed a bug
in this code in the case of Fw.0 editing where a value just over 0.5 was
rounded incorrectly to 0 rather than 1 when no fractional digits were
requested.
Rework that algorithm a little, ensuring that the initial
binary->decimal conversion produces at least one digit, and coping
correctly with the rounding of an exact 0.5 value for Fw.0 editing
(rounding it to the nearest even decimal, namely 0, following
near-universal compiler-dependent behavior in other Fortrans).
Fixes https://github.com/llvm/llvm-project/issues/74274.
The template function call `CheckDescriptorEqInt(length.get(), 16)` 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.
Preliminary patch to change lowering/code generation to use
llvm::DataLayout information instead of generating "sizeof" GEP (see
https://github.com/llvm/llvm-project/issues/71507).
Fortran Semantic analysis needs to know about the target type size and
alignment to deal with common blocks, and intrinsics like
C_SIZEOF/TRANSFER. This information should be obtained from the
llvm::DataLayout so that it is consistent during the whole compilation
flow.
This change is changing flang-new and bbc drivers to:
1. Create the llvm::TargetMachine so that the data layout of the target
can be obtained before semantics.
2. Sharing bbc/flang-new set-up of the
SemanticConstext.targetCharateristics from the llvm::TargetMachine. For
now, the actual part that set-up the Fortran type size and alignment
from the llvm::DataLayout is left TODO so that this change is mostly an
NFC impacting the drivers.
3. Let the lowering bridge set-up the mlir::Module datalayout attributes
since it is doing it for the target attribute, and that allows the llvm
data layout information to be available during lowering.
For flang-new, the changes are code shuffling: the `llvm::TargetMachine`
instance is moved to `CompilerInvocation` class so that it can be used
to set-up the semantic contexts. `setMLIRDataLayout` is moved to
`flang/Optimizer/Support/DataLayout.h` (it will need to be used from
codegen pass for fir-opt target independent testing.)), and the code
setting-up semantics targetCharacteristics is moved to
`Tools/TargetSetup.h` so that it can be shared with bbc.
As a consequence, LLVM targets must be registered when running
semantics, and it is not possible to run semantics for a target that is
not registered with the -triple option (hence the power pc specific
modules can only be built if the PowerPC target is available.
As already documented in flang/docs/Extensions.md and implemented in the
compilation-time format validator, we want to support at execution time
the Intel (and presumably also Fujitsu) extension of allowing a missing
width on an edit descriptor in a formatted I/O statement.
Fixes https://github.com/llvm/llvm-project/issues/72597.
This test case depends on the stderr output of a `nullptr` being
"(null)". However, it is empty string on AIX.
This PR is to initialize the `sourceFileName_` to be a specific string
to avoid that.
Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair number of
sites in the code do not, and can emit portability warnings
unconditionally, which can confuse a user that hasn't asked for them
(-pedantic) and isn't terribly concerned about portability *to* other
compilers.
Add calls to ShouldWarn() or IsEnabled() around messages that need them,
and add -pedantic to tests that now require it to test their portability
messages, and add more expected message lines to those tests when
-pedantic causes other diagnostics to fire.
In Fortran, a format automatically repeats, with a line break, until all
the data items of a data transfer statement have been consumed. PRINT
"(3I4)", 1, 2, 3, 4, 5, 6 prints two lines, for example, three values
each.
When there are nested parentheses in a format, the rightmost set of
parentheses at the top level are used for automatic repetition. PRINT
"(I4,2(I4))" 1, 2, 3, 4, 5, 6, 7 print three lines, with three values on
the first and two each on the later ones.
Fix a bug in format interpretation that causes the detection of the
"rightmost" set of parentheses to take place on each pass, leading to
problems when parentheses are even further nested.
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.
A recent PR addressed zero and one element edge cases but did not cover
another case where the descriptors of arrays with more than two elements
may have byte strides that are not perfect multiples, like when creating
a descriptor for A(:, 1:1:2).
In general, the byte stride in a dimension is only meaningful if that
dimension has more than one element. Update IsContiguous and
CFI_is_contiguous to reflect that.
Support the EX edit descriptor for hexadecimal real formatted output and
hexadecimal real input for all forms of formatted input.. (We're
possibly the first Fortran compiler to support this feature for input
editing; only one other can handle EX output editing.)
As true (not BOZ) hexadecimal floating-point constants are not supported
in Fortran source code, only in formatted input, the implementation
takes place in the I/O editing portion of the runtime, not as new
conversions in the Decimal library.
The byte strides in zero and one element array descriptor may not be
perfect multiple of the element size and previous and extents.
IsContiguous and its CFI equivalent should still return true for such
arrays (Fortran 2018 standards says in 8.5.7 that an array is not
contiguous if it has two or more elements and ....).
The representation produced by `getTypeAsString` is used by reduction,
privatization and firstprivatization recipes. The name of the recipe is
used as a symbol attribute. If the name has special symbol the symbol
becomes quoted. This patch remove the special character from the
representation so the representation is homogenous.
This reverts commit 6403287eff71a3d6f6c862346d6ed3f0f000eb70.
This is failing on all but 1 of Linaro's flang builders.
CMake Error at /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/llvm/flang-rt/unittests/CMakeLists.txt:37 (message):
Target llvm_gtest not found.
See discourse thread https://discourse.llvm.org/t/rfc-support-cmake-option-to-control-link-type-built-for-flang-runtime-libraries/71602/18 for full details.
Flang-rt is the new library target for the flang runtime libraries. It builds the Flang-rt library (which contains the sources of FortranRuntime and FortranDecimal) and the Fortran_main library. See documentation in this patch for detailed description (flang-rt/docs/GettingStarted.md).
This patch aims to:
- integrate Flang's runtime into existing llvm infrasturcture so that Flang's runtime can be built similarly to other runtimes via the runtimes target or via the llvm target as an enabled runtime
- decouple the FortranDecimal library sources that were used by both compiler and runtime so that different build configurations can be applied for compiler vs runtime
- add support for running flang-rt testsuites, which were created by migrating relevant tests from `flang/test` and `flang/unittest` to `flang-rt/test` and `flang-rt/unittest`, using a new `check-flang-rt` target.
- provide documentation on how to build and use the new FlangRT runtime
Reviewed By: DanielCChen
Differential Revision: https://reviews.llvm.org/D154869
Source allocation with a zero sized array is legal, and the resulting
allocatable/pointer should be allocated/associated.
The current code skipped the actual allocation, leading the allocatable
or pointer to look unallocated/disassociated.
This patch mostly affects performance of the code produced by
HLIFR lowering. If MATMUL argument is an array slice, then
HLFIR lowering passes the slice to the runtime, whereas
FIR lowering would create a contiguous temporary for the slice.
Performance might be better than the generic implementation
for cases where the leading dimension is contiguous.
This patch improves CPU2000/178.galgel making HLFIR version
faster than FIR version (due to avoiding the temporary copies
for MATMUL arguments).
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D159134
Leading zeros should appear only for Iw.m output formatting.
Gw, Gw.d, and Gw.dEe output editing all map to Iw with no ".m"
(Fortran 202X 13.7.5.2.2).
Differential Revision: https://reviews.llvm.org/D159037
I decided to clean up the CMake files as well.
Only FotranEvaluate directly needs quadmath, so we only need
to link these two together.
Differential Revision: https://reviews.llvm.org/D156808
This update allows constant folding for many 128 bit floating point intrinsics
through the library quadmath, which is only available on some platforms.
Differential Revision: https://reviews.llvm.org/D156435
A recent patch replaced two sprintf() calls with snprintf(), but didn't
use the right length for the remaining space in the buffer.
Differential Revision: https://reviews.llvm.org/D155224
At least one compiler more recent that the one that I test with emits
a warning (valid but benign) for some code in a unit test that I
modified a few minutes ago. Adding some curly braces to placate the
compiler.
