<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
0aj yt <br>
<br>
<div style="font-size:100%;text-align:left;color:#000000">
<div>d-------- Ursprüngliche Nachricht --------</div>
<div>Von: via cfe-dev <cfe-dev@lists.llvm.org></cfe-dev@lists.llvm.org></div>
<div>Datum:05.01.2017 07:51 (GMT+01:00) </div>
<div>An: cfe-dev@lists.llvm.org </div>
<div>Betreff: cfe-dev Digest, Vol 115, Issue 18 </div>
<div><br>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Send cfe-dev mailing list submissions to<br>
cfe-dev@lists.llvm.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_BLANK">
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
cfe-dev-request@lists.llvm.org<br>
<br>
You can reach the person managing the list at<br>
cfe-dev-owner@lists.llvm.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cfe-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Is there a nicer way to error than "llvm_unreachable" at<br>
CodeGen ? (Nat! via cfe-dev)<br>
2. Re: Is there a nicer way to error than "llvm_unreachable" at<br>
CodeGen ? (Mehdi Amini via cfe-dev)<br>
3. Statically linking libc++/libc++abi (ELF)<br>
(Matt Glazar via cfe-dev)<br>
4. Re: Statically linking libc++/libc++abi (ELF)<br>
(James Y Knight via cfe-dev)<br>
5. Re: DeclarationName and the StringRef. (Umesh Kalappa via cfe-dev)<br>
6. Re: clang 3.8, libtooling cannot visit some BinaryOperator<br>
(詹石岩 via cfe-dev)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 04 Jan 2017 21:43:57 +0100<br>
From: Nat! via cfe-dev <cfe-dev@lists.llvm.org><br>
To: "cfe-dev@lists.llvm.org" <cfe-dev@lists.llvm.org><br>
Subject: [cfe-dev] Is there a nicer way to error than<br>
"llvm_unreachable" at CodeGen ?<br>
Message-ID: <586D5E8D.3000704@mulle-kybernetik.com><br>
Content-Type: text/plain; charset=ISO-8859-15<br>
<br>
I would like to error and abandon compilation during code generation<br>
(after syntax/semantics is through), but not crash.<br>
<br>
Ciao<br>
Nat!<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 04 Jan 2017 14:06:06 -0800<br>
From: Mehdi Amini via cfe-dev <cfe-dev@lists.llvm.org><br>
To: Nat! <nat@mulle-kybernetik.com><br>
Cc: "cfe-dev@lists.llvm.org" <cfe-dev@lists.llvm.org><br>
Subject: Re: [cfe-dev] Is there a nicer way to error than<br>
"llvm_unreachable" at CodeGen ?<br>
Message-ID: <38E05DC4-1BD2-43CF-8587-5AF925D51C49@apple.com><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Caution: `llvm_unreachable` is absolutely *not* intended to report error. It is only asserting when assertions are enabled, and compiled out to “nothing” in release build.<br>
<br>
We have report_fatal_error(“…”) for ICE (internal compiler error) when we want a behavior that is “assertions in release mode”, but that’s also not intended to happen (IMO): ideally it should *not* be possible to trigger it with valid IR (yeah we’re not doing
a good job at it…).<br>
<br>
So yes, you can diagnose an error properly, using the LLVMContext. For example open llvm/lib/Target/AMDGPU/SIISelLowering.cpp and search for: DAG.getContext()->diagnose(NoGraphicsHSA);<br>
<br>
— <br>
Mehdi<br>
<br>
<br>
> On Jan 4, 2017, at 12:43 PM, Nat! via cfe-dev <cfe-dev@lists.llvm.org> wrote:<br>
> <br>
> I would like to error and abandon compilation during code generation<br>
> (after syntax/semantics is through), but not crash.<br>
> <br>
> Ciao<br>
> Nat!<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> cfe-dev@lists.llvm.org<br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_BLANK">
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 4 Jan 2017 21:21:30 +0000<br>
From: Matt Glazar via cfe-dev <cfe-dev@lists.llvm.org><br>
To: "cfe-dev@lists.llvm.org" <cfe-dev@lists.llvm.org><br>
Cc: Saleem Abdulrasool <abdulras@fb.com><br>
Subject: [cfe-dev] Statically linking libc++/libc++abi (ELF)<br>
Message-ID: <D4928FFA.20CA2%strager@fb.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I want to statically link libc++ and libc++abi into my ELF DSO (shared<br>
library). (Statically linking avoids incompatibilities with other<br>
libc++/libstdc++/etc. loaded at runtime by other DSO-s.) (My DSO exports<br>
no C++ APIs, imports no C++ APIs, does not throw or catch exceptions<br>
across DSO boundaries, does not require callers to delete returned<br>
pointers, etc.)<br>
<br>
To achieve this, I am using -fvisibility=hidden,<br>
-D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS, and<br>
-D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS (and some other tweaks) when<br>
compiling libc++, libc++abi, and my own code. I build libc++ and libc++abi<br>
as static libraries and link them into my DSO.<br>
<br>
This seems to work well. However, Clang forces some libc++abi symbols to<br>
default visibility. This puts these symbols in my DSO's dynamic export<br>
table. Thus:<br>
<br>
* Linking against my DSO may inadvertently use my DSO's symbols instead of<br>
the symbols you expect (e.g. the system libstdc++'s symbols).<br>
* It also means my DSO's references to its libc++abi symbols may be<br>
replaced at runtime with another DSO's symbols (e.g. the system<br>
libstdc++'s symbols).<br>
<br>
From what I have found so far, default visibility for libc++abi symbols is<br>
forced in two places in Clang:<br>
<br>
* lib/Sema/SemaExprCXX.cpp Sema::DeclareGlobalAllocationFunction<br>
* lib/CodeGen/ItaniumCXXABI.cpp ItaniumRTTIBuilder::BuildTypeInfo<br>
<br>
Is there a reason these symbols *must* have default visibility? I<br>
understand that, in general, typeinfo should have default visibility for<br>
exception handling to function properly. Does an opt-in option to change<br>
the visibility of these symbols (for use cases like mine) sound reasonable?<br>
<br>
Thanks,<br>
<br>
Matthew Glazar<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 4 Jan 2017 18:19:10 -0500<br>
From: James Y Knight via cfe-dev <cfe-dev@lists.llvm.org><br>
To: Matt Glazar <strager@fb.com><br>
Cc: Saleem Abdulrasool <abdulras@fb.com>, "cfe-dev@lists.llvm.org"<br>
<cfe-dev@lists.llvm.org><br>
Subject: Re: [cfe-dev] Statically linking libc++/libc++abi (ELF)<br>
Message-ID:<br>
<CAA2zVHo7uRpMEFEg1h9uDN2ryL+ChLQiiAPydPhsEDX-NFraJg@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Typically the way people do this is by passing a --version-script to the<br>
linker, which lets you include/exclude symbols as you wish regardless of<br>
the visibility attributes.<br>
<br>
Even more so when building against libstdc++ headers, which forces nearly<br>
everything to have default visibility, no matter what.<br>
<br>
On Wed, Jan 4, 2017 at 4:21 PM, Matt Glazar via cfe-dev <<br>
cfe-dev@lists.llvm.org> wrote:<br>
<br>
> I want to statically link libc++ and libc++abi into my ELF DSO (shared<br>
> library). (Statically linking avoids incompatibilities with other<br>
> libc++/libstdc++/etc. loaded at runtime by other DSO-s.) (My DSO exports<br>
> no C++ APIs, imports no C++ APIs, does not throw or catch exceptions<br>
> across DSO boundaries, does not require callers to delete returned<br>
> pointers, etc.)<br>
><br>
> To achieve this, I am using -fvisibility=hidden,<br>
> -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS, and<br>
> -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS (and some other tweaks) when<br>
> compiling libc++, libc++abi, and my own code. I build libc++ and libc++abi<br>
> as static libraries and link them into my DSO.<br>
><br>
> This seems to work well. However, Clang forces some libc++abi symbols to<br>
> default visibility. This puts these symbols in my DSO's dynamic export<br>
> table. Thus:<br>
><br>
> * Linking against my DSO may inadvertently use my DSO's symbols instead of<br>
> the symbols you expect (e.g. the system libstdc++'s symbols).<br>
> * It also means my DSO's references to its libc++abi symbols may be<br>
> replaced at runtime with another DSO's symbols (e.g. the system<br>
> libstdc++'s symbols).<br>
><br>
> From what I have found so far, default visibility for libc++abi symbols is<br>
> forced in two places in Clang:<br>
><br>
> * lib/Sema/SemaExprCXX.cpp Sema::DeclareGlobalAllocationFunction<br>
> * lib/CodeGen/ItaniumCXXABI.cpp ItaniumRTTIBuilder::BuildTypeInfo<br>
><br>
> Is there a reason these symbols *must* have default visibility? I<br>
> understand that, in general, typeinfo should have default visibility for<br>
> exception handling to function properly. Does an opt-in option to change<br>
> the visibility of these symbols (for use cases like mine) sound reasonable?<br>
><br>
> Thanks,<br>
><br>
> Matthew Glazar<br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> cfe-dev@lists.llvm.org<br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_BLANK">
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20170104/fd03f243/attachment-0001.html" target="_BLANK">http://lists.llvm.org/pipermail/cfe-dev/attachments/20170104/fd03f243/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 5 Jan 2017 09:29:51 +0530<br>
From: Umesh Kalappa via cfe-dev <cfe-dev@lists.llvm.org><br>
To: cfe-dev@lists.llvm.org<br>
Subject: Re: [cfe-dev] DeclarationName and the StringRef.<br>
Message-ID:<br>
<CAGfacvRK71s6=+GVOrjbxDDunXTLP7zC67CxQ_jUa6A6P_77Ag@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thank you Eli for the your suggestion and we are trying at clang AST level<br>
,since we are supporting through pragma directive.<br>
<br>
Umesh<br>
<br>
On Dec 21, 2016 4:34 PM, "Umesh Kalappa" <umesh.kalappa0@gmail.com> wrote:<br>
<br>
Hi Guys ,<br>
<br>
We have the function that accepts StringRef and construct<br>
the DeclarationName instance .<br>
<br>
Currenlty we are achieving the same as ,the code snap<br>
<br>
void appendExtern(StringRef Sr)<br>
{<br>
char *ExternChar = const_cast<char *> (Sr.data());<br>
*Ptr =reinterpret_cast<void *>(ExternChar);<br>
<br>
this->ExternName = DeclarationName::getFromOpaquePtr(Ptr);<br>
<br>
}<br>
<br>
There is, any better way of achieving this ,because the above code is<br>
crashing intermittently ?<br>
<br>
Thank you and any help here appreciated.<br>
~Umesh<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20170105/49955573/attachment-0001.html" target="_BLANK">http://lists.llvm.org/pipermail/cfe-dev/attachments/20170105/49955573/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Thu, 5 Jan 2017 14:51:12 +0800<br>
From: 詹石岩 via cfe-dev <cfe-dev@lists.llvm.org><br>
To: "=?utf-8?B?Y2ZlLWRldg==?=" <cfe-dev@lists.llvm.org><br>
Subject: Re: [cfe-dev] clang 3.8, libtooling cannot visit some<br>
BinaryOperator<br>
Message-ID: <tencent_38850A3A2EDF3FDD3DB4725E@qq.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I added code just at the beginning of VisitBinaryOperator like:<br>
bool VisitBinaryOperator(BinaryOperator *b){<br>
PrintingPolicy policy = PrintingPolicy(this->TheRewriter.getLangOpts());<br>
b->printPretty(llvm::errs(), NULL, policy);<br>
llvm::errs()<<'\n';<br>
if(b->isAssignmentOp()){<br>
handler.HandleBinaryOperator(b);<br>
}<br>
return true;<br>
}The test code includes these lines:void setForceMethod(NbodyModel *theModel,int force_method) {<br>
theModel->force_method=force_method;<br>
}<br>
void setTreeRangeCoefficient(NbodyModel *theModel,double coefficient) {<br>
theModel->treeRangeCoefficient=coefficient;<br>
}<br>
void setIntMethod(NbodyModel *theModel,int int_method) {<br>
theModel->int_method=int_method;<br>
}expected output should include these assignments but I didn't find them in terminal.I tried `clang -Xclang -ast-dump -fsyntax-only mycode.c` and these assignments were printed out.The older version of this tool can get most of these assignments(7 out of 8)
but after I added some code, all of them are gone. Does this problem have any relation to compiler? Or the memory layout was messed up by my code?<br>
Are you SURE that the VisitBinaryOperator function is not being called? I<br>
find that highly unlikely (considering that these visitors are quite<br>
commonly used for all sorts of different purposes, and checking for<br>
assignments isn't unusual by any means).<br>
<br>
I would expect that the conditions INSIDE your function is what is causing<br>
problems. Try adding some printout (or set a breakpoint in a debugger) at<br>
the beginning of the function. I suspect the function is being called, but<br>
the operands are not the kind you think they are in this case, so your<br>
printout or "do stuff" isn't happening.<br>
<br>
--<br>
Mats<br>
<br>
<br>
------------------<br>
----<br>
祝好！詹石岩<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20170105/ceaacbf7/attachment.html" target="_BLANK">http://lists.llvm.org/pipermail/cfe-dev/attachments/20170105/ceaacbf7/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
cfe-dev@lists.llvm.org<br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_BLANK">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of cfe-dev Digest, Vol 115, Issue 18<br>
****************************************<br>
</div>
</span></font>
</body>
</html>