jhuber6 added a comment. In D152882#4422797 <https://reviews.llvm.org/D152882#4422797>, @yaxunl wrote:
> In D152882#4422788 <https://reviews.llvm.org/D152882#4422788>, @jhuber6 wrote: > >> In D152882#4421138 <https://reviews.llvm.org/D152882#4421138>, @yaxunl wrote: >> >>> However, bitcode of target ID gfx90a:xnack+ is allowed to link in bitcode >>> of target ID gfx90a as long as they are from different containers. So there >>> are two rules about target ID: 1. compatibility rules for objects/bitcode >>> in the same container 2. compatibility rules for linking bitcode of >>> different target ID's. >>> >>> we need tests for both rules. >> >> So I'm wondering why I'm allowed to do >> `--offload-arch=gfx90a,gfx90a:xnack+`. Shouldn't that be caught by >> `getConflictTargetIDCombination`? That seems like the proper place to >> diagnose this. > > clang --offload-arch=gfx90a,gfx90a:xnack+ -c a.hip > clang: error: invalid offload arch combinations: 'gfx90a' and 'gfx90a:xnack+' > (for a specific processor, a feature should either exist in all offload > archs, or not exist in any offload archs) > > At least it is caught for HIP. OpenMP may not check that. if (Kind != Action::OFK_HIP) return std::nullopt; Yes, this would be the culprit. Guessing we shouldn't do that? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152882/new/ https://reviews.llvm.org/D152882 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
