[cfe-dev] [RFC] Delayed target-specific diagnostic when compiling for the devices.

[Alexey Bataev via cfe-dev]

Yes, I thought about this. But we need to delay the diagnostic until the
Codegen phase. What I need is the way to associate the diagnostic with
the function so that this diagnostic is available in CodeGen.

Also, we need to postpone the diagnotics not only for functions, but,for
example, for some types. For example, __float128 type is not supported
by CUDA. We can get error messages when we ran into something like
`typedef __float128 SomeOtherType` (say, in some system header files)
and get the error diagnostic when we compile for the device. Though,
actually, this type is not used in the device code, the diagnostic is
still emitted and we need to delay too and emit it only iff the type is
used in the device code.

-------------
Best regards,
Alexey Bataev

15.01.2019 17:33, John McCall пишет:
> On 15 Jan 2019, at 17:20, Alexey Bataev wrote:
>> This is not only for asm, we need to delay all target-specific
>> diagnostics.
>> I'm not saying that we need to move the host diagnostic, only the
>> diagnostic for the device compilation.
>> As for Cuda, it is a little but different. In Cuda the programmer
>> must explicitly mark the device functions,  while in OpenMP it must
>> be done implicitly. Thus, we cannot reuse the solution used for Cuda.
>
> All it means is that you can't just use the solution used for CUDA
> "off the shelf".  The basic idea of associating diagnostics with the
> current function and then emitting those diagnostics later when you
> realize that you have to emit that function is still completely
> applicable.
>
> John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190116/425bdde3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190116/425bdde3/attachment.sig>