search for: instantiations

On Dec 4, 2009, at 12:40 PM, Duncan Sands wrote: > Hi Bill, > >> Here's what I get with TOT compiling with -Os. The orig.ll is what >> I get before r72619. Notice that orig.ll has only one function in >> it. Both the one you sent and duncan.ll have more than one >> function. It's not the fact that more than one function is showing >> up, but

>> > Only "_Z11dummysymbolv" should be there. Here's Doug's explanation of > why this should be so: > > Here's what it *looks* like is happening, and where the FE is probably > getting it wrong. First of all, the constructor in question is defined > outside of the basic_string class template as a non-inline definition: > >

Reduced testcase: template<typename T> struct A { typedef decltype(T() + 0) type; }; template<typename T> struct B { struct C { typedef typename A<C*>::type type; }; typedef typename A<C*>::type type; }; B<int> b; ... produces ... <stdin>:3:38: error: no type named 'type' in 'A<B<int>::C *>' struct C { typedef typename

Hello, I am working on a tool which takes c++ header files and based on interfaces defined in them generates csharp classes and glue layer for interop. For analyzing the c++ code I am currently using clang, which parses the headers and writes output into xml via -ast-print-xml (yes, this unfortunately means that it is a very old version of clang). I then use these xml files to generate the csharp

Hi Bill, > Here's what I get with TOT compiling with -Os. The orig.ll is what I get > before r72619. Notice that orig.ll has only one function in it. Both the > one you sent and duncan.ll have more than one function. It's not the > fact that more than one function is showing up, but these functions in > particular shouldn't be there because of the implicit/explicit

On Dec 4, 2009, at 12:52 AM, Duncan Sands wrote: > Hi Bill, > >> There's a problem with your check-in for r72619 is causing "weak >> external" symbols to appear in C++ code when it shouldn't. Take >> this code for example, >> #include <stdexcept> >> void dummysymbol() { >> throw(std::runtime_error("string"));

Hi, While investigating the situation of visibility annotations and linkage in libc++ with the goal of removing uses of `__always_inline__`, Eric Fiselier and I stumbled upon the attached test case, which I don't think Clang compiles properly. Here's the gist of the test case, reduced to the important parts (see the attachment if you want to repro): // RUN: %cxx -shared -o

This doesn't appear to me to be the same issue (but of course I don't know clang as well as you all do). This code appears invalid (and G++ rejects it with a similar "no type named ..." error message), whereas the original code is valid C++ (both C++98 and C++11). On Fri, Sep 28, 2012 at 3:54 PM, Richard Smith <richard at metafoo.co.uk> wrote: > Reduced testcase: >

On Dec 4, 2009, at 2:40 PM, Eric Christopher wrote: >>> >> Only "_Z11dummysymbolv" should be there. Here's Doug's explanation of >> why this should be so: >> >> Here's what it *looks* like is happening, and where the FE is >> probably >> getting it wrong. First of all, the constructor in question is >> defined >>

Is this a relevant location to provide information about what I believe is a compiler bug in clang? If not, please forgive me for posting it here. (Perhaps you can redirect me to some place more appropriate.) If so, here are the details: I have a short 15-line C++ program using only one standard header that clang fails to compile properly under C++11 with the new standard library (although the

Hi All, I have just started using LLVM . i am facing a issue while using ilist container. Here is a struct with ilist container as its one element. typedef ilist<Instruction *> InstListType; struct list_node { int Impact; InstListType InstList; }; list_node

...some > alternate solution via this mail. > > Ondrej > > > On Tue, May 8, 2012 at 1:03 AM, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > Is the original definition of the template available in the XML file, not > > just the reference to the specific instantiations (i.e. > > IMyEnumerator<int>). > > > > > > On Mon, May 7, 2012 at 12:08 PM, Ondrej Kolacek <natris1 at gmail.com> > wrote: > >> > >> (another try from different mail account; I hope I was able to clarify > >> my issue better. ) >...

Most of libc++ doesn't have explicit template instantiations, which leads to a pretty significant build time and code size cost when using libc++, since a large number of common templates will be emitted by the compiler and coalesced by the linker. Notably, in include/__config, we have: #ifndef _LIBCPP_EXTERN_TEMPLATE #define _LIBCPP_EXTERN_TEMPLATE...

Hey everyone, I''m trying to find a work around for a performance problem I''ve been having. I have a class that builds paths (among other things) dynamically to many files and folders depending on what sets of information the user accesses. Once built, this class instantiation contains all the information necessary for several pages (controllers/views) to operate. However at

...e: in instantiation of function template specialization 'func<false>' requested here return func<true>() + func<false>(); ^ 2 warnings generated. I have at least two (possibly naive) ideas about how to handle this: 1) Visit templates & skip instantiations. This is even consistent with some existing code (see CFG.cpp:441-ish, where the Expr *S is checked for type/value dependence & the condition is not evaluated if that is the case - in fact that's never the case because AnalysisBasedWarnings.cpp:821 skips analyzing any dependent context. Ins...

Is the original definition of the template available in the XML file, not just the reference to the specific instantiations (i.e. IMyEnumerator<int>). On Mon, May 7, 2012 at 12:08 PM, Ondrej Kolacek <natris1 at gmail.com> wrote: > (another try from different mail account; I hope I was able to clarify > my issue better. ) > > Hello, > I am working on a tool which takes c++ header files of a C...

That is one evil bug! I just tested it against tip-of-trunk clang and it appears to be fixed there (just fyi for everyone). Howard On Sep 27, 2012, at 7:17 PM, Adam Peterson <alpha.eta.pi at gmail.com> wrote: > Is this a relevant location to provide information about what I > believe is a compiler bug in clang? If not, please forgive me for > posting it here. (Perhaps you can

...terator iterator_type; libc++'s std::map implementation was using a construct whose semantics depended on whether 'Member' is a complete type (thus triggering the instantiation of that type in the middle of instantiating map<K,Member*>, creating a dependency cycle between the two instantiations). I'm not at all clear on whether that is permissible behavior for a standard library implementation, but it still seems to be a problem in some cases. libc++'s is_assignable implementation uses SFINAE on this: decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_ty...

On Fri, Sep 28, 2012 at 6:45 PM, Howard Hinnant <hhinnant at apple.com> wrote: > On Sep 28, 2012, at 5:54 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > > Reduced testcase: > > > > template<typename T> struct A { typedef decltype(T() + 0) type; }; > > template<typename T> struct B { > > struct C { typedef typename

Is there any way to get AR to instantiate a different class when using STI? Where it would normally instantiate Digit, I would like it to instantiate SkelDigit. Here''s why... My rails app has the following STI hierarchy: Digit < Glyph < ActiveRecord::Base My migrate script can''t use those classes directly however (backward compatibility issues), so I created some