Hi! On Mon, 11 Jan 2016 12:46:17 +0300 (MSK), Alexander Monakov <amona...@ispras.ru> wrote: > On Fri, 8 Jan 2016, Jakub Jelinek wrote: > > And CU_JIT_TARGET / CU_TARGET_COMPUTE_30 requests JITting only on sm_30 and > > nothing else, or just on sm_30 or later, something else? > > It requests to produce binary code targeting sm_30 devices. Newer (Maxwell) > devices use a different hw instruction set, so they simply cannot execute > binary code emitted/jitted for sm_30.
ACK. > > This really should be reviewed by somebody familiar with CUDA more than > > myself. > > FWIW this is my patch -- I developed it as part of OpenMP offloading work, and > I still think that the patch is doing the right thing. ACK, as I recently suggested/requested in <http://news.gmane.org/find-root.php?message_id=%3C87h9j9gq2m.fsf%40kepler.schwinge.homeip.net%3E>. > (and I don't understand what's going on with lack of Changelog showing > attribution No offense intended I think -- I guess Jim simply forgot to include the ChangeLog update in this submission; you're certainly listed in his gomp-4_0-branch commit r232142, <http://news.gmane.org/find-root.php?message_id=%3C568ED528.6080200%40codesourcery.com%3E>. > I also hoped I'd be Cc'ed on this) Right. Alexander, would you please also submit a fix for that for nvptx-tools' nvptx-run.c? (Or want me to do that?) Going further, for both GCC's libgomp and nvptx-tools' nvptx-run, would it make sense to have a way to restrict code generation to a specific SM version for testing purposes? For example with a compiler flag that then stores this information in the executable (how?), or NVPTX_RUN_CC, and GOMP_NVPTX_CC environment variables (or, *_SM?), respectively? Grüße Thomas
signature.asc
Description: PGP signature