summaryrefslogtreecommitdiff
path: root/flang/unittests
Commit message (Collapse)AuthorAgeFilesLines
* [flang] Use internal linkage for string literalsDavid Truby2023-05-111-1/+1
| | | | | | | | | | | | | | On Windows, global string literals with "linkonce" linkage is not supported without using comdat. As a simpler fix than adding comdat support we can use internal linkage instead. This fixes a bug where two string literals with the same value in different fortran files would cause a linker error due to the use of linkonce linkage. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D149859
* [flang][runtime] Support L editing of LogicalShao-Ce SUN2023-04-062-0/+57
| | | | | | | | I tested gfortran and flang(old). https://godbolt.org/z/c89foro4G Reviewed By: klausler Differential Revision: https://reviews.llvm.org/D146989
* [flang] Add AllocatableInit functions for use in allocate loweringValentin Clement2023-03-201-0/+17
| | | | | | | | | | | | | | | | | `AllocatableInitIntrinsic`, `AllocatableInitCharacter` and `AllocatableInitDerived` are meant to be used to initialize a descriptor when it is instantiated and not to be used multiple times in a scope. Add `AllocatableInitDerivedForAllocate`, `AllocatableInitCharacterForAllocate` and `AllocatableInitDerivedForAllocate` to be used for the allocation in allocate statement. These new functions are meant to be used on an initialized descriptor and will return directly if the descriptor is allocated so the error handling is done by the call to `AllocatableAllocate`. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D146290
* [flang] add fused matmul-transpose to the runtimeTom Eccles2023-03-172-0/+127
| | | | | | | | | | | | | This fused operation should run a lot faster than first transposing the lhs array and then multiplying the matrices separately. Based on flang/runtime/matmul.cpp Depends on D145959 Reviewed By: klausler Differential Revision: https://reviews.llvm.org/D145960
* [flang][runtime] Corrections to formatted child I/OPeter Klausler2023-03-101-19/+24
| | | | | | | | | | A handful of I/O statements (OPEN, CLOSE, positioning) are not allowed on units during child I/O; catch violations and report errors. Also finesse error handling during FORMAT runtime parsing of DT derived type edit descriptors, and ensure that formatted child I/O is nonadvancing. Differential Revision: https://reviews.llvm.org/D145751
* [flang] Handle unlimited polymorphic with intrinsic dynamic type in ↵Valentin Clement2023-03-101-0/+13
| | | | | | | | | | | extends_type_of Unlimited polymorphic entities can have an intrinsic dynamic type. Update the code of extends_type_of to compare the CFI_type in these case. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D145722
* Break circular dependency between FIR dialect and utilitiesRenaud-K2023-03-099-9/+10
|
* [flang] Simplify same_type_as conditionValentin Clement2023-03-091-12/+21
| | | | | | | | | | | | Restore the behavior changed in D145384 and add proper unit tests. Unallocated unlimited poymorphic allocatable and disassociated unlimited polymorphic pointer should return false. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D145674
* [flang] Align same_type_as result to other compilersValentin Clement2023-03-082-0/+45
| | | | | | | | | | | Unallocated unlimited polymorphic entities do not have a dynamic type set and do not have declared type. The standard notes that the result is processor dependent when one of the arguments of same_type_as is in this case. Align the result to other compiler (gfortran, nvfortran). Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D145384
* [flang] Allow scalar boxed record type in intrinsic elemental loweringValentin Clement2023-03-011-0/+37
| | | | | | | | | Relax a bit the condition added in D144417 and allow scalar polymorphic entities and boxed scalar record type. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D145058
* [flang] Handle dynamic type in move_allocValentin Clement2023-03-012-7/+10
| | | | | | | | | | Update move_alloc to carry over the dyanmic type of `from` to `to` and reset the dynamic type of `from` to its declared type when it is polymorphic. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D144997
* [flang] Block constructV Donaldson2023-02-281-67/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A block construct is an execution control construct that supports declaration scopes contained within a parent subprogram scope or another block scope. (blocks may be nested.) This is implemented by applying basic scope processing to the block level. Name uniquing/mangling is extended to support this. The term "block" is heavily overloaded in Fortran standards. Prior name uniquing used tag `B` for common block objects. Existing tag choices were modified to free up `B` for block construct entities, and `C` for common blocks, and resolve additional issues with other tags. The "old tag -> new tag" changes can be summarized as: -> B -- block construct -> new B -> C -- common block C -> YI -- intrinsic type descriptor; not currently generated CT -> Y -- nonintrinsic type descriptor; not currently generated G -> N -- namelist group L -> -- block data; not needed -> deleted Existing name uniquing components consist of a tag followed by a name from user source code, such as a module, subprogram, or variable name. Block constructs are different in that they may be anonymous. (Like other constructs, a block may have a `block-construct-name` that can be used in exit statements, but this name is optional.) So blocks are given a numeric compiler-generated preorder index starting with `B1`, `B2`, and so on, on a per-procedure basis. Name uniquing is also modified to include component names for all containing procedures rather than for just the immediate host. This fixes an existing name clash bug with same-named entities in same-named host subprograms contained in different-named containing subprograms, and variations of the bug involving modules and submodules. F18 clause 9.7.3.1 (Deallocation of allocatable variables) paragraph 1 has a requirement that an allocated, unsaved allocatable local variable must be deallocated on procedure exit. The following paragraph 2 states: When a BLOCK construct terminates, any unsaved allocated allocatable local variable of the construct is deallocated. Similarly, F18 clause 7.5.6.3 (When finalization occurs) paragraph 3 has a requirement that a nonpointer, nonallocatable object must be finalized on procedure exit. The following paragraph 4 states: A nonpointer nonallocatable local variable of a BLOCK construct is finalized immediately before it would become undefined due to termination of the BLOCK construct. These deallocation and finalization requirements, along with stack restoration requirements, require knowledge of block exits. In addition to normal block termination at an end-block-stmt, a block may be terminated by executing a branching statement that targets a statement outside of the block. This includes Single-target branch statements: - goto - exit - cycle - return Bounded multiple-target branch statements: - arithmetic goto - IO statement with END, EOR, or ERR specifiers Unbounded multiple-target branch statements: - call with alternate return specs - computed goto - assigned goto Lowering code is extended to determine if one of these branches exits one or more relevant blocks or other constructs, and adds a mechanism to insert any necessary deallocation, finalization, or stack restoration code at the source of the branch. For a single-target branch it suffices to generate the exit code just prior to taking the indicated branch. Each target of a multiple-target branch must be analyzed individually. Where necessary, the code must first branch to an intermediate basic block that contains exit code, followed by a branch to the original target statement. This patch implements an `activeConstructStack` construct exit mechanism that queries a new `activeConstruct` PFT bit to insert stack restoration code at block exits. It ties in to existing code in ConvertVariable.cpp routine `instantiateLocal` which has code for finalization, making block exit finalization on par with subprogram exit finalization. Deallocation is as yet unimplemented for subprograms or blocks. This may result in memory leaks for affected objects at either the subprogram or block level. Deallocation cases can be addressed uniformly for both scopes in a future patch, presumably with code insertion in routine `instantiateLocal`. The exit code mechanism is not limited to block construct exits. It is also available for use with other constructs. In particular, it is used to replace custom deallocation code for a select case construct character selector expression where applicable. This functionality is also added to select type and associate constructs. It is available for use with other constructs, such as select rank and image control constructs, if that turns out to be necessary. Overlapping nonfunctional changes include eliminating "FIR" from some routine names and eliminating obsolete spaces in comments.
* [flang][runtime] Add API to help with the difficult array constructor casesJean Perier2023-02-222-0/+160
| | | | | | | | | | | | | | | | | | This runtime API can be used to lower any flavor of array constructors, but is mainly intended to be used with: - array constructors for which the extent or length parameters cannot be computed without lowering some ac-value or ac-implied-do-control that cannot be pre-evaluated. - array constructors of a derived type with allocatable component where copy is not trivial or PDTS. Example of use cases: - `[((i+j,i=1, ifoo()), j=1,n)]` where ifoo() is not pure. - `[return_allocatable_array(), return_allocatable_array()]` Differential Revision: https://reviews.llvm.org/D144411
* [flang] Update intrinsic types to unlimited polymorphic formValentin Clement2023-02-151-0/+70
| | | | | | | | | | This patch updates the code added in D143888 to avoid overwriting some part of the types when updating it for unlimited polymorphic types. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D143995
* [NFC][TargetParser] Replace uses of llvm/Support/Host.hArchibald Elliott2023-02-102-2/+2
| | | | | | | The forwarding header is left in place because of its use in `polly/lib/External/isl/interface/extract_interface.cc`, but I have added a GCC warning about the fact it is deprecated, because it is used in `isl` from where it is included by Polly.
* [NFC][TargetParser] Remove llvm/ADT/Triple.hArchibald Elliott2023-02-071-1/+1
| | | | | | I also ran `git clang-format` to get the headers in the right order for the new location, which has changed the order of other headers in two files.
* [flang] Support allocate array from scalar source in runtimePeixin Qiao2023-02-012-0/+40
| | | | | | | | | | | | As Fortran 2018 9.7.1.2(7), the value of each element of allocate object becomes the value of source when the allocate object is array and the source is scalar. Fix #60090. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D142112
* [flang] Single entry point for GET_ENVIRONMENT_VARIABLELeandro Lupori2023-01-312-41/+29
| | | | | | | | | | | | | This patch refactors the runtime support for GET_ENVIRONMENT_VARIABLE to have a single entry point instead of 2. It also updates lowering accordingly. This makes it easier to handle dynamically optional arguments. See also https://reviews.llvm.org/D118777 Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D142489
* [flang] Improve error message for move_allocDavid Truby2023-01-311-2/+2
| | | | | | | This patch improves the error message when MOVE_ALLOC is passed the same allocated allocatable as both the to and from arguments. Differential Revision: https://reviews.llvm.org/D142899
* [flang] Add lowering of move_alloc to IntrinsicCallDavid Truby2023-01-203-1/+33
| | | | | | | | | This patch relies on D141286 for the runtime implementation of move_alloc. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D141616
* [flang] Fixed unittest build issue with older gcc.Slava Zakharin2023-01-181-7/+0
| | | | | | | | | | | | | | I am getting this error with `check-flang`: ``` ld.lld: error: undefined symbol: mlir::SuccessorRange::SuccessorRange(mlir::Operation*) >>> referenced by Operation.h:549 (/llvm-project/llvm/../mlir/include/mlir/IR/Operation.h:549) >>> CMakeFiles/FlangRuntimeTests.dir/Allocatable.cpp.o:(mlir::Operation::getSuccessors()) ``` The buildbots are okay, so I guess it has something to do with gcc-9 that I am using. Differential Revision: https://reviews.llvm.org/D142069
* [flang] Do not perform INTERNAL_CHECK for deallocation of unlimited ↵Valentin Clement2023-01-181-0/+12
| | | | | | | | | | | | | | | | | polymorphic with intrinsic type spec When an unlimited polymorphic descriptor is establish for an intrinsic type spec, the `PointerNullifyIntrinsic` or `AllocatableInitIntrinsic` runtime function is called. These functions do not initialize an addendum with a derivedType. When the deallocation on this descriptor is performed, the runtime should not crash if the addendum is not present. This patch updates `PointerDeallocatePolymorphic` and `AllocatableDeallocatePolymorphic` for this use case. Depends on D141996 Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D142010
* [flang] Allocate polymorphic with SOURCE= using ApplyMoldValentin Clement2023-01-181-0/+21
| | | | | | | | | | Source allocation is similar to mold allocation + assignment. Use ApplyMold runtime entry point for polymorphic source allocation. It could be generalized for other source allocation. Reviewed By: jeanPerier, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141996
* [flang] Add implementation of move_alloc to the runtimeDavid Truby2023-01-182-0/+81
| | | | | | | | This patch adds a move_alloc implementation to the flang runtime. Most of the checks required by the standard for move_alloc are done by semenatic analysis; these checks are not replicated here. Differential Revision: https://reviews.llvm.org/D141286
* [flang] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata2023-01-021-2/+3
| | | | | | | This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
* [Support] Move TargetParsers to new componentArchibald Elliott2022-12-202-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fairly large changeset, but it can be broken into a few pieces: - `llvm/Support/*TargetParser*` are all moved from the LLVM Support component into a new LLVM Component called "TargetParser". This potentially enables using tablegen to maintain this information, as is shown in https://reviews.llvm.org/D137517. This cannot currently be done, as llvm-tblgen relies on LLVM's Support component. - This also moves two files from Support which use and depend on information in the TargetParser: - `llvm/Support/Host.{h,cpp}` which contains functions for inspecting the current Host machine for info about it, primarily to support getting the host triple, but also for `-mcpu=native` support in e.g. Clang. This is fairly tightly intertwined with the information in `X86TargetParser.h`, so keeping them in the same component makes sense. - `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains the target triple parser and representation. This is very intertwined with the Arm target parser, because the arm architecture version appears in canonical triples on arm platforms. - I moved the relevant unittests to their own directory. And so, we end up with a single component that has all the information about the following, which to me seems like a unified component: - Triples that LLVM Knows about - Architecture names and CPUs that LLVM knows about - CPU detection logic for LLVM Given this, I have also moved `RISCVISAInfo.h` into this component, as it seems to me to be part of that same set of functionality. If you get link errors in your components after this patch, you likely need to add TargetParser into LLVM_LINK_COMPONENTS in CMake. Differential Revision: https://reviews.llvm.org/D137838
* [flang] Finish substring loweringJean Perier2022-12-201-1/+2
| | | | | | | Hlfir.designate was made to support substrings but so far substrings were not yet lowered to it. Implement support for them. Differential Revision: https://reviews.llvm.org/D140310
* [flang] Lowering and runtime support for F08 transformational intrinsics: ↵Tarun Prabhu2022-12-192-0/+291
| | | | | | | | | | | | | | | | | | | | | | | BESSEL_JN and BESSEL_YN The runtime implementation uses the recurrence relations `J(n-1, x) = (2.0 / x) * n * J(n, x) - J(n+1, x)` `Y(n+1, x) = (2.0 / x) * n * Y(n, x) - Y(n-1, x)` (see https://dlmf.nist.gov/10.74.iv and https://dlmf.nist.gov/10.6.E1). Although the standard requires that `N1` and `N2` in `BESSEL_JN(N1, N2, x)` and `BESSEL_YN(N1, N2, x)` be non-negative, this is not checked in the runtime functions. This is in keeping with some other compilers which also return some results when `N1` and/or `N2` are negative. The special case for `x == 0` is handled in different runtime functions for each of `BESSEL_JN` and `BESSEL_YN`. The lowering code checks for this case and inserts the checks and the appropriate runtime calls in FIR. The existing tests for the two intrinsics was modified to keep the style consistent with the additional lowering tests that were added.
* [flang][NFC] add builder to simplify fir.shape creationJean Perier2022-12-151-2/+1
| | | | Differential Revision: https://reviews.llvm.org/D140031
* [flang] Lower exponentiation without using pgmath.Slava Zakharin2022-12-141-0/+79
| | | | | | | | | | | | | Exponentiation is lowered to either math::FPowI or Fortran runtime call (in case of --math-runtime=precise). MathToFuncs convertor will convert math::FPowI operations with exponent width >32 to calls of outlined implementations and otherwise will leave the operation to MathToLLVM convertor. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D139806
* [flang/unittests] Use std::nullopt instead of None (NFC)Kazu Hirata2022-12-036-10/+10
| | | | | | | | | | | | This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
* [flang] Lower symbols to hlfir.declareJean Perier2022-11-151-32/+7
| | | | | | | | | | | | | Update lowering to generate hlfir.declare instead of fir.declare. Introduce the hlfir::Entity class that will be used to work with Fortran objects in HLFIR transformation. Fix lower bounds that where swapped with extents in fir.declare generation. Update tests that expected fir.declare. Differential Revision: https://reviews.llvm.org/D137951
* [flang][NFC] rename hlfir::FortranEntity into EntityWithAttributesJean Perier2022-11-141-5/+5
| | | | | | | | | | This reflects the fact that Attributes will not always be visible when looking at an HLFIR variable. The EntityWithAttributes class is used to denote in the compiler code that the value at hand has visible attributes. It is intended to be used in lowering so that the code can query about operands attributes when generating code. Differential Revision: https://reviews.llvm.org/D137792
* [flang] Initial support for FastMathAttr setup in FirOpBuilder.Slava Zakharin2022-11-071-0/+55
| | | | | | | | | | | | | | | | | Provide FirOpBuilder::setFastMathFlags() to configure FastMathFlags for the builder. Set FastMathAttr for operations based on FirOpBuilder configuration via mlir::OpBuilder::Listener. This is a little bit hacky solution, because we lose the ability to hook other listeners to FirOpBuilder. There are also potential issues with OpBuilder::clone() - the hook will be invoked for cloned operations and will effectively overwrite FastMathAttr with the ones configured in FirOpBuilder, which should not be happening. We should teach mlir::OpBuilder about FastMathAttr setup in future. Reviewed By: jeanPerier, kiranchandramohan Differential Revision: https://reviews.llvm.org/D137390
* [Flang] Run clang-format on all flang filesPeter Steinfeld2022-11-032-3/+2
| | | | | | This will make it easier for me to do reviews. Differential Revision: https://reviews.llvm.org/D137291
* [Flang][Driver]Add datalayout before doing LLVM-IR transformationMats Petersson2022-11-031-0/+5
| | | | | | | | | | | | The earlier available datalyaout allows MLIR to LLVM-IR transformation to use the datalayout for decisions, such as comparing sizes for different types of integers. This should solve https://github.com/llvm/llvm-project/issues/57230 Reviewed By: awarzynski, vzakhari Differential Revision: https://reviews.llvm.org/D133568
* [NFC][flang] Lowering options clean-up.Slava Zakharin2022-11-021-0/+1
| | | | | | | This change-set defines the LoweringOptions the same way other options are defined in Flang. Differential Revision: https://reviews.llvm.org/D137207
* [flang] add hlfir::FortranEntity classJean Perier2022-10-212-0/+219
| | | | | | | | | | | | Add hlfir::FortranEntity class and a first helper to convert it to fir::ExtendedValue. The hlfir::FortranEntity will be the core class of the new expression lowering. It is conceptually very similar to what fir::ExtendedValue is today, except that it is wrapping single mlir::Value: it holds the SSA value for a lowered Fortran variable or expression value. Differential Revision: https://reviews.llvm.org/D136428
* [flang] Add High level Fortran IR dialectJean Perier2022-10-211-0/+1
| | | | | | | | | | | | | This patch adds the basic dialect definition of the HLFIR dialect that was described in https://reviews.llvm.org/D134285. It adds the definition of the hlfir.expr type and related tests so that it can be verified that the dialect is properly hooked up by the tools. Operations will be added as progress is made in the expression lowering update. Differential Revision: https://reviews.llvm.org/D136328
* [flang] Add fir.declare operationJean Perier2022-10-192-0/+152
| | | | | | | | | | | Add fir.declare operation whose purpose was described in https://reviews.llvm.org/D134285. It uses the FortranVariableInterfaceOp for most of its logic (including the verifier). The rational is that all these aspects/logic will be shared by hlfir.designate and hlfir.associate. Its codegen and lowering will be added in later patches. Differential Revision: https://reviews.llvm.org/D136181
* [flang] Add getTypeDescriptorBindingTableName functionValentin Clement2022-10-181-0/+17
| | | | | | | | | | | | Type descriptor and its binding table are defined as fir.global in FIR. Their names are derived from the derived-type name. This patch adds a new function `getTypeDescriptorBindingTableName` in the NameUniquer and refactor the `GetTypeDescriptorName` function to reuse the same code. This will be used in the fir.dispatch code generation. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D136167
* [Flang] Add -fconvert option to swap endianness for unformatted files.Jonathon Penix2022-10-122-3/+5
| | | | | | To accomplish this, this patch creates an optional list of environment variable default values to be set by the runtime to allow directly using the existing runtime implementation of FORT_CONVERT for I/O conversions.
* [flang] Add cpowi function to runtime and use instead of pgmathDavid Truby2022-10-112-0/+171
| | | | | | | | This patch adds a cpowi function to the flang runtime, and switches to using that function instead of pgmath for complex number to integer power operations. Differential Revision: https://reviews.llvm.org/D134889
* [flang] Add type-specific runtime entries for Minloc/Maxloc.Slava Zakharin2022-10-103-11/+64
| | | | | | | | | | | We used to have a big switch statement over the type categories and kinds inside Minloc/Maxloc. After D133051 the switch grew bigger, and this changed inlining decisions made by GCC (the build compiler). Some of the simple methods stopped being inlined, and this caused slight performance regression in Polyhedron/gas_dyn2. This change adds separate entries for real/integer data types to let them be optimized separately. Differential Revision: https://reviews.llvm.org/D135610
* [flang] Allow conversion from boxed derived type to fir.classValentin Clement2022-10-101-0/+29
| | | | | | | | | | | | This patch updates the fir.convert operation's verifier to allow conversion from !fir.box<!fir.type<T>> to !fir.class<!fir.type<T>>. Other conversion involving fir.class are likely needed but will be added when lowering needs them. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D135445
* [flang] Update to fir::isUnlimitedPolymorphicType and fir::isPolymorphicType ↵Valentin Clement2022-10-052-0/+120
| | | | | | | | | | | | functions This patch update the fir::isUnlimitedPolymorphicType function to reflect the chosen design. It adds also a fir::isPolymorphicType function. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D135143
* [flang][runtime] Fixed identity value for REAL(16) == __float128.Slava Zakharin2022-09-281-0/+17
| | | | | | | | std::numeric_limits<__float128>::max/lowest return 0.0, so recreate value of FLT128_MAX ourselves to avoid using quadmath.h's FLT128_MAX that is currently causes warnings with GCC -Wpedantic. Differential Revision: https://reviews.llvm.org/D134496
* [flang][runtime] Fixes for element size calculation.Slava Zakharin2022-09-221-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | BytesFor() used to return KIND for the size, which is not always correct, so I changed it to return the size of the actual CppType corresponding to the given category and kind. MinElemLen() used to calculate size incorrectly (e.g. CFI_type_extended_double was sized 10, whereas it may occupy more bytes on a target), so I changed it to call BytesFor(). Additional changes were needed to resolve new failures for transformational intrinsics. These intrinsics used to work for not fully supported data types (e.g. REAL(3)), but now stopped working because CppType cannot be computed for those categories/kinds. The solution is to use known element size from the source argument(s) for establishing the destination descriptor - the element size is all that is needed for transformational intrinsics to keep working. Note that this does not help cases, where runtime still has to compute the element size, e.g. when it creates descriptors for components of derived types. If the component has unsupported data type, BytesFor() will still fail. So these cases require adding support for the missing types. New regression unit test in Runtime/Transformational.cpp demonstrates the case that will start working properly with this commit.
* [flang] Use x.empty() instead of llvm::empty(x) (NFC)Kazu Hirata2022-09-181-1/+1
| | | | | | | I'm planning to deprecate and eventually remove llvm::empty. Note that no use of llvm::empty requires the ability of llvm::empty to determine the emptiness from begin/end only.
* [flang][runtime] ensure character compares to blank are unsignedJean Perier2022-09-131-0/+2
| | | | | | | | CompareToBlankPadding was doing signed compare on architecture where `char` is signed. This caused `'abc'//char(128) > 'abc'` to evaluate to false at runtime instead of true. Differential Revision: https://reviews.llvm.org/D133693
View Lorry Controller Status