BSD Commit Log Search

[flang][NFC] Converted five tests from old lowering to new lowering (part 45) (#192265)

Tests converted from test/Lower: io-statement-2.f90, io-statement-3.f90,
io-statement-big-unit-checks.f90, io-statement-open-options.f90,
io-write.f90

   doc: Updated devel/py-maturin to 1.13.1

   py-maturin: update to 1.13.1.

   1.13.1

   fix: fall back to placeholder for abi3 when found interpreters are too old by @messense in #3126

   1,13

   maturin 1.13.0 is a feature-rich release focused on better wheel
   generation, improved packaging workflows, and smoother cross-platform
   builds. This release adds new capabilities for stub generation and
   PGO builds, significantly improves wheel repair support on macOS
   and Windows, and includes a broad set of fixes for ABI tagging,
   source distributions, and platform-specific build behavior.

[llvm][DebugInfo] Use formatv in DWARFExpressionPrinter (#191993)

This relates to #35980.

try

extract ctor from CXXNew

[lldb] Declare return type of lldbutil.run_to_source_breakpoint (#190028)

Helpful for remembering the types of the four return values (and their
order).

[HLSL] Mark vector and matrix constructor-turned-InitListExprs as ListInitializations (#192151)

Fixes #189086

This PR fixes a bug for HLSL where vector and matrix constructors that
have been turned into initializer lists via
https://github.com/llvm/llvm-project/blob/18519f34650db7fc8e1885ac0293c1e9a5f1b071/clang/lib/Sema/SemaInit.cpp#L6993-L7000
were not marked with ListInitialization = true, which causes template
re-instantiation to fail because the initialization with a InitListExpr
gets classified as a InitializationKind::IK_Direct instead of a
InitializationKind::IK_DirectList when ListInitialization is false.

Assisted-by: Claude Opus 4.6

[AMDGPU] Enable real true16 on gfx1250 (#190452)

Minor stylistic cleanup

[PowerPC] Implement Elliptic Curve Cryptography Builtins (#184681)

Add support for the following ISA Future elliptic curve cryptograpy
builtins.

* Builtins with immediate parameters:
vector unsigned char __builtin_xxmulmul(vector unsigned char, vector
unsigned char, unsigned int);
vector unsigned char __builtin_xxmulmulhiadd(vector unsigned char,
vector unsigned char, unsigned int, unsigned int, unsigned int); vector
unsigned char __builtin_xxmulmulloadd(vector unsigned char, vector
unsigned char, unsigned int, unsigned int); vector unsigned char
__builtin_xxssumudm(vector unsigned char, vector unsigned char, unsigned
int);
vector unsigned char __builtin_xxssumudmc(vector unsigned char, vector
unsigned char, unsigned int);
vector unsigned char __builtin_xxssumudmcext(vector unsigned char,
vector unsigned char, vector unsigned char, unsigned int);


    [32 lines not shown]

[lldb][windows] recommend building with Python 3.11 (#191159)

As of https://github.com/llvm/llvm-project/pull/176387 and release 22,
official builds of lldb on Windows use Python 3.11 both on x64 and
arm64.

The Windows lldb build bots use 3.11+ versions of Python:

[lldb-x86_64-win](https://lab.llvm.org/buildbot/#/builders/211) -
`3.12.7`
[lldb-remote-linux-win](https://lab.llvm.org/buildbot/#/builders/197) -
`3.12.7`
[lldb-aarch64-windows](https://lab.llvm.org/buildbot/#/builders/141) -
`3.11.9`

This patch changes the cmake config and documentation to recommend
building lldb on Windows with Python 3.11 or more recent.

In the future, given the reduced number of lldb maintainers on Windows
compared to other platforms, bumping the Python version on Windows would
help reduce the surface area of Python related bugs.

   doc: Updated lang/py-librt to 0.9.0

   py-librt: update to 0.9.0.

   Changes not found.

   doc: Updated security/py-google-auth to 2.49.2

[AMDGPU] Fix .Lfunc_end label placement (#191526)

Now it is placed after the kernel descriptor, even the section is
.rodata, which is wrong. This allows proper code size calculation in MC.

   py-google-auth: update to 2.49.2.

   Changes not found.

   doc: Updated www/py-google-api-python-client to 2.194.0

   py-google-api-python-client: update to 2.194.0.

   API updates.

Revert "[SimplifyCFG] Reuse function comdat for switch lookup table (#190995)" (#192294)

This reverts commit 4e3a074501cae5f132293d56f9987ded94ee72be.

CI broke with errors that look very much like they're caused by #190995.
I can't merge, so someone else will have to.

https://lab.llvm.org/buildbot/#/builders/94/builds/16933
https://lab.llvm.org/buildbot/#/builders/55/builds/26779

   doc: Updated devel/py-google-api-core to 2.30.3

   py-google-api-core: update to 2.30.3.

   API updates.

Extend post_order's lifetime

Don't pass RecipeBuilder

Legacy calls `setRecipe` on all processed recipes but really queries `getRecipe`
for memory operations only, that we don't touch in the scalarization as that
happens after all memory recipes has been processed.

Just use `vputils::onlyFirstLaneUsed`

Use `reverse`/`IsaPred`

[VPlan] Scalarize to first-lane-only directly on VPlan

This is needed to enable subsequent https://github.com/llvm/llvm-project/pull/182595.

I don't think we can fully port all scalarization logic from the legacy
path to VPlan-based right now because that would require us to introduce
interleave groups much earlier in VPlan pipeline, and without that we
can't really `assert` this new decision matches the previous CM-based
one. And without those `assert`s it's really hard to ensure we properly
port all the previous logic.

As such, I decided just to implement something much simpler that would
be enough for #182595. However, we perform this transformation before
delegating to the old CM-based decision, so it **is** effective
immediately and taking precedence even for consecutive loads/stores
right away.

Depends on https://github.com/llvm/llvm-project/pull/182592 but is stacked on
top of https://github.com/llvm/llvm-project/pull/182594 to enable linear
stacking for https://github.com/llvm/llvm-project/pull/182595.

try

   doc: Updated textproc/libzim to 9.6.0

   libzim: update to 9.6.0.

   libzim 9.6.0
   ============

    * Optimization of memory usage by dirents during ZIM creation (@veloman-yunkan #1055)
    * Allows to open ZIM with more than ~268M entries on macOS (@jasontitus #1053)
    * Fix ZIM metadata 'Counter' parser by properly ignoring mime-types paramters (@Pranavjeet-Naidu #1050)