The intrinsic is defined as a GNU extension here:
https://gcc.gnu.org/onlinedocs/gfortran/SIGNAL.html
And as an IBM extension here:
https://www.ibm.com/docs/en/xffbg/121.141?topic=procedures-signali-proc-extension
The IBM version provides a compatible subset of the functionality
offered by the GNU version. This patch supports most of the GNU
features, but not calling SIGNAL as a function. We don't currently
support intrinsics being both subroutines AND functions and this changed
seemed too large to be justified by a non-standard intrinsic.
I cannot point to open source code Fortran using this intrinsic. This is
needed for a proprietary code base.
This reverts commit 4210eb1d704c3ba602328efc8924147b2e98ed18.
I didn't realise this was going to break every -Werror bot,
so I guess we'll take the test suite failure until a fix is found,
it's less disruptive.
This reverts commit 18734f606635f4f4270f911b68060890ce3dd94a.
This caused a test suite failure on our bots:
https://lab.llvm.org/buildbot/#/builders/184/builds/9407
```
$ ~/stage1.install/bin/flang-new flush_1.f90
/usr/bin/ld: /home/david.spickett/stage1.install/lib/libFortranRuntime.a(extensions.cpp.o): in function `getlog_':
extensions.cpp:(.text.getlog_+0x1c): undefined reference to `operator new(unsigned long)'
/usr/bin/ld: extensions.cpp:(.text.getlog_+0x7c): undefined reference to `operator delete(void*)'
/usr/bin/ld: extensions.cpp:(.text.getlog_+0xc4): undefined reference to `operator delete(void*)'
/usr/bin/ld: extensions.cpp:(.text.getlog_+0xe8): undefined reference to `operator delete(void*)'
flang-new: error: linker command failed with exit code 1 (use -v to see invocation)
```
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>
The GNU extension intrinsic IARGC is equivalent to
COMMAND_ARGUMENT_COUNT, and the GETARG is similar to
GET_COMMAND_ARGUMENT, but with less arguments. Reuse the runtime of
COMMAND_ARGUMENT_COUNT and GET_COMMAND_ARGUMENT for IARGC and GETARG.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D133558
Prior to the introduction of the FLUSH statement in Fortran 2003,
implementations provided a FLUSH subroutine.
We can't yet put Fortran code into the runtime, so this subroutine
is in C++ with a Fortran-mangled entry point name.
Differential Revision: https://reviews.llvm.org/D115289
