search for: instantiable

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

My gut tells me that if it isn't already available, then it will be difficult as the instantiation has to occur for the final compilation, but that must be occurring in a later phase of compilation than the one where the XML file is generated. Their is also a good chance that the instantiation depends on information that isn't available until after the XML file is generated (things like

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(...) #endif whereas before

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

I'm just wondering if anyone's already working on addressing the current shortcomings around -Wunreachable-code in regards to templates. Take the following simple example: $ cat unreachable.cpp int func1(); int func2(); template<bool b> int func() { return !b ? func1() : func2(); } int main() { return func<true>() + func<false>(); } $ clang++ -Wunreachable-code

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

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

On Fri, Sep 28, 2012 at 5:11 PM, Adam Peterson <alpha.eta.pi at gmail.com>wrote: > 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). [The

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