AlexVlx wrote: > > Running into an observable situation where this is a concern means that > > either you've messed around with (non C/C++) attributes, or are linking in > > something exciting. Neither of which constitutes valid C/C++, and I'm > > leaning towards saying shouldn't be allowed to silently work - we probably > > should refrain from infecting C/C++ with explicit address spaces a la > > OpenCL. What are you actually running into @jhuber6 where this is a > > concern? More specifically, you are saying "we want to do X, in C++" -> why? > > I'm trying to port the OpenMP device runtime to just use C/C++, we use a lot > of `__local` variables there which this turns into a mess of C-style casts. > It also interacts badly with the `this` pointer if you put a class inside of > anything with an address space. C/C++ says nothing about address spaces, but > these basically act as target specific attributes on certain types. > > This is a case where it's actually harder to do something in C/C++ than > OpenCL and I don't want it to be that way. See > https://godbolt.org/z/1Gn71qqPT for an example of what I'm talking about. > > TL;DR, every other language allows this and I want to be able to use classes > or LDS variables without spamming `(int &)` everywhere.
Well it's harder to do OpenCL in C++ than doing OpenCL in OpenCL is not entirely surprising, is it? I understand you do not want to do it that way, however this allows for what is essentially non-standard C++ to sneakily start "working" as if it were standard C++. Every other language in this case == every other GPU offload language modelled after CUDA/OpenCL, but I don't know if that should mean we can simply drop something in an otherwise standard C++ compilation. This is important because these are typefully significant target specific attributes, with consequential semantics in the AST (for example they contribute to overload resolution). It's also plausibly important for quirky cases such as bit-patterns `nullptr` / `NULL` for different address spaces - as I said, not all AS-casts to generic have to be NOPs. So overall I'm leaning against doing it as is; guarding it under some flavour of `allow-relaxed-address-space-handling` or something that sounds better but is still noisy enough to make it clear there's danger seems preferable, at least to me. https://github.com/llvm/llvm-project/pull/112248 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
