similar to: [LLVMdev] Static ctors in llvm::Attribute

I see the problem. Let me try to come up with a solution that does not involve constructors but also does not sacrifice type safety. On Tue, Feb 7, 2012 at 12:01 PM, Chris Lattner <clattner at apple.com> wrote: > Hi Kostya, > > One unexpected piece of fallout in your recent attributes change (r148553) > was that it introduced a bunch of static constructors into .o files that

On Tue, Feb 7, 2012 at 12:53 PM, Kostya Serebryany <kcc at google.com> wrote: > I see the problem. > Let me try to come up with a solution that does not involve constructors > but also does not sacrifice type safety. > > > I have a patch that uses a proxy POD type. 'make && make check' passes. It's a bit ugly in the header file

On Feb 7, 2012, at 4:04 PM, Kostya Serebryany wrote: > On Tue, Feb 7, 2012 at 3:46 PM, John McCall <rjmccall at apple.com> wrote: > On Feb 7, 2012, at 2:07 PM, Kostya Serebryany wrote: > > Slightly formatted/commented patch. > > WDYT? > > This seems to work fine, except that reading a field from a const > AttrConst is not a constant expression in C++03, so the

On Tue, Feb 7, 2012 at 4:55 PM, John McCall <rjmccall at apple.com> wrote: > On Feb 7, 2012, at 4:04 PM, Kostya Serebryany wrote: > > On Tue, Feb 7, 2012 at 3:46 PM, John McCall <rjmccall at apple.com> wrote: > >> On Feb 7, 2012, at 2:07 PM, Kostya Serebryany wrote: >> > Slightly formatted/commented patch. >> > WDYT? >> >> This seems to

On Feb 7, 2012, at 2:07 PM, Kostya Serebryany wrote: > Slightly formatted/commented patch. > WDYT? This seems to work fine, except that reading a field from a const AttrConst is not a constant expression in C++03, so the "set" declarations (ParameterOnly, FunctionOnly, VarArgsIncompatible, and MutuallyIncompatible) still require a global constructor. You can split the values

On Feb 7, 2012, at 4:56 PM, Kostya Serebryany wrote: > > > On Tue, Feb 7, 2012 at 4:55 PM, John McCall <rjmccall at apple.com> wrote: > On Feb 7, 2012, at 4:04 PM, Kostya Serebryany wrote: >> On Tue, Feb 7, 2012 at 3:46 PM, John McCall <rjmccall at apple.com> wrote: >> On Feb 7, 2012, at 2:07 PM, Kostya Serebryany wrote: >> > Slightly

On Tue, Feb 7, 2012 at 3:46 PM, John McCall <rjmccall at apple.com> wrote: > On Feb 7, 2012, at 2:07 PM, Kostya Serebryany wrote: > > Slightly formatted/commented patch. > > WDYT? > > This seems to work fine, except that reading a field from a const > AttrConst is not a constant expression in C++03, so the "set" > declarations (ParameterOnly,

Slightly formatted/commented patch. WDYT? --kcc On Tue, Feb 7, 2012 at 1:29 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Tue, Feb 7, 2012 at 12:53 PM, Kostya Serebryany <kcc at google.com> wrote: > >> I see the problem. >> Let me try to come up with a solution that does not involve constructors >> but also does not sacrifice type safety.

http://llvm.org/releases/2.0/docs/CodingStandards.html I just realized that the target version is LLVM 2.0, so most likely the llvm::StringStream is deprecated by now. Thanks for your response! On 12/10/2011, at 17:10, Garrison Venn wrote: > Hi Pablo, > > Can you provide a link to the document containing a reference to > llvm::StringStream? I've looked in both the llvm coding

Hi Pablo, Can you provide a link to the document containing a reference to llvm::StringStream? I've looked in both the llvm coding standards, and llvm programming manual for versions: ToT (3.0), 2.9 (which seems to be the same as ToT), and 2.8. Obviously my search is missing something. Thanks in advance Garrison On Oct 12, 2011, at 8:18, Pablo Barrio wrote: > Hi, > > I need

From: Matt Fleming <matt.fleming at intel.com> GCC 4.7 now places pointers to functions with the 'constructor' and 'destructor' function attributes in .init_array and .fini_array sections, respectively, whereas previously they were in the .ctors and .dtors sections. This change breaks the ctors/dtors code as it only expects function to be in the .ctors and .dtors sections,

I'm not advocating AAA. However this is a proposal for more modern thinking regarding the permissiveness of auto in LLVM codebases. Currently the rule on the use of auto is here: https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable It is quite strict. It allows the use of auto for * lambdas * iterators because they are long to type * casts to

Hello all! I extended the LDC2 with a pragma to register a funcion in the llvm.global_ctors or llvm.global_dtors list. On Linux, references to these functions are placed in .ctors and .dtors sections and everything runs fine. On Windows, functions from llvm.global_ctors are placed in section .CRT$XCU, which is automatically called by the MS C Runtime. However, functions from

On Fri, Dec 30, 2016 at 2:08 AM Piotr Padlewski via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Thanks for very accurate responses. > - I totally agree what Dave and Chandler said about explicit and implicit > operations, this is what I meant my first email. > I believe there are places like > v.emplace_back(A, B); > istead of > v.push_back(make_pair(A,

+llvmdev, -llvm-dev On Tue, Jun 26, 2012 at 2:28 PM, Kostya Serebryany <kcc at google.com> wrote: > Hi Reid, > > On Tue, Jun 26, 2012 at 4:30 AM, Reid Watson <reidw at google.com> wrote: > >> Hello, >> >> I'm starting work on a project to detect initialization order problems >> in C++ files using AddressSanitizer. >> The extension in

Hello > On Windows, functions from llvm.global_ctors are placed in section .CRT$XCU, > which is automatically called by the MS C Runtime. Only if you link with MS runtime. Mingw follows standard .ctors / .dtors scheme. > My expectation was that the dtors placed in .CRT$XTU which are the C > terminator functions. Maybe there is a way to customize this? Yes. Target (or,rather

2016-12-30 11:34 GMT+01:00 Chandler Carruth <chandlerc at gmail.com>: > On Fri, Dec 30, 2016 at 2:08 AM Piotr Padlewski via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Thanks for very accurate responses. >> - I totally agree what Dave and Chandler said about explicit and implicit >> operations, this is what I meant my first email. >> I believe

On Thu, Nov 29, 2012 at 7:43 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Thu, Nov 29, 2012 at 3:49 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Moving to LLVM dev to discuss the possibility of extending the cast > > infrastructure to handle this. > > > > On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote:

On Mon, Jan 9, 2017 at 6:17 AM Piotr Padlewski via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Are there any other comments about changing style guide? > I would like to add points like > > - prefer "using' instead of "typedef" > - use default member initialization > struct A { > void *ptr = nullptr; > }; > > (instead of doing it in

On Thu, Nov 29, 2012 at 8:16 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Thu, Nov 29, 2012 at 7:43 PM, Eli Friedman <eli.friedman at gmail.com> > wrote: >> >> On Thu, Nov 29, 2012 at 3:49 PM, David Blaikie <dblaikie at gmail.com> wrote: >> > Moving to LLVM dev to discuss the possibility of extending the cast >> > infrastructure to