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