similar to: Building LLVM 3.8 and later with 2016 Intel C++ compiler

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

On Sep 28, 2012, at 10:18 PM, Richard Smith <richard at metafoo.co.uk> wrote: > 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; }; > >

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

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 A<C*>::type type; }; > typedef typename A<C*>::type type; > }; > B<int> b; > > ... produces ...

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: >

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

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

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

Hi Dave, It may be possible to do this with the current API, but what I was looking for is a common API for existing block types. For example there is no succ_begin for Machine BasicBlock. I'm looking to make the CFGSuccessors and CFGPredecessors classes in CFGDiff.h templated, and this needs a common API for all types instantiations. Does this clarify your question or did I misunderstand

Hey Nick, what's the status on YAML IO? The other thread seems to have died. -- Sean Silva

On Tue, Mar 10, 2020 at 2:30 PM David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Mar 10, 2020 at 8:31 AM Alina Sbirlea <alina.sbirlea at gmail.com> > wrote: > >> Hi Dave, >> >> It may be possible to do this with the current API, but what I was >> looking for is a common API for existing block types. For example there is >> no

Hi, As part of an ongoing work to extend the GraphDiff (this models a CFG view), I came across the need to have a common interface for accessing successors/predecessors in various IR units, such that a type such as `typename NodeT::succ_iterator` could be used in templated code. In particular, the need arose for BasicBlocks, MachineBasicBlocks, VPBlockBase and clang::CFGBlock. The least invasive

On Mar 19, 2014, at 11:32 AM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Wed, Mar 19, 2014 at 2:13 PM, Lang Hames <lhames at gmail.com> wrote: >> Hi all, >> >> As RFCs go this is short and sweet - I think it would be nice to add an >> empty method to iterator_range. Something like: >> >> bool empty() const { return begin() != end();

Hi all, As RFCs go this is short and sweet - I think it would be nice to add an empty method to iterator_range. Something like: bool empty() const { return begin() != end(); } My motivation is to make the 'if' test at the start of this common pattern tidier: if (!collection.empty()) // initialization... for (auto& c : collection) // do something for each c. which I think that

Hello, Our llvm::iterator_range is quite minimalist in design, it does not even have an "empty" method. Is that because we want it to work on all iterators (including those dirty OutputIterator)? Maybe we can add a little bit to it? I recently needed: - bool empty() - value_type& font() - value_type& back() - void advance_begin(difference_type n) - void

On Oct 22, 2012, at 4:40 PM, Sean Silva wrote: > Hey Nick, what's the status on YAML IO? The other thread seems to have died.\ I'm waiting on Michael Spencer's feedback. The issues I know of right now are: 1) Should we structure YAML I/O to be a more general I/O utility that could support reading and writing other data formats such as JSON or plists. RIght now, all the code is

On Sun, Jan 13, 2013 at 2:10 PM, Matthieu Monrocq <matthieu.monrocq at gmail.com> wrote: > gcc 4.5, MSVC 10, clang 3.1 > - decltype v1.0 [1] + late specified return type > - lambda v1.0 [2] > - local types as template arguments > - r-value 2.0 [3] > - static_assert > - built-in type traits This isn't very encouraging. Anecdotally from what I've seen in LLD

On Sun, Jan 13, 2013 at 10:26 AM, Tim Northover <t.p.northover at gmail.com> wrote: >> Good points David, I don't feel qualified to evaluate the differences >> between those versions though... Perhaps Richard or Doug could comment here? > > Unless I'm misreading the buildbots, we don't actually have anything > trying to build with MSVC. Have we considered how

On Sun, Jan 13, 2013 at 9:59 PM, Sean Silva <silvas at purdue.edu> wrote: > On Sun, Jan 13, 2013 at 2:10 PM, Matthieu Monrocq > <matthieu.monrocq at gmail.com> wrote: > > gcc 4.5, MSVC 10, clang 3.1 > > - decltype v1.0 [1] + late specified return type > > - lambda v1.0 [2] > > - local types as template arguments > > - r-value 2.0 [3] > > -

On Mar 2, 2014, at 10:47 PM, Chandler Carruth <chandlerc at google.com> wrote: >> I'm not aware of the prior art or standards are here, but I think that a global reverse() adapter is the way to go. Likewise, we should have a standard "enumerate()" adaptor like python. >> >> I definitely prefer the global adaptor pattern. As for prior art, I had played with