LLVM/project cc8e2b8llvm/test/tools/llvm-objcopy/ELF binary-output-target.test

[llvm-objcopy] Add AMDGPU case to binary-output-target.test

Add test coverage for converting binary input to elf64-amdgpu format,
verifying the output has the correct format string, arch (amdgpu),
and machine type (EM_AMDGPU 0xE0). Follows the same pattern as all
other architectures in this test file.
DeltaFile
+6-0llvm/test/tools/llvm-objcopy/ELF/binary-output-target.test
+6-01 files

LLVM/project d111119llvm/test/tools/llvm-objcopy/ELF binary-output-target.test

[llvm-objcopy] Fix AMDGPU arch checks in tests

ELFObjectFile.h getArch() for EM_AMDGPU returns Triple::UnknownArch
when e_flags & EF_AMDGPU_MACH is 0 (no GPU target specified). Only
when a MACH flag in the AMDGCN range is present does it return
Triple::amdgpu.

- cross-arch-headers.test: restore EF_AMDGPU_MACH_AMDGCN_GFX900 flag
  on the input ELF so that after format conversion the output correctly
  reports Arch: amdgpu.

- binary-output-target.test: expect Arch: unknown since converting
  from raw binary input (-I binary) produces an ELF with e_flags=0
  (no MACH flags), giving UnknownArch. This is correct behavior.
DeltaFile
+1-1llvm/test/tools/llvm-objcopy/ELF/binary-output-target.test
+1-11 files

FreeBSD/src a3b5937lib/libsys mknod.2

mknod.2: properly document root requirements

Submitted by:   Martijn Dekker <mcdutchie at hotmail.com>
PR:     297082
Fixes:  4090d103b0c3 ("mknod.2: update the man page")
MFC after:      3 days
DeltaFile
+1-1lib/libsys/mknod.2
+1-11 files

LLVM/project 5e91f5dllvm/lib/Transforms/Vectorize SLPVectorizer.cpp, llvm/test/Transforms/SLPVectorizer/X86 schedule-bundle-missing-for-expanded-binop-parent.ll

[SLP]Fix dep accounting for expanded binops in non-scheduled entries

The extra dependency counted for the expanded form was never released
when the expanding entry had no schedule bundle and the block had no
copyable elements, leaving the operand's bundle unscheduled forever.
Take the pseudo-bundle path also when the instruction is an expanded
binop in some tree entry.

Fixes #212220

Reviewers: 

Pull Request: https://github.com/llvm/llvm-project/pull/212380
DeltaFile
+47-0llvm/test/Transforms/SLPVectorizer/X86/schedule-bundle-missing-for-expanded-binop-parent.ll
+17-14llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
+64-142 files

OpenBSD/ports jovM0ebnet/ergo Makefile distinfo, net/ergo/pkg PLIST

   Update to ergo-2.19.0

   From Lydia Sobot (maintainer)
VersionDeltaFile
1.2+5-0net/ergo/pkg/PLIST
1.5+2-2net/ergo/distinfo
1.6+1-1net/ergo/Makefile
+8-33 files

OpenBSD/ports qThMfAXsysutils/moor Makefile modules.inc

   Update to moor-2.15.2

   From Lydia Sobot (maintainer)
VersionDeltaFile
1.11+12-10sysutils/moor/distinfo
1.5+4-3sysutils/moor/modules.inc
1.11+1-1sysutils/moor/Makefile
+17-143 files

OpenBSD/ports KC9RZFUsysutils/node_exporter Makefile distinfo

   Update to node_exporter-1.12.1
VersionDeltaFile
1.20+2-2sysutils/node_exporter/distinfo
1.30+1-1sysutils/node_exporter/Makefile
+3-32 files

LLVM/project 67861a2llvm/test/tools/llvm-objcopy/ELF cross-arch-headers.test binary-output-target.test

[llvm-objcopy] Fix AMDGPU arch checks in tests

ELFObjectFile.h getArch() for EM_AMDGPU returns Triple::UnknownArch
when e_flags & EF_AMDGPU_MACH is 0 (no GPU target specified). Only
when a MACH flag in the AMDGCN range is present does it return
Triple::amdgpu.

- cross-arch-headers.test: restore EF_AMDGPU_MACH_AMDGCN_GFX900 flag
  on the input ELF so that after format conversion the output correctly
  reports Arch: amdgpu.

- binary-output-target.test: expect Arch: unknown since converting
  from raw binary input (-I binary) produces an ELF with e_flags=0
  (no MACH flags), giving UnknownArch. This is correct behavior.
DeltaFile
+1-1llvm/test/tools/llvm-objcopy/ELF/cross-arch-headers.test
+1-1llvm/test/tools/llvm-objcopy/ELF/binary-output-target.test
+2-22 files

FreeBSD/ports e385accdatabases/couchdb3 Makefile pkg-plist

databases/couchdb3: Bump PORTREVISION after erlang-runtime28 update
DeltaFile
+367-367databases/couchdb3/pkg-plist
+1-1databases/couchdb3/Makefile
+368-3682 files

FreeBSD/ports f2a23d4lang/erlang-wx Makefile distinfo

lang/erlang-wx: Update to 28.5.0.4
DeltaFile
+3-3lang/erlang-wx/distinfo
+1-1lang/erlang-wx/Makefile
+4-42 files

FreeBSD/ports 131f496lang/erlang-java Makefile distinfo

lang/erlang-java: Update to 28.5.0.4
DeltaFile
+3-3lang/erlang-java/distinfo
+1-1lang/erlang-java/Makefile
+4-42 files

FreeBSD/ports 8aad612lang/erlang-doc Makefile distinfo

lang/erlang-doc: Update to 28.5.0.4
DeltaFile
+3-3lang/erlang-doc/distinfo
+1-1lang/erlang-doc/Makefile
+4-42 files

FreeBSD/ports a2553a6lang/erlang Makefile distinfo

lang/erlang: Update to 28.5.0.4
DeltaFile
+3-3lang/erlang/distinfo
+1-1lang/erlang/Makefile
+4-42 files

FreeBSD/ports 2bd35a7lang/erlang-runtime28 Makefile distinfo

lang/erlang-runtime28: Update to 28.5.0.4
DeltaFile
+3-3lang/erlang-runtime28/distinfo
+1-2lang/erlang-runtime28/Makefile
+4-52 files

FreeBSD/ports 71bbe28lang/erlang-runtime27 Makefile distinfo

lang/erlang-runtime27: Update to 27.3.4.15
DeltaFile
+3-3lang/erlang-runtime27/distinfo
+1-2lang/erlang-runtime27/Makefile
+4-52 files

FreeBSD/ports 3399ba8lang/erlang-man Makefile distinfo

lang/erlang-man: Update to 28.5.0.4
DeltaFile
+3-3lang/erlang-man/distinfo
+1-1lang/erlang-man/Makefile
+4-42 files

FreeBSD/ports 52d8a78lang/erlang-runtime29 Makefile distinfo

lang/erlang-runtime29: Update to 29.0.4
DeltaFile
+3-3lang/erlang-runtime29/distinfo
+1-1lang/erlang-runtime29/Makefile
+4-42 files

FreeBSD/ports f715d62security/vuxml/vuln 2026.xml

security/vuxml: Document Erlang/OTP vulnerabilities fixed in OTP 29.0.4, 28.5.0.4 and 27.3.4.15
DeltaFile
+349-0security/vuxml/vuln/2026.xml
+349-01 files

LLVM/project 9121283clang/docs ReleaseNotes.md, clang/lib/UnifiedSymbolResolution USRGeneration.cpp

[clang][Index][USR] Generate USRs for class-type non-type template arguments (#212356)

A class-type non-type template parameter is represented in the AST by a
TemplateParamObjectDecl, which has an empty DeclarationName.
USRGenerator had no visitor for it, so it fell through to
VisitNamedDecl, where EmitDeclName fails on the empty name and sets
IgnoreResults. That discarded the USR of the enclosing declaration.

Add a visitor that encodes the parameter object's type and value, so
specializations on distinct values get distinct USRs and equal values
agree.

Fixes #212351
DeltaFile
+27-0clang/test/Index/USR/class-type-tpl-arg.cpp
+10-0clang/lib/UnifiedSymbolResolution/USRGeneration.cpp
+2-0clang/docs/ReleaseNotes.md
+39-03 files

OpenBSD/ports eRutmVagames/godot/pack3 Makefile distinfo, games/godot/pack3/patches patch-godotsteam_godotsteam_cpp patch-godotsteam_godotsteam_h

   Update to Godot (pack3) maintenance release 4.7.1. Release notes:
   https://godotengine.org/article/maintenance-release-godot-4-7-1/

   While Godot still can't build the godotsteam extension and it thus
   remains disabled, still move version of godotsteam up to the most
   recent one that should support our version of the steam api (via
   goldberg_emulator port). I keep my hopes up for now that Godot will
   fix the extension building issues.
VersionDeltaFile
1.2+146-146games/godot/pack3/patches/patch-godotsteam_godotsteam_h
1.2+38-68games/godot/pack3/patches/patch-godotsteam_godotsteam_cpp
1.5+4-4games/godot/pack3/distinfo
1.6+2-2games/godot/pack3/Makefile
+190-2204 files

LLVM/project 123063fclang/lib/CodeGen CGOpenMPRuntime.cpp, clang/test/OpenMP target_map_nested_ptr_member_mapper_codegen.cpp

[OpenMP] Propagate PRESENT to pointee entries in mapper codegen

Extend map-type-modifier propagation in emitUserDefinedMapper to the PRESENT
modifier, but only for entries that have an attach ptr (the pointee data, whose
storage differs from the struct's own). A present modifier on the outer clause
must require that pointee to be present on the device.

This is gated on a new PropagatePresentToPointee argument, which Clang sets from
CGM.getLangOpts().OpenMP >= 60. Before 6.0 the present modifier is treated as
not applying to the pointee: the spec committee confirmed the divergence
between the present motion modifier (to/from) and the present map-type modifier
(map) was unintentional, to be fixed as an OpenMP 6.0 erratum. Only propagation
is gated; present written directly in a mapper's own clause applies at all
versions.

A TODO notes PRESENT should also propagate to the struct's own members, which
is blocked while pointer members use PTR_AND_OBJ.

Update the present-check tests to their final 6.0-gated behavior.

    [2 lines not shown]
DeltaFile
+36-11llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+10-17offload/test/mapping/mapper_target_update_present_ptee.c
+14-13offload/test/mapping/mapper_map_mbr_then_present_mbr_ptee.c
+13-4llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
+6-9clang/test/OpenMP/target_map_nested_ptr_member_mapper_codegen.cpp
+12-3clang/lib/CodeGen/CGOpenMPRuntime.cpp
+91-576 files

LLVM/project 5f0e43bclang/lib/CodeGen CGOpenMPRuntime.cpp, clang/test/OpenMP declare_mapper_codegen.cpp target_map_nested_ptr_member_mapper_codegen.cpp

[OpenMP][Clang] Enable ATTACH-style maps for mappers.

Track per-entry attach-ptr info (HasAttachPtr) through mapper codegen so that
emitUserDefinedMapper does not add a new outer MEMBER_OF to pointee/combined
entries (which occupy different storage than the struct) or to ATTACH entries.
Clang and the MLIR translator populate the per-entry array in parallel with the
other MapInfosTy arrays.

Address review:
  - Rename MapSkipMemberOfArrayTy to MapHasAttachPtrArrayTy to match the
    HasAttachPtr field it backs.
  - Restructure the emitUserDefinedMapper comment into a bulleted (*)/(**)/(***)
    list keyed to the example entries.
  - Reword the Clang comments: HasAttachPtr marks pointee entries that have a
    base attach-ptr; a combined entry has a base attach-ptr if its constituents
    do; cross-reference emitUserDefinedMapper for the MEMBER_OF rationale.
  - Update the moved present-check tests to their now-correct behavior (the
    attach-style maps make the inbounds present checks pass and remove the
    "explicit extension" errors).

    [2 lines not shown]
DeltaFile
+196-160clang/test/OpenMP/target_map_nested_ptr_member_mapper_codegen.cpp
+68-60clang/test/OpenMP/declare_mapper_codegen.cpp
+56-15llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+65-5clang/lib/CodeGen/CGOpenMPRuntime.cpp
+18-24offload/test/mapping/mapper_enter_data_always_present_ptee.c
+18-22offload/test/mapping/mapper_map_mbr_then_present_mbr_ptee.c
+421-28611 files not shown
+493-36117 files

LLVM/project 021f7f4clang/test/OpenMP declare_mapper_codegen.cpp target_map_array_section_of_structs_with_nested_mapper_codegen.cpp, llvm/lib/Frontend/OpenMP OMPIRBuilder.cpp

[OpenMP] Propagate ALWAYS/DELETE/CLOSE map-type modifiers to mapper entries

When a map clause uses a user-defined mapper, the map-type-modifying bits
(ALWAYS, DELETE, CLOSE) on the outer clause must apply to each map the mapper
inserts (OpenMP 6.0:281:34). Propagate them in emitUserDefinedMapper by OR-ing
the imported modifier bits into each pushed component, except ATTACH entries
(ATTACH|ALWAYS is reserved for attach(always) and the other bits are
meaningless for ATTACH).

PRESENT is intentionally not propagated here yet (a TODO notes it is handled in
a follow-on, since it requires distinguishing pointee entries from the struct's
own storage).

Update the offload always-propagation tests to their now-correct behavior:
ALWAYS forces a member transfer that the ref count would otherwise suppress, so
mapper_map_always_from.c reads s.y back as 111, and the enter-data variants
(C and Fortran) see 111 in the device copy (all were 0 before this change).
Since emitUserDefinedMapper is shared between clang and flang, the Fortran test
covers the flang path as well.

    [2 lines not shown]
DeltaFile
+152-136clang/test/OpenMP/target_map_nested_ptr_member_mapper_codegen.cpp
+87-77clang/test/OpenMP/target_map_array_section_of_structs_with_nested_mapper_codegen.cpp
+87-77clang/test/OpenMP/target_map_array_of_structs_with_nested_mapper_codegen.cpp
+38-2llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+27-9clang/test/OpenMP/declare_mapper_codegen.cpp
+11-17offload/test/offloading/fortran/mapper-map-always-to-enter-data.f90
+402-3187 files not shown
+443-37013 files

LLVM/project ece9735offload/test/mapping mapper_map_always_to_enter_data.c, offload/test/offloading/fortran mapper-map-always-to-enter-data.f90

[OpenMP][test] Add mapper ALWAYS-propagation tests with no target construct

Companions to mapper_map_always_from.c that exercise ALWAYS propagation into a
user-defined mapper's entries without entering any target region. The device
copy is inspected directly via omp_get_mapped_ptr() and omp_target_memcpy(), so
the check covers only the data-motion performed by `target enter data`.

The Fortran variant is the first Fortran offload test that runs on the host
(x86_64) target: it needs no device kernel, so it does not depend on a device
runtime being available.

Both tests currently CHECK the pre-propagation behavior (the transfer is
suppressed for the already-mapped entry) and record the expected value in a
FIXME.
DeltaFile
+71-0offload/test/offloading/fortran/mapper-map-always-to-enter-data.f90
+60-0offload/test/mapping/mapper_map_always_to_enter_data.c
+131-02 files

LLVM/project e364a21llvm/include/llvm/Transforms/IPO Instrumentor.h, llvm/lib/Transforms/IPO Instrumentor.cpp

[Instrumentor] Reintroduce runtime inlining (#208072)

The ability to link in and eagerly inline a specified runtime was
present in older dev versions of the instrumentor. This patch ports that
functionality to the current instrumentor pass and adds a test.

Co-authored-by: Johannes Doerfert <johannes at jdoerfert.de>
Co-authored-by: Kevin Sala <salapenades1 at llnl.gov>
Co-authored-by: Ivan Radanov Ivanov <ivanov.i.aa at m.titech.ac.jp>
DeltaFile
+218-0llvm/test/Instrumentation/Instrumentor/inline_runtime.ll
+71-0llvm/lib/Transforms/IPO/Instrumentor.cpp
+14-0llvm/test/Instrumentation/Instrumentor/inline_runtime_config.json
+13-0llvm/test/Instrumentation/Instrumentor/runtimes/bytes_computed_rt.ll
+5-1llvm/test/Instrumentation/Instrumentor/default_config.json
+6-0llvm/include/llvm/Transforms/IPO/Instrumentor.h
+327-12 files not shown
+330-28 files

FreeBSD/ports a730b42science/rdkit Makefile

science/rdkit: Broken on 16 arm64

Reported by:    fallout

(cherry picked from commit 07ededc4f224e55a18d23749d8024d55c6ddf2d8)
DeltaFile
+1-0science/rdkit/Makefile
+1-01 files

FreeBSD/ports fe2a2fdscience/rdkit Makefile

science/rdkit: correction

(cherry picked from commit a0e09ce96eeb4522c633d56a1899c22406cd5fcf)
DeltaFile
+1-1science/rdkit/Makefile
+1-11 files

FreeBSD/ports a0e09cescience/rdkit Makefile

science/rdkit: correction
DeltaFile
+1-1science/rdkit/Makefile
+1-11 files

LLVM/project 63fe0cfllvm/include/llvm/CodeGen BasicTTIImpl.h, llvm/test/Transforms/RelLookupTableConverter unnamed_addr.ll

Reapply "Disable RelLookupTableConverter on AArch64" (#212358)

This reverts commit ce8cf3f0a427f7fcf178a9a64ea48a4167211f82 (#207046).

Reland of #204669.


https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst#code-models
says that under the small code model rodata + text must fit in 2GB, but
the RelLookupTableConverter pass introduces PREL32 relocations from
.rodata to .data.rel.ro:

```
$ cat /tmp/a.c
extern void ext_func0(void);
extern void ext_func1(void);

typedef void (*func_t)(void);


    [24 lines not shown]
DeltaFile
+47-0llvm/test/Transforms/RelLookupTableConverter/AArch64/no_relative_lookup_table.ll
+0-40llvm/test/Transforms/RelLookupTableConverter/unnamed_addr.ll
+4-3llvm/include/llvm/CodeGen/BasicTTIImpl.h
+51-433 files

FreeBSD/ports 07ededcscience/rdkit Makefile

science/rdkit: Broken on 16 arm64

Reported by:    fallout
DeltaFile
+1-0science/rdkit/Makefile
+1-01 files