<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hmm, do we have a backtrace from a debug+assertions build? Like,
what are we specifically crashing at? It kinda makes sense that we
should have the variable in the vals list, because we went through
its respective DeclStmt, right? So i dunno where we are crashing.<br>
<br>
I also dumped the AST for the pseudo-code that you provided and i
noticed more inconsistencies with your AST:<br>
<br>
- Integral cast from int to unsigned is missing within operator ==.<br>
- The lvalue-to-rvalue around operator & in the __spec_begin
call is unnecessary because operator & already returns an
rvalue.<br>
- On the other hand, DeclRefExprs for both __setjmp_buf and
__setjmp_ret must be lvalues.<br>
<br>
It's also a bit weird that there's no control flow in your CFG. I
would have expected that a new block is going to start after
operator ==, but i guess if the user code is unmodified anyway,
there probably isn't much control flow anyway. But then what's the
point of comparing? I'm confused.<br>
<br>
> One thing I have noticed from the CFG is that all my calls were
tagged "template".<br>
<br>
CFG just calls Stmt::printPretty() in this case. A quick look at
Stmt pretty-printing suggests that you have created the DeclRefExpr
for the function with a non-empty template keyword source location,
i.e. this AST pretends to be constructed from code<br>
<br>
unsigned int __spec_mode = template __spec_begin(...);<br>
<br>
Also your variables have type 'auto'. And, as far as i understand,
we're dealing with C code.<br>
<br>
So just to be sure - are you sure you want to auto-generate AST? Did
you consider implementing your feature as a macro instead, probably
with the help of a custom compiler builtin for __spec_begin() if it
does something that a normal function cannot do? I.e., implement all
special features in the builtin, and instead of auto-generating the
surrounding AST, just add a macro into the header that expands to
whatever you want? It's not as omnipotent, but it's much easier.
Like, i mean, this AST compiles, but all clang tools are screwed
unless the AST makes perfect sense; this compiler warning is just
the first slightly-advanced tool you encountered.<br>
<br>
<div class="moz-cite-prefix">On 9/25/18 3:27 PM, João Paulo
Labegalini de Carvalho wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGjvy2959jsariJm6oMMjOj=8r4GAXC2usJi9mLWGqc3SvohdQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Yes, I understand and really appreciate your
help, Artem.<br>
<br>
Last night I had the same insight, but splitting the
VerDecls to different DeclStmts had no effect.<br>
<br>
Bellow is the dump of the source-level CFG for the block in
question. One thing I have noticed from the CFG is that all
my calls were tagged "template". Any idea why? </div>
<div dir="ltr">Maybe that has something to do with why
UninitializedVariables Analysis is sigseg-faulting.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">
<div dir="ltr">[B181]</div>
<div dir="ltr"> 1: jmp_buf __setjmp_buf;</div>
<div dir="ltr"> 2: <b>template</b> setjmp</div>
<div dir="ltr"> 3: [B181.2] (ImplicitCastExpr,
FunctionToPointerDecay, int (*)(struct __jmp_buf_tag *)) </div>
<div dir="ltr"> 4: __setjmp_buf</div>
<div dir="ltr"> 5: [B181.4] (ImplicitCastExpr,
ArrayToPointerDecay, struct __jmp_buf_tag *)</div>
<div dir="ltr"> 6: [B181.3]([B181.5])</div>
<div dir="ltr"> 7: int __setjmp_ret = <b>template</b>
setjmp(__setjmp_buf);</div>
<div dir="ltr"> 8: <b>template</b> __spec_begin</div>
<div dir="ltr"> 9: [B181.8] (ImplicitCastExpr,
FunctionToPointerDecay, unsigned int (*)(jmp_buf *, int))</div>
<div dir="ltr"> 10: __setjmp_buf</div>
<div dir="ltr"> 11: &[B181.10]</div>
<div dir="ltr"> 12: __setjmp_ret</div>
<div dir="ltr"> 13: [B181.12] (ImplicitCastExpr,
LValueToRValue, int)</div>
<div dir="ltr"> 14: [B181.9]([B181.11], [B181.13])</div>
<div dir="ltr"> 15: unsigned int __spec_mode = <b>template</b>
__spec_begin(&__setjmp_buf, __setjmp_ret);</div>
<div dir="ltr"> 16: __spec_mode</div>
<div dir="ltr"> 17: [B181.16] (ImplicitCastExpr,
LValueToRValue, unsigned int)</div>
<div dir="ltr"> 18: [B181.17] == 1</div>
<div dir="ltr"> 19: <b>template</b> __begin_spec_slow_path</div>
<div dir="ltr"> 20: [B181.19] (ImplicitCastExpr,
FunctionToPointerDecay, void (*)(void))</div>
<div dir="ltr"> 21: [B181.20]()</div>
<div dir="ltr"> 22: global_maxNumVertices</div>
<div dir="ltr"> 23: [B181.22] (ImplicitCastExpr,
LValueToRValue, ULONGINT_T)</div>
<div dir="ltr"> 24: (long)[B181.23] (CStyleCastExpr,
IntegralCast, long)</div>
<div dir="ltr"> 25: long __tmp_maxNumVertices =
(long)global_maxNumVertices;</div>
<div dir="ltr"> 26: __tmp_maxNumVertices</div>
<div dir="ltr"> 27: typeof (tmp_maxNumVertices) ___a =
(__tmp_maxNumVertices);</div>
<div dir="ltr"> 28: maxNumVertices</div>
<div dir="ltr"> 29: [B181.28] (ImplicitCastExpr,
LValueToRValue, ULONGINT_T)</div>
<div dir="ltr"> 30: 1 (ImplicitCastExpr, IntegralCast,
unsigned long)</div>
<div dir="ltr"> 31: [B181.29] + [B181.30]</div>
<div dir="ltr"> 32: typeof (maxNumVertices + 1) ___b =
(maxNumVertices + 1); </div>
<div dir="ltr"> 33: ___a</div>
<div dir="ltr"> 34: [B181.33] (ImplicitCastExpr,
LValueToRValue, typeof (tmp_maxNumVertices))</div>
<div dir="ltr"> 35: [B181.34] (ImplicitCastExpr,
IntegralCast, unsigned long)</div>
<div dir="ltr"> 36: ___b</div>
<div dir="ltr"> 37: [B181.36] (ImplicitCastExpr,
LValueToRValue, typeof (maxNumVertices + 1)) </div>
<div dir="ltr"> 38: [B181.35] > [B181.37]</div>
<div dir="ltr"> T: ([B181.38]) ? ... : ... </div>
<div dir="ltr"> Preds (1): B185</div>
<div dir="ltr"> Succs (2): B179 B180</div>
<div><br>
</div>
<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Sep 25, 2018 at 2:47 PM Artem Dergachev
<<a href="mailto:noqnoqneo@gmail.com" target="_blank"
moz-do-not-send="true">noqnoqneo@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Remote debugging is
hard, but here's something i notice: i don't think you can
declare multiple variables of different types in the same
DeclStmt. Eg., you can do `int x = 1, *y = 0;`, but you
can't do `int x = 1, unsigned y = 0;`. Could you try to
produce a separate DeclStmt for every VarDecl and see if it
helps?<br>
<br>
If it doesn't, can i also have a look at the CFG? Just do
CFG.dump().<br>
<br>
<div
class="m_-307315359463317007m_-7535279087831355520moz-cite-prefix">On
9/24/18 3:26 PM, João Paulo Labegalini de Carvalho wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Artem,
<div><br>
</div>
<div>First of all, thank you for your reply.<br>
<br>
Indeed, I am auto-generating AST made of regular
nodes. More specifically, my SpecStmt node has four
sub-nodes. A DeclStmt that I use to hang the variables
a need, a Expr to compare __spec_mode and decide which
path to take (SlowPath or FastPath) and two
CompoundStmts. So SpecStmt looks like an IfStmt with
both then and else statements.<br>
<br>
Bellow is the part of the AST which triggers the
sigsegv (Please find the AST for the whole
FunctionDecl attached):</div>
<div><br>
</div>
<div>
<div>| | |-<b>SpecStmt</b> 0x15c1ca8
<./spec.h:127:32></div>
<div>| | | |-DeclStmt 0x15c09e8 <col:32></div>
<div>| | | | |-VarDecl 0x15c0368
<col:32> col:32 <b>__setjmp_buf</b> 'jmp_buf':'struct
__jmp_buf_tag [1]' auto</div>
<div>| | | | |-VarDecl 0x15c03c8
<col:32> col:32 <b>__setjmp_ret</b> 'int' auto
cinit</div>
<div>| | | | | `-CallExpr 0x15c0630
<col:32> 'int'</div>
<div>| | | | | |-ImplicitCastExpr 0x15c0618
<col:32> 'int (*)(jmp_buf *)'
<FunctionToPointerDecay></div>
<div>| | | | | | `-DeclRefExpr 0x15c05e0
<col:32> 'int (jmp_buf *)' Function 0x15c04d8
'<b>setjmp</b>' 'int (jmp_buf *)'</div>
<div>| | | | | `-ImplicitCastExpr 0x15c0450
<col:32> 'jmp_buf *'
<ArrayToPointerDecay></div>
<div>| | | | | `-DeclRefExpr 0x15c0428
<col:32> 'jmp_buf':'struct __jmp_buf_tag [1]'
Var 0x15c0368 '<b>__setjmp_buf</b>'
'jmp_buf':'struct __jmp_buf_tag [1]'</div>
<div>| | | | `-VarDecl 0x15c0660
<col:32> col:32 <b>__spec_mode</b> 'unsigned
int' auto cinit</div>
<div>| | | | `-CallExpr 0x15c0990
<col:32> 'unsigned int'</div>
<div>| | | | |-ImplicitCastExpr 0x15c0978
<col:32> 'unsigned int (*)(jmp_buf *, int)'
<FunctionToPointerDecay></div>
<div>| | | | | `-DeclRefExpr 0x15c0940
<col:32> 'unsigned int (jmp_buf *, int)'
Function 0x15c07d0 '<b>__spec_begin</b>' 'unsigned
int (jmp_buf *, int)'</div>
<div>| | | | |-ImplicitCastExpr 0x15c0730
<col:32> 'jmp_buf *' <LValueToRValue></div>
<div>| | | | | `-UnaryOperator 0x15c06e8
<col:32> 'jmp_buf *' prefix '&'</div>
<div>| | | | | `-DeclRefExpr 0x15c06c0
<col:32> 'jmp_buf':'struct __jmp_buf_tag [1]'
Var 0x15c0368 '<b>__setjmp_buf'</b> 'jmp_buf':'struct
__jmp_buf_tag [1]'</div>
<div>| | | | `-ImplicitCastExpr 0x15c0748
<col:32> 'int' <LValueToRValue> </div>
<div>| | | | `-DeclRefExpr 0x15c0708
<col:32> 'int' Var 0x15c03c8 '<b>__setjmp_ret</b>'
'int'</div>
<div>| | | |-BinaryOperator 0x15c0a60
<col:32> 'bool' lvalue '=='</div>
<div>| | | | |-ImplicitCastExpr 0x15c0a28
<col:32> 'unsigned int' <LValueToRValue></div>
<div>| | | | | `-DeclRefExpr 0x15c0a00
<col:32> 'unsigned int' lvalue Var 0x15c0660 '<b>__spec_mode'</b> 'unsigned
int'</div>
<div>| | | | `-IntegerLiteral 0x15c0a40
<col:32> 'int' 1</div>
<div>| | | |-CompoundStmt 0x15c1c38
<col:32></div>
</div>
<div><br>
</div>
<div dir="ltr"><br>
</div>
<div>Thanks in advance for any help!<br>
<br>
</div>
<div>Respectfully,</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Mon, Sep 24, 2018 at 4:36 PM Artem
Dergachev <<a href="mailto:noqnoqneo@gmail.com"
target="_blank" moz-do-not-send="true">noqnoqneo@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Is the
DeclRefExpr for __spec_mode pointing to a valid
VarDecl? Would this VarDecl be encountered
previously during analysis in order to populate
TransferFunctions::vals()? Dunno if that makes
sense, i didn't really look at this analysis.<br>
<br>
I guess i want to look at your full -ast-dump. It
seems that you are not only adding a new Stmt kind,
but also you're getting into business of
auto-generating AST made of some regular nodes,
probably as its children. This is often hard because
it's very easy to break invariants that the normal
AST obeys and there's no way to verify those
invariants other than seeing how everything crashes
and debugging.<br>
<br>
<div
class="m_-307315359463317007m_-7535279087831355520m_-6700653932672170602moz-cite-prefix">On
9/24/18 4:43 AM, João Paulo Labegalini de Carvalho
via cfe-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">You are right, I should have been
more specific. In my case crashing means
segmentation fault inside runOnBlock function
(lib/Analysis/UninitializedValues.cpp).<br>
<br>
Please find the stack trace attached.</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Mon, Sep 24, 2018 at 4:09 AM
Csaba Raduly <<a
href="mailto:rcsaba@gmail.com"
target="_blank" moz-do-not-send="true">rcsaba@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">Hi João Paulo,<br>
<br>
<br>
On Sun, Sep 23, 2018 at 11:39 PM, João Paulo
Labegalini de Carvalho<br>
via cfe-dev <<a
href="mailto:cfe-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>>
wrote:<br>
> Hi,<br>
><br>
> I have implemented a new Stmt in clang
which given<br>
><br>
> __speculate {<br>
> // user code<br>
> }<br>
><br>
> generates LLVM IR equivalent to as if
the following code was given:<br>
><br>
...<br>
><br>
> However, if
UninitializedVariablesAnalysis is enabled,
clang crashes at<br>
> runOnBlock function
(lib/Analysis/UninitializedValues.cpp). If I
disable it<br>
> via -Wno-uninitialized, the code
generated runs flawlessly and works as<br>
> expected.<br>
<br>
"crash" is a meaningless term. Does it
generate an access violation,<br>
an assertion failure, or something else?<br>
What was the error message? Is there a stack
trace?<br>
<br>
<br>
Csaba<br>
<br>
-- <br>
You can get very substantial performance
improvements<br>
by not doing the right thing. - Scott
Meyers, An Effective C++11/14 Sampler<br>
So if you're looking for a completely
portable, 100% standards-conformat way<br>
to get the wrong information: this is what
you want. - Scott Meyers (C++TDaWYK)<br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr"
class="m_-307315359463317007m_-7535279087831355520m_-6700653932672170602gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>João Paulo L. de Carvalho<br>
Computer Science | IC-UNICAMP |
Campinas , SP - Brazil</div>
<div><a
href="mailto:jaopaulolc@gmail.com"
target="_blank"
moz-do-not-send="true">jaopaulolc@gmail.com</a></div>
<div><a
href="mailto:joao.carvalho@ic.unicamp.br"
target="_blank"
moz-do-not-send="true">joao.carvalho@ic.unicamp.br</a><br>
<a
href="mailto:j160924@dac.unicamp.br"
target="_blank"
moz-do-not-send="true">j160924@dac.unicamp.br</a></div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset
class="m_-307315359463317007m_-7535279087831355520m_-6700653932672170602mimeAttachmentHeader"></fieldset>
<pre class="m_-307315359463317007m_-7535279087831355520m_-6700653932672170602moz-quote-pre">_______________________________________________
cfe-dev mailing list
<a class="m_-307315359463317007m_-7535279087831355520m_-6700653932672170602moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>
<a class="m_-307315359463317007m_-7535279087831355520m_-6700653932672170602moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr"
class="m_-307315359463317007m_-7535279087831355520gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>João Paulo L. de Carvalho<br>
Computer Science | IC-UNICAMP | Campinas , SP -
Brazil</div>
<div><a href="mailto:jaopaulolc@gmail.com"
target="_blank" moz-do-not-send="true">jaopaulolc@gmail.com</a></div>
<div><a href="mailto:joao.carvalho@ic.unicamp.br"
target="_blank" moz-do-not-send="true">joao.carvalho@ic.unicamp.br</a><br>
<a href="mailto:j160924@dac.unicamp.br"
target="_blank" moz-do-not-send="true">j160924@dac.unicamp.br</a></div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="m_-307315359463317007gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>João Paulo L. de Carvalho<br>
Computer Science | IC-UNICAMP | Campinas , SP - Brazil</div>
<div><a href="mailto:jaopaulolc@gmail.com" target="_blank"
moz-do-not-send="true">jaopaulolc@gmail.com</a></div>
<div><a href="mailto:joao.carvalho@ic.unicamp.br"
target="_blank" moz-do-not-send="true">joao.carvalho@ic.unicamp.br</a><br>
<a href="mailto:j160924@dac.unicamp.br" target="_blank"
moz-do-not-send="true">j160924@dac.unicamp.br</a></div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>