Method

Every observation on this site comes from small, legal programs compiled and run on the compilers and GPUs below. Each program checks its own result and prints it.

How a result is decided

Each program is compiled and run with time limits, and its outcome is classified from all of the compiler's messages as rejected, internal compiler error, link failure, crash, hang, wrong answer or correct. Its legality is checked against the OpenMP or OpenACC specification text by two independent checkers, neither of them the compiler under test.

A failure counts only when it reproduces in another build directory, on another node and in a repeat run; results that disagree are shown as unknown. Where a program has a control, the control differs by one change and runs correctly on the same compiler. When another compiler family runs the same program correctly, that is listed as evidence too.

States and statuses

Each cell of an issue's table says what happened to the program on that compiler, GPU and memory mode:

behaves incorrectly / not supported: this issue reproduces there.
fails another way: a different failure there; not counted as this issue.
correct: the program's own check passes there.
unknown: not run there, or the runs disagree.

Each issue also says when it fails and how:

At compile time: the compiler refuses the legal program, crashes (an internal compiler error) or does not finish.
At link time: the link step refuses it (an undefined symbol, a missing library) or the offload or LTO tool crashes.
At run time: the program crashes or aborts, stops with a run-time error, hangs, or finishes with a wrong answer.

Legality review

Each issue's program is also read by independent readers that see the program, the specification text and the observed result, but not the argument written for the issue. The readers are language models (Claude Sonnet), each run on its own with no access to the catalog. Every batch of programs a reader gets holds one decoy whose answer is known, an illegal program or a result the specification does not require; a reader that misses its decoy does not count, and neither does one that quotes a passage the specification does not contain, quotes a program line the program does not contain, or says the program lacks something that is there. Two readers read each program. When they disagree or one is uncertain, two more readers adjudicate: they see both readings and check each against the specification, in batches that hold a decoy dispute whose right side is known. Every reading that counts, for an issue or against it, is then fact-checked: a verifier lists the premises the reading rests on and checks each against the specification and the program, in batches that hold a reading with a known false premise and a sound one. A reading two verifiers refute, each with quotes that check out, no longer counts. An argument against an issue's legality, filed from the link on its page, goes to adjudicators the same way. An issue's legality is one of:

independently confirmed: two readers, or two adjudicators of a dispute, find the program legal and the result required.
supported by outside evidence: the readers find the specification unclear, and an official example, a vendor's own bug tracker or a fix in a later release settles it.
contested: an adjudicator (or, before adjudication, a reader) finds the program not legal or the result not required, and nothing outside settles it. The reason is shown on the issue.
not independently confirmed: no review yet, readers uncertain, or the program changed since its review.

An issue's status on a compiler release X is one of:

Fixed in X: correct on X wherever the previous version failed (each GPU and memory mode).
Changed in X: a different failure there from X on.
Not yet run: no result yet on the compiler the program was written for.
Not reproduced in current runs: it ran there and did not fail this way.
Mixed evidence: the program's legality is disputed or not settled; the reason is shown.

Behaviour no tested compiler implements

Three constructs read plainly in the OpenMP 5.2 text and fail on every compiler tested (AFAR, CCE, NVHPC, GCC) and on the host: a firstprivate item initialized by its type's type-bound defined assignment (section 5.4.4), a lastprivate item updated by it (section 5.4.5), and the finalization of a privatized item of a finalizable type at the end of the region (section 5.3). Because no implementation honours them and the failure is not specific to offload, they are not listed as compiler issues here.

HeCBench programs

Some programs come from HeCBench, a public collection of GPU benchmarks (ORNL/HeCBench, one fixed version). Its OpenMP offload versions are built the way the collection's own makefiles say, with each compiler's own offload flags, and checked against a serial host build of the same code or against the program's own check. Half of the benchmarks, chosen in advance by a fixed rule on their names, were used here; the results for the other half are held back and not shown. Benchmarks under copyleft or non-commercial licences are left out. As for every other program, a failure counts only when it reproduces in another build directory, on another node and in a repeat run, and another compiler family runs the same program correctly. The failures found this way are reduced to small programs written for this site; no benchmark code is copied. Runs that hit the 30-second time limit are not counted as issues, because they cannot tell a hang from a slow kernel.

Compilers and GPUs

Compiler	Version	GPUs and memory modes
AMD AFAR	AFAR 24.3.0	MI300A (gfx942, unified memory and copy); MI250X (gfx90a, copy); MI300X (gfx942, copy); MI350X (gfx950, copy)
Cray CCE	19.0.0	MI300A (gfx942, unified memory and copy); MI250X (gfx90a, copy)
Cray CCE	20.0.2	MI300A (gfx942, unified memory and copy); MI250X (gfx90a, copy)
Cray CCE	21.0.3	MI300A (gfx942, unified memory and copy); MI250X (gfx90a, copy)
Cray CCE	21.0.4	MI300A (gfx942, unified memory and copy); MI250X (gfx90a, copy)
NVIDIA HPC SDK	25.11	A100 (sm_80, separate memory and managed memory)
NVIDIA HPC SDK	26.9	A100 (sm_80, separate memory and managed memory)
GNU GCC	16.2.0	MI300A (gfx942, unified memory and copy); MI250X (gfx90a, copy); MI300X (gfx942, copy); MI350X (gfx950, copy)
GNU GCC	16.2.0	A100 (sm_80, separate memory)

Sources and credits

Programs come from a generated catalog of OpenMP and OpenACC constructs, randomized and stress programs, real application codes, and public bug reports and test suites, including the OpenMP Validation and Verification suite, the LLVM project's offload tests (Apache 2.0 with LLVM exception) and AMD's AOMP tests, each credited in its program's header.

Quoted specification text

The passages under "What the specification requires" are quoted, each with its version, section and page, from these documents, whose notices follow.

Permission to copy without fee all or part of this material is granted, provided the OpenMP Architecture Review Board copyright notice and the title of this document appear. Notice is given that copying is by permission of the OpenMP Architecture Review Board.

The OpenACC® Application Programming Interface, Version 3.4, June 2025, OpenACC-Standard.org: © 2011-2025 OpenACC-Standard.org. All rights reserved. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of the authors.