Good First Issues in Assembly

A Featurerequest. 😀 I suggest an Screensaver, which Show the Actual time. This Thing May Have Features like Different fonts... Different Clockstiles.... But if it only Show time. Everything is ok. 😀

Code of Conduct I have searched the existing bug issues. I am a human engaging in an interpersonal interaction. During this interaction, my words are my own and are not generated. If relevant, I provide links to my sources. CVA6 commit affected 6348e9e Bug Description In frontend, the prediction always_comb computes ras_push/ras_pop/ras_update as single scalars in a loop that runs the fetch slots high-index down to slot 0. The branch arm clears ras_push/ras_pop unconditionally, including when the branch is not taken. A not-taken branch falls through, so the upper slot behind it is on-path and consumed. Because slot 0 is processed last, its not-taken arm overwrites the push/pop the upper call/return just set. predict_address is unaffected and the redirect this cycle is correct. Only the RAS update is lost, so a dropped push mispredicts the eventual ret, and a dropped pop corrupts the next return. Reachable on any RVC config (INSTR_PER_FETCH = 2, e.g. cv32a6_imac_sv32). Buggy Code co

Describe the bug compute.NewDatumWithoutOwning returns the same Datum implementation as compute.NewDatum, so calling Release() on it compiles and runs like any other datum. But the datum did not retain the value, so that Release() drops the reference the caller's array still depends on: the allocator reports the buffers freed while the array is in scope and readable, and the array's own later Release() does not panic. The doc comment says "should not have Release called on it", and ends with a truncated sentence: "For the most part this is just a convenience function.+-" (datum.go line 278). With the Go allocator this is silent, because the memory stays alive under the garbage collector. With a C allocator, or when the buffers were imported from C through the cdata package, the same call frees memory under a live array. Go 1.27.1, macOS 26.6 (arm64), arrow-go v18.7.0; identical on v18.8.0-rc1. mem := memory.NewCheckedAllocator(memory.NewGoAllocator()) b := array.NewInt64Builder(mem) b.

I have been investigating an issue with the UCSD p-System IV.0 distribution included with RomWBW, using a ZETA V2 system. The standard p-System boots and operates correctly. While adding original UCSD BASIC and FORTRAN IV.0 compilers, I found that both compilers successfully generate code, but even trivial compiled programs fail immediately at runtime with: Unimplemented instruction Segment REALOPS Proc# 14 Offset# 73 This occurs even with a BASIC program containing only: 10 END A minimal FORTRAN program produces the same REALOPS error. We investigated the RomWBW p-System distribution and found that SYSTEM.INTERP is based on INTERP.Z.CODE. The distribution contains INTERP.Z.CODE, RSP.CODE, BIOS.CRP.CODE, INTER.X.CODE and TERTBOOT.CODE, but no FP0.CODE, FP2.Z.CODE or FP4.CODE. According to the SofTech p-System IV.0 adaptable-system documentation, floating-point support is supplied separately when configuring the interpreter. For a Z80 system using four-word REALs, the expected configura

Describe the enhancement requested Add client-side test coverage for Substrait prepared statements in arrow/flight/flightsql/client_test.go. PR #732 added server-side coverage for CreatePreparedSubstraitPlan, but the review discussion identified that the corresponding client path has no dedicated tests. The tests should cover: Client.PrepareSubstrait constructing a CreatePreparedSubstraitPlan action with the supplied plan bytes and Substrait version. Parsing the returned prepared-statement handle and schemas. Preserving all three is_update states: absent, false, and true. Txn.PrepareSubstrait request construction, including the transaction ID, if it is not already covered through shared helpers. Query and update execution do not need duplicate coverage here: after prepared-statement creation, Substrait and SQL use the same Flight SQL execution paths. Component(s) Integration

Here is a debug from zsid (register E is set with 53, but the line got cut off) B=01, C=00, E=53 #ta ----I A=53 B=0053 D=0053 H=1780 S=0EB2 P=175F ----- A'00 B'0000 D'0000 H'0000 X=0000 Y=0000 LD C,00 ----I A=53 B=0000 D=0053 H=1780 S=0EB2 P=1761 ----- A'00 B'0000 D'0000 H'0000 X=0000 Y=0000 LD B,01 ----I A=53 B=0100 D=0053 H=1780 S=0EB2 P=1763 ----- A'00 B'0000 D'0000 H'0000 X=0000 Y=0000 CALL FFF0 ----I A=53 B=0100 D=0053 H=1780 S=0EB0 P=FFF0 ----- A'00 B'0000 D'0000 H'0000 X=0000 Y=0000 JP FE04 ----I A=53 B=0100 D=0053 H=1780 S=0EB0 P=FE04 ----- A'00 B'0000 D'0000 H'0000 X=0000 Y=0000 LD (FE28),SP ----I A=53 B=0100 D=0053 H=1780 S=0EB0 P=FE08 ----- A'00 B'0000 D'0000 H'0000 X=0000 Y=0000 LD SP,FFE0 ----I A=53 B=0100 D=0053 H=1780 S=FFE0 P=FE0B ----- A'00 B'0000 D'0000 H'0000 X=0000 Y=0000 LD A,(FFE0) ----I A=8E B=0100 D=0053 H=1780 S=FFE0 P=FE0E ----- A'00 B'0000 D'0000 H'0000 X=0000 Y=0000 LD (FFE1),A ----I A=8E B=0100 D=0053 H=1780 S=FFE0 P=FE11 ---

Summary Expose the remaining hipDNN Graph lifecycle, plan-management, inspection, and serialization APIs in the Python bindings. Parent: #10579 Required API Add Python bindings for: build checkTensorUidsSet getTensorsByUid getTensorsByName set_override_shape_enabled is_override_shape_enabled The execution overload accepting runtime shape and stride overrides. to_compiled_plan_binary from_compiled_plan_binary get_execution_plan_count execute_plan_at_index get_workspace_size_plan_at_index get_plan_name_at_index build_plan_at_index get_autotune_workspace_size get_plan_name Use Python-friendly return values for C++ output parameters and preserve optional values and error reporting. The override-shape methods must remain consistent with the existing HIPDNN_ENABLE_SDPA feature guard. Tests Add focused tests for: build and the complete standard graph lifecycle. Tensor UID/name inspection. Plan count, plan selection, plan execution, workspace, and plan-name queries. Compiled-plan serializat

Summary Complete the Python bindings for hipDNN TensorAttributes and scalar tensor metadata. The current binding covers basic dimensions, strides, dtype, UID, name, virtual status, and a float-only set_value. It does not expose the complete public tensor metadata and pass-by-value API needed for full frontend parity or DLPack integration. Parent: #10579 Required API Expose the remaining public tensor metadata methods, including: Scalar tensor construction for all supported value types. get_is_pass_by_value get_pass_by_value get_compile_time_constant get_has_compile_time_constant get_is_runtime_pass_by_value set_as_runtime_parameter set_is_pass_by_value set_compile_time_constant get_value_variant clear_value Ragged-offset getters, setters, and presence checks. Alignment getters and setters. Any remaining public data-type, dimension, stride, output, virtual, UID, and name accessors. Use Python-friendly conversions for C++ scalar variants and optionals. Preserve existing Tensor.create()

This will likely involve a new set of values in the defines file, to coordinate how the tool is addressing into that memory space. - Sizes and raw memory positioning seems to be different than the defined funcs currently present. (I believe those were initially pulled from the emerald decomp?)

Suggestion Description As part of enabling relaxed affine tensor shape requirements for BatchNorm in this PR in hipDNN, the corresponding frontend changes have currently been implemented only for the BatchNorm operation. To fully support this feature across all BatchNorm operations, the same functionality also needs to be implemented in: BatchnormBackwardNode, BatchnormInferenceNode and BatchnormInferenceNodeVarianceExt. Without these changes, users cannot take full advantage of the relaxed affine tensor shape requirements for the batchnorm operation.

While investigating #8530, we reviewed other hipDNN frontend node property inference paths for cases where missing output tensor metadata may be ambiguous or inconsistent with cuDNN frontend behavior. SDPA backward is not ambiguous in the same way as convolution backward data/weight, but it still has validation and layout-policy gaps that should be tracked. Current behavior SdpaBwdNode::infer_properties_node() infers missing gradient output metadata as: dQ.dim = Q.dim dK.dim = K.dim dV.dim = V.dim missing dQ/dK/dV strides are generated with the default packed row-major/BHSD policy This shape inference is deterministic and mathematically correct for SDPA backward, including GQA/MQA: the gradients must match the original tensors they differentiate. This differs from cuDNN frontend, which generally expects backward output descriptors to be supplied, but it is not inherently unsafe the way convolution dx / dw inference can be unsafe. The gap is that hipDNN currently accepts caller-suppli

The main goal is to have official package in Debian distro (and other Debian-based Linux distros over time) This is follow up on work done in #267 Current status: .deb files can be built, pass lintian checks, salsa CI builds and runs all jobs of its pipeline, packaging how-to and helper files are established and it should be reasonably easy to keep the package up to date in future. To test current .deb package you can download it from salsa CI build or build yourself from salsa repository (or mentors site if it's still available there). Initial non-formal feedback from one of Debian Developers was "RTFM, start from scratch" - which I have still not a slightest idea why/what/how to change. So this is stalled until we get better info what could be improved or decide to go ahead with current state and try harder to find mentor/sponsor. TODO: get Debian mentor who will review and provide constructive feedback how to make the package acceptable get Debian sponsor for upload (open "reques

figure out what is the current best practice to sign releases on GitHub check also Debian's wiki and finalize plan some reddit list of key servers in case we will publish keys there prepare tooling/how-to sign next release adjust debian packaging repo (file debian/watch) to check signatures

Context From PR #6296 review by @mousdahl-amd — merged as-is with this tracked as a follow-up. Problem The integration round-trip tests (JSON and binary serialize/deserialize) manually compare every field of the deserialized graph against expected values. This is verbose and fragile — each new field requires updating every round-trip test. Proposal Implement Equals, (Possibly call it LogicallyEquals) for: Graph Node (and its concrete subtypes or via virtual dispatch) Tensor operator == likely should also compare the backend descriptors, and for the checks we want here, it should be skipped. Likely want to split into two things with overlapping support. LogicallyEquals which compares logical equivalency of the graph state (Graph properties + Nodes + Tensor definitions all match). Operator==, that checks LogicallyEquals && the descriptor pointers / lowering state. Tests can use LogicallyEquals, and consumers can use LogicallyEquals for checking if graphs represent the same operatio

[Migrated from original issue] ROCm/composable_kernel#688 Original issue author: @junliume *Full blown fix for Workaround #687 * We need to fix them as a quality improvement, but for now suppressing this warning in immediate releases: http://compiler-ci.amd.com/blue/rest/organizations/jenkins/pipelines/compiler-psdb-amd-stg-open/runs/2540/nodes/282/steps/3202/log/?start=0 e.g. majority of the issues are happening in the following two files [2023-04-26T17:26:31.524Z] /jenkins/workspace/compiler-psdb-amd-stg-open/Libs/MIOpen/deps_hip/cget/build/tmp-a3db5da587a64213bde99fb856db1b43/composable_kernel-0f98035df1cc5ba3e90ab03187e672b426a25b00/include/ck/utility/generic_memory_space_atomic.hpp:52:19: error: unsafe pointer arithmetic [-Werror,-Wunsafe-buffer-usage] [2023-04-26T17:26:31.524Z] atomicAdd(c_style_pointer_cast<float*>(p_dst) + 1, vx.template AsType<float>()[I1]); [2023-04-26T17:26:31.524Z] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [2023-04-26T17:26:31.523Z] /je

Any fork of this repository upon each commit attempts to publish a GitHub Pages site of the changes being made to the repository, and then fails to do so. I am unfortunately less familiar with GitHub actions than I would like to be so I am unsure if this is even something that can be avoided. But it would be very nice if it could. The error messages involved can be viewed here as an example and are shown below as well: Deploy to GitHub pages Error: Failed to create deployment (status: 404) with build version 13ce6651d0d00a7d4a855f3d2f03d7d756f9f0e3. Request ID A001:748CB:4D81E55:4F0C036:69733936 Ensure GitHub Pages has been enabled: https://github.com/Les-Wet/gb-asm-tutorial/settings/pages HttpError: Not Found at /home/runner/work/_actions/actions/deploy-pages/v4/node_modules/@octokit/request/dist-node/index.js:124:1 at processTicksAndRejections (node:internal/process/task_queues:95:5) at createPagesDeployment (/home/runner/work/_actions/actions/deploy-pages/v4/src/internal

Suggestion Description Add integration tests in plugins/miopen_legacy_plugin/integration_tests/ to verify MIOpen plugin gracefully rejects invalid tensor layouts. Test Cases: 3D tensors → graph.build() returns error (miopen batch norm only supports 4D and 5D tensors) Mixed layouts (X=NCHW, Y=NHWC) → rejected Non-standard stride order (e.g., {0,1,2,3}) → rejected Acceptance Criteria: result.code != ErrorCode::OK No crashes or undefined behavior Error message mentions layout issue Tests follow naming convention: IntegrationGpuBatchnormUnhappyLayouts Tests added to plugins/miopen_legacy_plugin/integration_tests/ Reference: See getValidateSupportedLayoutTestCases() in unit tests

Similarly to what we have in Pan Docs: https://gbdev.io/pandocs/single.html