The present implementation of defined formatted I/O is incorrect for
arrays in the data item list; it assumes that a DT defined format
descriptor (or list-directed/namelist instance) applies to all of the
elements in the array. The loop over the elements in the array is within
the DefinedFormattedIo() template function that handles defined
formatted I/O, not around its calls. This causes only one format list
edit descriptor to be used for the whole array, which is of course
wrong.
Invert this arrangment by performing the per-element looping in at the
top level in FormattedDerivedTypeIo() instead.
Defined unformatted I/O remains as it was.
Allow C-API users to debug their JITed code via the GDB JIT Interface.
This is currently supported on ELF and MachO based platforms. On
other systems `LLVMOrcLLJITEnableDebugSupport()` returns an error.
This patch adds a new C-API header `LLJITUtils.h`, which can host
further advanced JIT features in the future. Using the header requires
linking against LLVMOrcDebugging.
Currently there's an include in which `[opt]` might be emitted twice if
the frame format also asks for it. As a trivial fix, we should manually
emit `[opt]` only if a custom frame format is not specified.
Defined unformatted I/O is not allowed except from/to an external unit.
This restriction prohibits an INQUIRE(IOLENGTH=n) statement from using
derived types with defined unformatted output in its I/O list. The
runtime currently detects this case and crashes with an internal error;
this patch defines a new I/O error enum and causes the program to crash
with a more useful message.
Neoverse N2 was incorrectly marked as an Armv8.5a core. This has been
changed to an Armv9.0a core. However, crypto options are not enabled
by default for Armv9 cores, so -mcpu=neoverse-n2+crypto is required
to enable crypto for this core.
Neoverse N2 Technical Reference Manual:
https://developer.arm.com/documentation/102099/0003/
An unsigned integer was being initialized with -1 to set all its bits to
1, but this doesn't work for the BigInt class which may be used as an
integer type on systems that don't support uint128 natively. This patch
moves the initialization to use ~T(0) instead.
Add missing constant propogation folder for Bitwise[Or|And|Xor].
Move previous Bitwise[Or|And] fold implementations to
SPIRVCanonicalization for consistency.
Implement additional folding when lhs == rhs and rhs = 0 for Xor. As
well as, update an Xor testcase to account for this introduced folding.
This helps for readability of lowered code into SPIR-V.
Part of work for #70704
d80e46d added support for the target function attribute. However, it
turns out that commit has a nasty bug/oversight. As the tests in that
revision show, everything works if clang -cc1 is directly invoked. I was
suprised to learn this morning that compiling with clang (i.e. the
typical user workflow) did not work.
The bug is that if a set of explicit negative extensions is passed to
cc1 at the command line (as the clang driver always does), we were
copying these negative extensions to the end of the rewritten extension
list. When this was later parsed, this had the effect of turning back
off any extension that the target attribute had enabled.
This patch updates the logic to only propagate the features from the
input which don't appear in the rewritten form in either positive or
negative form.
Note that this code structure is still highly suspect. In particular I'm
fairly sure that mixing extension versions with this code will result in
odd results. However, I figure its better to have something which mostly
works than something which doesn't work at all.
This is a follow up on #74481 that migrates code from all
specializations into `FPCommonProperties` (except for
`EXPLICIT_BIT_MASK` in the `X86_Binary80` specialization)
We have other targets with scalable vectors (e.g.RISC-V), and there
doesn't seem to be any particular reason these options can't be used on
those targets.
Create a new constant pool entry directly instead of going via a BUILD_VECTOR node, which makes constant pool reuse more difficult.
Helps with some regressions in #73509
According to [wikipedia](https://en.wikipedia.org/wiki/Exponent_bias)
the "biased exponent" is the encoded form that is always positive
whereas the unbiased form is the actual "real" exponent that can be
positive or negative.
`FPBits` seems to be using `unbiased_exponent` to describe the encoded
form (unsigned). This patch simply use `biased` instead of `unbiased`.
Since Dexter no longer intends to build any code, the ShouldBuild
property in any Visual Studio project being run by Dexter should be
false to ensure that a build step is never invoked by Dexter, whether
the project has already been built or not.
Reviewed by: OCHyams
When LLVM_PROFILE_FILE is set incorrectly (e.g. multiple %c) and it
falls back to use `default.profraw` name, but continuous mode is still
set. This might cause signal bus in the following scenario.
LLVM_PROFILE_FILE is set incorrectly (with "%c%c") for process A and B.
Suppose A starts first and falls back to use `default.profraw` and
mmaped its file content to memory. Later B starts and also falls back to
use `default.profraw`, but it will truncate the file because online
merging is disable when reseting to `default.profraw`. When A tries to
update counter via mmaped memory, signal bus will occur.
This fixes it by disabling continuous mode when reset to
default.profraw.
Check for the existence of the macro instead of checking for Solaris.
illumos has this macro in sys/time.h.
/export/home/brad/llvm-brad/openmp/runtime/src/z_Linux_util.cpp:77:9: warning: 'TIMEVAL_TO_TIMESPEC' macro redefined [-Wmacro-redefined]
77 | #define TIMEVAL_TO_TIMESPEC(tv, ts) \
| ^
/usr/include/sys/time.h:424:9: note: previous definition is here
424 | #define TIMEVAL_TO_TIMESPEC(tv, ts) { \
| ^
Per [[class.friend]p6](http://eel.is/c++draft/class.friend#6) a friend
function shall not be defined if its name isn't unqualified. A
_template-id_ is not a name, meaning that a friend function
specialization does not meet this criteria and cannot be defined.
GCC, MSVC, and EDG all consider friend function specialization
definitions to be invalid de facto explicit specializations and diagnose
them as such.
Instantiating a dependent friend function specialization definition
[currently sets off an assert](https://godbolt.org/z/Krqdq95hY) in
`FunctionDecl::setFunctionTemplateSpecialization`. This happens because
we do not set the `TemplateSpecializationKind` of the `FunctionDecl`
created by template argument deduction to `TSK_ExplicitSpecialization`
for friend functions
[here](https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaTemplate.cpp#L9600).
I changed the assert condition because I believe this is the correct
behavior.
* Remove pointer AddressSpaceCast in function `constructPointer`
* Remove 1st parameter (`ResTy`) of function `constructPointer`
1st input argument to function `constructPointer` in all 4 call-sites is
`ptr addrspace(0)`. Function `constructPointer` performs a pointer
AddressSpaceCast to `ResTy`, making the returned pointer have type `ptr
addrspace(0)` in all 4 call-sites.
Unless there's a clear reason to discard the addrspace info of input
parameter `Ptr`, I think we should keep and forward that info to the
returned pointer of `constructPointer`.
Opaque ptr cleanup effort.
This commit factors out the logic building each component of a qualified
name into its own function so that it may be reused by a future commit,
while also simplifying the logic of assembling these pieces together by
using llvm::interleave.
Summary:
We provide `-Xoffload-linker` to pass arguments directly to the link
step. Currently this uses `-Wl,` implicitly which prevents us from using
clang options that we otherwise could make use of. This patch removes
that implicit behavior as users can just as easiliy pass
`-Xoffload-linker -Wl,-foo` if needed.
This PR adds the `-fno-fortran-main` command line option to remove
`Fortran_main.a` from the link and to allow for linking Fortran code w/o
program unit with C/C++ translation units that provide the `main()`
entrypoint.
When linking Fortran code with C/C++ code (Fortran calling into C/C++),
PR #73124 introduced a proper error message that would prevent
successful linkage, if there was a program unit from Fortran *and*
`main()` function coming from C/C++. Alas, this caused some breakage of
code that would call Fortran code from C/C++ and rightfully provided the
`main()` entrypoint. Classic Flang had the command-line option
`-fno-fortran-main` to then remove the entrypoints for the Fortran
program unit from the linker stage.
This PR is related to PR #74120 and (merged) PR #73124.
---------
Co-authored-by: Andrzej Warzyński <andrzej.warzynski@gmail.com>
Fix https://github.com/llvm/llvm-project/issues/74189 (crash report).
The pruning code uses a BitVector to track which parts of a variable have been
defined in order to find redundant debug records. BitVector uses a u32 to track
size; variable of types with a bit-size greater than max(u32) ish* can't be
represented using a BitVector.
Fix the assertion by introducing a limit on type size. Improve performance by
bringing the limit down to a sensible number and tracking byte-sizes instead
of bit-sizes.
Skipping variables in this pruning code doesn't cause debug info correctness
issues; it just means there may be some extra redundant debug records.
(*) `max(u32) - 63` due to BitVector::NumBitWords implementation.
