<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Eli,<br>
<br>
I usually appreciate your comment. <br>
<br>
>Shouldn't the UsualArithmeticConversions call come after the
checkConditionalConvertScalarsToVectors check? Not completely sure
here (the rules aren't really clear, and clang's implementation of
the check in question isn't consistent with any interpretation of
the OpenCL standard).<br>
<br>
I also agree your opinion but it causes assertion "assert(0
&& "can't implicitly cast lvalue to rvalue with this cast
kind");" with following OpenCL example.<br>
<br>
Source Code: test.cl<br>
typedef char char16 __attribute__((ext_vector_type(16)));<br>
<br>
__kernel void test(void) {<br>
char valA;<br>
char valB;<br>
char16 valC;<br>
char16 destVal = valC ? valA : valB;<br>
}<br>
<br>
This assertion comes from "ImpCastExprToType()" function in
"checkConditionalConvertScalarsToVectors()" function because LHS and
RHS are LValue at that moment without
"UsualArithmeticConversions()". In order to move
"UsualArithmeticConversions()" after
"checkConditionalConvertScalarsToVectors ()",
"checkConditionalConvertScalarsToVectors ()" needs
"DefaultLvalueConversion()" to make 'LValueToRValue'
ImplicitCastExpr with LHS and RHS. I think that
"DefaultLvalueConversion()" is redundant because
"UsualArithmeticConversions()" also executes
"DefaultLvalueConversion()". How do you feel about this?<br>
<br>
>If you're going to go the route of updating CondTy, LHSTy, and
RHSTy whenever the expressions change, please make sure they stay
consistently up-to-date throughout the function.<br>
<br>
I am so sorry that I can not understand your comment completely due
to my idiot brain. I simply modified patch to use "getType()"
function. If there are something wrong, please guide me to correct
direction. :)<br>
<br>
Thanks for your good comment again,<br>
JinGu Kang<br>
<br>
<div><br>
</div>
<div class="moz-cite-prefix">On 29/08/2013 22:37, Eli Friedman
wrote:<br>
</div>
<blockquote
cite="mid:CAJdarcHdj_rB_rmWVupt=WoSqLbw2YvuHDgnSvr8m_uGWtMsJg@mail.gmail.com"
type="cite">
<div dir="ltr">On Thu, Aug 29, 2013 at 10:13 AM, JinGu Kang <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:jingu@codeplay.com" target="_blank">jingu@codeplay.com</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi
all,<br>
<br>
My colleague 'Alistair' tested a simple code and found a
error. The simplified code and error message are as
following:<br>
<br>
Source code:<br>
typedef char char16 __attribute__((ext_vector_type(16)));<br>
<br>
int main(void) {<br>
char16 valA;<br>
char valB;<br>
char valC;<br>
char16 destVal = valC ? valA : valB;<br>
}<br>
<br>
Error message:<br>
error: can't convert between vector values of different
size ('char16' and 'int')<br>
char16 destVal = valC ? valA : valB;<br>
^ ~~~~ ~~~~<br>
<br>
This error message comes from "CheckVectorOperands()"
function in "CheckConditionalOperands()" function because
"UsualArithmeticConversions(LHS, RHS)" function is
executed before "CheckVectorOperands()" function and
"UsualArithmeticConversions(LHS, RHS)" function changes
RHS as follows:<br>
GDB output of original RHS:<br>
DeclRefExpr 0xc4b3050 'char' lvalue Var 0xc4b2f50 'valB'
'char'<br>
<br>
GDB output of changed RHS:<br>
ImplicitCastExpr 0xc4b30a8 'int' <IntegralCast><br>
`-ImplicitCastExpr 0xc4b3098 'char' <LValueToRValue><br>
`-DeclRefExpr 0xc4b3050 'char' lvalue Var 0xc4b2f50
'valB' 'char'<br>
<br>
So, the error message is generated between 'char16' and
'int'. I am wondering whether this error is correct or
not. I have checked other checking functions executes
"CheckVectorOperands()" function before
"UsualArithmeticConversions(LHS, RHS)" function such as
"CheckSubtractionOperands()", "CheckAdditionOperands()"
functions and etc... Could someone let me know about this
error? I have attached a simple patch to fix it on the
assumption that it is not correct.<br>
<br>
</blockquote>
<div><br>
</div>
<div>The patch is in the right direction; the call
to UsualArithmeticConversions should come after the call
to CheckVectorOperands.</div>
<div><br>
</div>
<div>Shouldn't the UsualArithmeticConversions call come
after the checkConditionalConvertScalarsToVectors check?
Not completely sure here (the rules aren't really clear,
and clang's implementation of the check in question isn't
consistent with any interpretation of the OpenCL
standard).</div>
<div><br>
</div>
<div>If you're going to go the route of updating CondTy,
LHSTy, and RHSTy whenever the expressions change, please
make sure they stay consistently up-to-date throughout the
function.</div>
<div><br>
</div>
<div>-Eli</div>
</div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
JinGu Kang
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: <a class="moz-txt-link-freetext" href="http://www.codeplay.com">http://www.codeplay.com</a>
Twitter: <a class="moz-txt-link-freetext" href="https://twitter.com/codeplaysoft">https://twitter.com/codeplaysoft</a>
This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY </pre>
</body>
</html>