#
5a34e6fd |
| 29-Jan-2025 |
Jean-Didier PAILLEUX <jean-di.pailleux@outlook.com> |
[flang] Implement CHDIR intrinsic (#124280)
This intrinsic is a gnu extension
(https://gcc.gnu.org/onlinedocs/gfortran/CHDIR.html) and is used in
FLEUR (https://github.com/JuDFTteam/FLEUR).
|
#
d732c86c |
| 27-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Don't take corank from actual intrinsic argument (#124029)
When constructing the characteristics of a particular reference to an
intrinsic procedure that was passed a non-coindexed referenc
[flang] Don't take corank from actual intrinsic argument (#124029)
When constructing the characteristics of a particular reference to an
intrinsic procedure that was passed a non-coindexed reference to local
coarray data as an actual argument, don't add the corank of the actual
argument to those characteristics.
Also clean up the TypeAndShape characteristics class a little; the
Attr::Coarray is redundant since the corank() accessor can be used to
the same effect.
show more ...
|
#
1e9b60cf |
| 27-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Recognize and check EVENT_QUERY (#123429)
Recognize the intrinsic subroutine EVENT_QUERY and enforce semantic
requirements on calls to it.
|
#
512b44d5 |
| 27-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Define ATOMIC_ADD as an intrinsic procedure (#122993)
This one appears to have been omitted when other ATOMIC_xxx intrinsic
procedures were defined. There's already tests for it, but they
[flang] Define ATOMIC_ADD as an intrinsic procedure (#122993)
This one appears to have been omitted when other ATOMIC_xxx intrinsic
procedures were defined. There's already tests for it, but they
apparently work even when ATOMIC_ADD must be interpreted as an external
procedure with an implicit interface. Extend the tests with INTRINSIC
NONE(EXTERNAL, TYPE) statements to ensure that they require the
intrinsic interpretation.
show more ...
|
#
9405a81e |
| 14-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix crash exposed by fuzzing (#122187)
An integer overflowed in an erroneous test. Fix, and improve the error
messages a bit.
Fixes https://github.com/llvm/llvm-project/issues/121979.
|
#
3a8a52f4 |
| 08-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Make IsCoarray() more accurate (#121415)
A designator without cosubscripts can have subscripts, component
references, substrings, &c. and still have corank. The current
IsCoarray() predica
[flang] Make IsCoarray() more accurate (#121415)
A designator without cosubscripts can have subscripts, component
references, substrings, &c. and still have corank. The current
IsCoarray() predicate only seems to work for whole variable/component
references. This was breaking some cases of THIS_IMAGE().
show more ...
|
#
94963919 |
| 08-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fold LCOBOUND & UCOBOUND (#121411)
Implement constant folding for LCOBOUND and UCOBOUND intrinsic
functions. Moves some error detection code from intrinsics.cpp to
fold-integer.cpp so that
[flang] Fold LCOBOUND & UCOBOUND (#121411)
Implement constant folding for LCOBOUND and UCOBOUND intrinsic
functions. Moves some error detection code from intrinsics.cpp to
fold-integer.cpp so that erroneous calls get properly flagged and
converted into known errors.
show more ...
|
#
878a5746 |
| 08-Jan-2025 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][cuda] Add c_devloc as intrinsic and inline it during lowering (#120648)
Add `c_devloc` as intrinsic and inline it during lowering. `c_devloc` is
used in CUDA Fortran to get the address of d
[flang][cuda] Add c_devloc as intrinsic and inline it during lowering (#120648)
Add `c_devloc` as intrinsic and inline it during lowering. `c_devloc` is
used in CUDA Fortran to get the address of device variables.
For the moment, we borrow almost all semantic checks from `c_loc` except
for the pointer or target restriction. The specifications of `c_devloc`
are are pretty vague and we will relax/enforce the restrictions based on
library and apps usage comparing them to the reference compiler.
show more ...
|
#
fc97d2e6 |
| 18-Dec-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Add UNSIGNED (#113504)
Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).
This is nearly identical to the UNSIGNED feature that h
[flang] Add UNSIGNED (#113504)
Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).
This is nearly identical to the UNSIGNED feature that has been available
in Sun Fortran for years, and now implemented in GNU Fortran for
gfortran 15, and proposed for ISO standardization in J3/24-116.txt.
See the new documentation for details; but in short, this is C's
unsigned type, with guaranteed modular arithmetic for +, -, and *, and
the related transformational intrinsic functions SUM & al.
show more ...
|
#
1858a4eb |
| 28-Nov-2024 |
Tom Eccles <tom.eccles@arm.com> |
Revert "[flang]Add new intrinsic function backtrace and complete the TODO of abort" (#117990)
Reverts llvm/llvm-project#117603 due to failed buildbot
https://lab.llvm.org/buildbot/#/builders/152/bu
Revert "[flang]Add new intrinsic function backtrace and complete the TODO of abort" (#117990)
Reverts llvm/llvm-project#117603 due to failed buildbot
https://lab.llvm.org/buildbot/#/builders/152/builds/710
The important bit of the log was
```
FAILED: CMakeFiles/FortranRuntime.dir/stop.cpp.o
ccache /usr/bin/g++ -DFLANG_LITTLE_ENDIAN=1 -DGTEST_HAS_RTTI=0 -DRT_USE_LIBCUDACXX=1 -D_DEBUG -D_GLIBCXX_ASSERTIONS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/buildbot/worker/as-builder-7/ramdisk/flang-runtime-cuda-gcc/llvm-project/flang/runtime/../include -I/home/buildbot/worker/as-builder-7/ramdisk/flang-runtime-cuda-gcc/build -I/home/buildbot/worker/third-party/nv/cccl/libcudacxx/include -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -Wimplicit-fallthrough -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fno-lto -O3 -DNDEBUG -U_GLIBCXX_ASSERTIONS -U_LIBCPP_ENABLE_ASSERTIONS -UNDEBUG -std=c++17 -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-rtti -MD -MT CMakeFiles/FortranRuntime.dir/stop.cpp.o -MF CMakeFiles/FortranRuntime.dir/stop.cpp.o.d -o CMakeFiles/FortranRuntime.dir/stop.cpp.o -c /home/buildbot/worker/as-builder-7/ramdisk/flang-runtime-cuda-gcc/llvm-project/flang/runtime/stop.cpp
/home/buildbot/worker/as-builder-7/ramdisk/flang-runtime-cuda-gcc/llvm-project/flang/runtime/stop.cpp:19:10: fatal error: llvm/Config/config.h: No such file or directory
19 | #include "llvm/Config/config.h"
| ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
```
CC @dty2
show more ...
|
#
159e6012 |
| 28-Nov-2024 |
执着 <118413413+dty2@users.noreply.github.com> |
[flang]Add new intrinsic function backtrace and complete the TODO of abort (#117603)
Hey guys, I found that Flang's built-in ABORT function is incomplete
when I was using it. Compared with gfortran
[flang]Add new intrinsic function backtrace and complete the TODO of abort (#117603)
Hey guys, I found that Flang's built-in ABORT function is incomplete
when I was using it. Compared with gfortran's ABORT (which can both
abort and print out a backtrace), flang's ABORT implementation lacks the
function of printing out a backtrace. This feature is essential for
debugging and understanding the call stack at the failure point.
To solve this problem, I completed the "// TODO:" of the abort function,
and then implemented an additional built-in function BACKTRACE for
flang. After a brief reading of the relevant source code, I used
backtrace and backtrace_symbols in "execinfo.h" to quickly implement
this. But since I used the above two functions directly, my
implementation is slightly different from gfortran's implementation (in
the output, the function call stack before main is additionally output,
and the function line number is missing). In addition, since I used the
above two functions, I did not need to add -g to embed debug information
into the ELF file, but needed -rdynamic to ensure that the symbols are
added to the dynamic symbol table (so that the function name will be
printed out).
Here is a comparison of the output between gfortran 's backtrace and my
implementation:
gfortran's implemention output:
```
#0 0x557eb71f4184 in testfun2_
at /home/hunter/plct/fortran/test.f90:5
#1 0x557eb71f4165 in testfun1_
at /home/hunter/plct/fortran/test.f90:13
#2 0x557eb71f4192 in test_backtrace
at /home/hunter/plct/fortran/test.f90:17
#3 0x557eb71f41ce in main
at /home/hunter/plct/fortran/test.f90:18
```
my impelmention output:
```
Backtrace:
#0 ./test(_FortranABacktrace+0x32) [0x574f07efcf92]
#1 ./test(testfun2_+0x14) [0x574f07efc7b4]
#2 ./test(testfun1_+0xd) [0x574f07efc7cd]
#3 ./test(_QQmain+0x9) [0x574f07efc7e9]
#4 ./test(main+0x12) [0x574f07efc802]
#5 /usr/lib/libc.so.6(+0x25e08) [0x76954694fe08]
#6 /usr/lib/libc.so.6(__libc_start_main+0x8c) [0x76954694fecc]
#7 ./test(_start+0x25) [0x574f07efc6c5]
```
test program is:
```
function testfun2() result(err)
implicit none
integer :: err
err = 1
call backtrace
end function testfun2
subroutine testfun1()
implicit none
integer :: err
integer :: testfun2
err = testfun2()
end subroutine testfun1
program test_backtrace
call testfun1()
end program test_backtrace
```
I am well aware of the importance of line numbers, so I am now working
on implementing line numbers (by parsing DWARF information) and
supporting cross-platform (Windows) support.
show more ...
|
#
c0192a00 |
| 26-Nov-2024 |
Tom Eccles <tom.eccles@arm.com> |
[flang] implement function form of SYSTEM intrinsic (#117585)
SYSTEM is a gfortran extension which we already supported in subroutine
form. Gfortran also allows it to be called as a function, which
[flang] implement function form of SYSTEM intrinsic (#117585)
SYSTEM is a gfortran extension which we already supported in subroutine
form. Gfortran also allows it to be called as a function, which was
requested by a user
https://discourse.llvm.org/t/unresolved-externals-with-appendend-underscore/83305/4
show more ...
|
#
ad7bb652 |
| 26-Nov-2024 |
Tom Eccles <tom.eccles@arm.com> |
[flang] Implement non-standard LNBLNK intrinsic (#117589)
This is defined here
https://gcc.gnu.org/onlinedocs/gfortran/LNBLNK.html. It is just an alias
to LEN_TRIM.
This was requested by a user
[flang] Implement non-standard LNBLNK intrinsic (#117589)
This is defined here
https://gcc.gnu.org/onlinedocs/gfortran/LNBLNK.html. It is just an alias
to LEN_TRIM.
This was requested by a user:
https://discourse.llvm.org/t/unresolved-externals-with-appendend-underscore/83305
show more ...
|
#
376713ff |
| 14-Nov-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Accept CLASS(*) array in EOSHIFT (#116114)
The intrinsic processing code wasn't allowing the ARRAY= argument to the
EOSHIFT intrinsic function to be CLASS(*). That case seems to conform to
[flang] Accept CLASS(*) array in EOSHIFT (#116114)
The intrinsic processing code wasn't allowing the ARRAY= argument to the
EOSHIFT intrinsic function to be CLASS(*). That case seems to conform to
the standard, although only one compiler could actually handle it, so
allow for it.
Fixes https://github.com/llvm/llvm-project/issues/115923.
show more ...
|
#
ebc0163c |
| 14-Nov-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] INT2 & INT8 can't be specific intrinsic functions (#115360)
I recently added support for the extension intrinsic functions INT2 and
INT8, and took the shortcut of defining them as specific
[flang] INT2 & INT8 can't be specific intrinsic functions (#115360)
I recently added support for the extension intrinsic functions INT2 and
INT8, and took the shortcut of defining them as specific intrinsic
functions that map to the standard INT() with hard-wired KIND= values
for the result. This works fine for references to these functions, but
leads to a compiler crash for an attempt to use their names in contexts
other than calling them, since their argument types aren't restricted to
single types and no concrete interface can be characterized for them. So
move them out of the table of specific intrinsic functions and into the
general table of intrinsics, and then handle them afterwards as if they
had been INT().
Fixes https://github.com/llvm/llvm-project/issues/115324.
show more ...
|
#
2bc30f37 |
| 14-Nov-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Make interoperability warning an off-by-default portability one (#115096)
The FPTR= argument to the C_F_POINTER intrinsic procedure should be a
pointer with an interoperable type, but isn't
[flang] Make interoperability warning an off-by-default portability one (#115096)
The FPTR= argument to the C_F_POINTER intrinsic procedure should be a
pointer with an interoperable type, but isn't required to be, and most
compilers don't mention it. Change the warning from an on-by-default
interoperability warning into an off-by-default portability warning.
Fixes https://github.com/llvm/llvm-project/issues/115012.
show more ...
|
#
922992a2 |
| 18-Oct-2024 |
Jay Foad <jay.foad@amd.com> |
Fix typo "instrinsic" (#112899)
|
#
5a9d6841 |
| 15-Oct-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Split interoperability warnings, disable some by default (#111922)
Type interoperability warnings current issue for intrinsic types when
their type, kind, or length do not meet the requirem
[flang] Split interoperability warnings, disable some by default (#111922)
Type interoperability warnings current issue for intrinsic types when
their type, kind, or length do not meet the requirements for C
interoperability. This turns out to be too noisy for the case of
one-byte characters with lengths other than one when creating C pointers
from C_LOC or C_F_POINTER -- it is not uncommon for programs to use
pointers to longer character objects.
So split the interoperability warning so that the case of a known bad
character length for an otherwise interoperable type is controlled by
its own UsageWarning enumerator, and leave that usage warning off by
default. This will better fit expectations in the default case while
still showing a warning under -pedantic.
show more ...
|
#
0f973ac7 |
| 02-Oct-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)
(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as
[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)
(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as expected.)
Allow a parser::Message for a warning to be marked with the
common::LanguageFeature or common::UsageWarning that controls it. This
will allow a later patch to add hooks whereby a driver will be able to
decorate warning messages with the names of its options that enable each
particular warning, and to add hooks whereby a driver can map those
enumerators by name to command-line options that enable/disable the
language feature and enable/disable the messages.
The default settings in the constructor for LanguageFeatureControl were
moved from its header file into its C++ source file.
Hooks for a driver to use to map the name of a feature or warning to its
enumerator were also added.
To simplify the tagging of warnings with their corresponding language
feature or usage warning, to ensure that they are properly controlled by
ShouldWarn(), and to ensure that warnings never issue at code sites in
module files, two new Warn() member function templates were added to
SemanticsContext and other contextual frameworks. Warn() can't be used
before source locations can be mapped to scopes, but the bulk of
existing code blocks testing ShouldWarn() and FindModuleFile() before
calling Say() were convertible into calls to Warn(). The ones that were
not convertible were extended with explicit calls to
Message::set_languageFeature() and set_usageWarning().
show more ...
|
#
856c38d5 |
| 02-Oct-2024 |
David Truby <david.truby@arm.com> |
[flang] Implement GETUID and GETGID intrinsics (#110679)
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simp
[flang] Implement GETUID and GETGID intrinsics (#110679)
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simply
call the POSIX getuid() and getgid() functions and return the result.
The only platform we support that does not have these is Windows.
Windows does not have the same concept of UIDs and GIDs, so on Windows
we issue a warning indicating this and return 1 from both functions.
Co-authored-by: Yi Wu <yi.wu2@arm.com>
show more ...
|
#
78ccffc0 |
| 30-Sep-2024 |
David Truby <david.truby@arm.com> |
[flang] Add MALLOC and FREE intrinsics for Cray pointers (#110018)
MALLOC and FREE are extensions provided by gfortran, Intel Fortran and
classic flang to allocate memory for Cray pointers. These a
[flang] Add MALLOC and FREE intrinsics for Cray pointers (#110018)
MALLOC and FREE are extensions provided by gfortran, Intel Fortran and
classic flang to allocate memory for Cray pointers. These are used in
some legacy codes such as libexodus.
All the above compilers accept using MALLOC and FREE with integers as
well, despite that this will often signify a bug in user code. We should
accept the same as the other compilers for compatibility.
show more ...
|
#
7a0a7947 |
| 30-Sep-2024 |
David Truby <david.truby@arm.com> |
Revert "[flang] Implement GETUID and GETGID intrinsics" (#110531)
Reverts llvm/llvm-project#108017
|
#
054eadcb |
| 30-Sep-2024 |
David Truby <david.truby@arm.com> |
[flang] Implement GETUID and GETGID intrinsics (#108017)
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simp
[flang] Implement GETUID and GETGID intrinsics (#108017)
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simply
call the POSIX getuid() and getgid() functions and return the result.
The only platform we support that does not have these is Windows.
Windows does not have the same concept of UIDs and GIDs, so on Windows
we issue a warning indicating this and return 1 from both functions.
Co-authored-by: Yi Wu <yi.wu2@arm.com>
---------
Co-authored-by: Yi Wu <yi.wu2@arm.com>
show more ...
|
#
6959ec91 |
| 20-Sep-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Extension intrinsics INT8 and INT2 (#109433)
These are legacy conversion intrinsic functions supported by nearly all
Fortran compilers (esp. INT8).
They are equivalent to INT(..., KIND=8 o
[flang] Extension intrinsics INT8 and INT2 (#109433)
These are legacy conversion intrinsic functions supported by nearly all
Fortran compilers (esp. INT8).
They are equivalent to INT(..., KIND=8 or 2), respectively.
show more ...
|
#
75138921 |
| 20-Sep-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Make IEEE_INT and IEEE_REAL into builtin intrinsic functions (#109191)
For proper error detection of bad KIND= arguments, make IEEE_INT and
IEEE_REAL actual intrinsic functions. Lowering wi
[flang] Make IEEE_INT and IEEE_REAL into builtin intrinsic functions (#109191)
For proper error detection of bad KIND= arguments, make IEEE_INT and
IEEE_REAL actual intrinsic functions. Lowering will have to check for
the new __builtin_ names.
show more ...
|