<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
<p>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.<br>
</p>
<pre class="moz-signature" cols="72">-------------
Best regards,
Alexey Bataev</pre>
<div class="moz-cite-prefix">15.01.2019 17:33, John McCall пишет:<br>
</div>
<blockquote type="cite"
cite="mid:4C620C7E-7AF7-4529-A06B-04E27D78CB73@apple.com">On 15
Jan 2019, at 17:20, Alexey Bataev wrote:
<br>
<blockquote type="cite">This is not only for asm, we need to delay
all target-specific diagnostics.
<br>
I'm not saying that we need to move the host diagnostic, only
the diagnostic for the device compilation.
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
<br>
John.
<br>
</blockquote>
</body>
</html>