[AArch64] Allow variadic calls with SVE argument if it is named. (#136833)
The following case used to work:
void foo(svint32_t a, ...);
void bar(svint32_t a) { foo(a); }
but 6c9086d13fa7e1069e75ed2d139aae30ee3863c8 introduced a regression
that wasn't caught by the existing test `sve-varargs.ll` because the
call in the test wasn't a tail call and therefore skipped the code-path
with the `report_fatal_error`.
www/gohugo: Update to 0.146.7
ChangeLog: https://github.com/gohugoio/hugo/releases/tag/v0.146.7
Bug fixes
* Revert the breaking change from 0.146.0 with dots in content filenames
* tpl: Fix indeterminate template lookup with templates with and without lang
* tpl/collections: Fix where ... not in with empty slice
* tpl: Fix layout fall back logic when layout is set in front matter but not
found
Improvements
* parser/metadecoders: Add CSV targetType (map or slice) option to
transform.Unmarshal
* tpl: Detect and fail on infinite template recursion
Dependency Updates
[4 lines not shown]
[flang] Retrieve shape from selector when generating assoc sym type
This PR extends `genSymbolType` so that the type of an associating symbol
carries the shape of the selector expression, if any. This is a fix for
a bug that triggered when an associating symbol is used in a locality
specifier. For example, given the following input:
```fortran
associate(a => aa(4:))
do concurrent (i = 4:11) local(a)
a(i) = 0
end do
end associate
```
before the changes in the PR, flang would assert that we are casting
between incompatible types. The issue happened since for the associating
symbol (`a`), flang generated its type as `f32` rather than
`!fir.array<8xf32>` as it should be in this case.
[flang] Retrieve shape from selector when generating assoc sym type
This PR extends `genSymbolType` so that the type of an associating symbol
carries the shape of the selector expression, if any. This is a fix for
a bug that triggered when an associating symbol is used in a locality
specifier. For example, given the following input:
```fortran
associate(a => aa(4:))
do concurrent (i = 4:11) local(a)
a(i) = 0
end do
end associate
```
before the changes in the PR, flang would assert that we are casting
between incompatible types. The issue happened since for the associating
symbol (`a`), flang generated its type as `f32` rather than
`!fir.array<8xf32>` as it should be in this case.
[lldb][MachO] MachO corefile support for riscv32 binaries (#137092)
Add support for reading a macho corefile with CPU_TYPE_RISCV and the
riscv32 general purpose register file. I added code for the floating
point and exception registers too, but haven't exercised this. If we
start putting the full CSR register bank in a riscv corefile, it'll be
in separate 4k byte chunks, but I don't have a corefile to test against
that so I haven't written the code to read it.
The RegisterContextDarwin_riscv32 is copied & in the style of the other
RegisterContextDarwin classes; it's not the first choice I would make
for representing this, but it wasn't worth changing for this cputype.
rdar://145014653
[cfi] Fix one -fno-sanitize-merge case, and add two TODOs (#135438)
-fno-sanitize-merge (introduced in
https://github.com/llvm/llvm-project/pull/120464) nearly works for CFI:
code that calls EmitCheck will already check the merge options. This
patch fixes one EmitTrapCheck call, which did not check the merge
options, and for two other EmitTrapChecks, adds two TODOs that explain
why it is difficult to fix them.
[libclc] only check filename part of the source for avoiding duplication (#135710)
llvm-diff shows this PR has no changes to amdgcn--amdhsa.bc.
Motivation is that in our downstream the same category of target
built-ins, e.g. math, are organized in several different folders. For
example, in target SOURCES we have math-common/cos.cl, while in generic
SOURCES it is math/cos.cl. Based on current check rule that compares
both folder name and base filename, target math-common/cos.cl won't
override math/cos.cl when collecting source files from SOURCES files in
cmake function libclc_configure_lib_source.
With this PR, we allow folder name to be different in the process.
A notable change of this PR is that two entries in SOURCES with the same
base filename must not implements the same built-in.
[memprof] Dump the number of matched frames (#137082)
This patch teaches readMemprof to dump the number of frames for each
allocation site match. This information helps us analyze what part of
the call stack in the MemProf profile has matched the IR.
Aside from updating existing test cases, this patch adds one more test
case, memprof-dump-matched-alloc-site.ll, because none of the existing
test cases has the number of frames greater than one.
