craycc/ftn: OpenMP 5.1/5.2/6.0 forms HPE does not claim are rejected, and some crash the compiler instead of a diagnostic

// # Draft finding: omp52-c-clause-uses_allocators-traits on cce19
//
// - compiler: cce19
// - toolchain: cce19; arch: gfx942; machine: tuolumne; memory mode: unified; opt: -O2
// - program: catalog omp52-c-clause-uses_allocators-traits (c, version 52, sha256 a5d4d553d629ef11)
// - expected: None (None; )
// - actual: rejected  (diagnostic: <tmpdir>/omp52-c-clause-uses_allocators-traits.c:33:23: error: call to undeclared function 'traits'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-de)
// - no control: the 5.0 spelling uses_allocators(my_alloc(my_traits)), once the check case's control (dropped), is an
//   internal compiler error on CCE 19, 20, 21.0.3 and 21.0.4 in both modes and on both GPUs, and AFAR rejects it as old
//   syntax (its rows: data/vendor/checks/results-compact, results-site, variant control), so it does not isolate the
//   rejection
// - verdict: compiler_bug by rule R11-compile-rejection: a legal program the compiler rejects with a diagnostic (or whose link fails on symbols the compiler's own code needs, or whose compile does not finish) while another compiler family compiles it
// - reason: 
// - citations: RUL-COMPILE-TIME (rulings.md)
// - legality: legal (legal by construction: offload.engine.gen / c_gen / acc_gen check every program against the catalog rules and the offload scope as it is built (no compiler))
// - witnesses: none
// - withdrawn: none
//
// Generated by compliance.c_gen (OpenMP 5.2, C11): the C port (offload.engine.f2c) of omp52-clause-uses_allocators-traits. Do not edit.
// id: omp52-c-clause-uses_allocators-traits
// primary atom: omp.clause.uses_allocators.traits
// legal: yes
// observable: no (unverified: the check covers the device kernel, not the atom)
// ran_on_host: inside the target region of interest
// evidence: unverified
// needs: none
// std: c11
// unverified (oracle_not_written): re-categorised (was implementation_defined): memory from the allocator 'will be byte aligned to at least the value specified for the alignment trait' (5.2 §6.2 p.173, 6.0 §8.2 p.306), so a check that t's address is a multiple of 64 is a deterministic oracle of the original; it is not written. A mutant without the trait could still be 64-byte aligned (any alignment conforms then), AFAR rejects uses_allocators and CCE 19's mutant without the trait is an internal compiler error (final-review re-audit)
#include <stdio.h>
#include <stdbool.h>
#include <omp.h>

enum { n = 64 };

int main(void) {
  int a[n];
  int b[n];
  int ref[n];
  int host_flag;
  bool ok;
  int t;
  omp_allocator_handle_t my_alloc;
  const const omp_alloctrait_t my_traits[1] = {{omp_atk_alignment, 64}};
  for (int i = 1; i <= n; i++) {
    a[i - 1] = i;
    b[i - 1] = 0;
    ref[i - 1] = 2 * i + 1;
  }
  host_flag = 1;
  #pragma omp target map(to: a) map(from: b) map(tofrom: host_flag) \
      uses_allocators(traits(my_traits): my_alloc)
  {
    host_flag = (omp_is_initial_device() ? 1 : 0);
    #pragma omp parallel for default(none) shared(a, b, my_alloc) private(t) \
        allocate(my_alloc: t)
    for (int i = 1; i <= n; i++) {
      t = 2 * a[i - 1];
      b[i - 1] = t + 1;
    }
  }
  bool t1_ = true;
  for (int k2_ = 0; k2_ < n; k2_++)
    t1_ = t1_ && (b[k2_] == ref[k2_]);
  ok = t1_;
  printf("RESULT ran_on_host=%d check=%s\n", host_flag, ok ? "pass" : "fail");
  return 0;
}