similar to: [LLVMdev] Incomplete X86MachineFunctionInfo type

I've completed a survey of llvm for unnecessary dependencies on libstdc++, and on conflicts with the upcoming C++0X standard, and am recommending several changes in the enclosed patch (created with svn diff). Here is a summary of the patch: --- #include <cstdlib> added to LinkAllVMCore.h and LinkAllCodegenComponents.h to declare std::getenv. Changed next(...) to llvm::next(...) in

On Dec 2, 2009, at 6:54 AM, Howard Hinnant wrote: > I've completed a survey of llvm for unnecessary dependencies on > libstdc++, and on conflicts with the upcoming C++0X standard, and am > recommending several changes in the enclosed patch (created with svn > diff). Thanks, applied here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091130/092102.html I

On Feb 14, 2014, at 1:09 PM, Howard Hinnant <hhinnant at apple.com> wrote: > Author: hhinnant > Date: Fri Feb 14 15:09:01 2014 > New Revision: 201432 > > URL: http://llvm.org/viewvc/llvm-project?rev=201432&view=rev > Log: Remove myself as owner of libc++ > > Modified: > llvm/trunk/CODE_OWNERS.TXT > > Modified: llvm/trunk/CODE_OWNERS.TXT > URL:

On Fri, Feb 14, 2014 at 1:29 PM, Howard Hinnant <hhinnant at apple.com> wrote: > On Feb 14, 2014, at 4:23 PM, Marshall Clow <mclow.lists at gmail.com> wrote: > >> On Feb 14, 2014, at 1:09 PM, Howard Hinnant <hhinnant at apple.com> wrote: >> >>> Author: hhinnant >>> Date: Fri Feb 14 15:09:01 2014 >>> New Revision: 201432 >>>

The target description .td files are allowed to change the default allocation order on a register class by overriding the allocation_order_begin() and allocation_order_end() methods on TargetRegisterClass. Previously, this was used all the time to filter out stack and frame pointers and other reserved registers. I was able to remove most of these custom allocation orders in the tree because 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

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; }; > >

Best guess is that you're clobbering something in the red zone. https://en.wikipedia.org/wiki/Red_zone_(computing). It's not guarantee that the area of the stack above the stack pointer is unused. I think you can check if the redzone is used by checking getUsesRedZone() in X86MachineFunctionInfo. If the red zone is used, its not safe to insert a push/pop. I think you can turn off the red

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

Comments: CheckDAGForTailCallsAndFixThem - 1. for (SelectionDAG::allnodes_iterator BE = DAG.allnodes_begin(), + BI = prior(DAG.allnodes_end()); BI != BE; BI--) { Please use pre-decrement instead of post-decrement. 2. The function is slower than it should be. You are scanning all the nodes in the DAG twice. You should just examine DAG.getRoot() to make determine whether it's a

On 9/4/20 3:37 AM, Luo, Yuanke wrote: > > Hi Hal, > > Thank you for the ideas that help us to improve the design, and sorry > for replying late. There is something I am not able to figure out and > there some special trait for tile RA. > You're quite welcome. > 1.X86RegisterInfo::getRegAllocationHints can tell RA which physical > register is preferred, but it

On Feb 28, 2012, at 6:34 AM, Chandler Carruth wrote: > Howard, high-level feedback from you would be particularly appreciated as I would love to contribute this to libc++ when the time is right. Does the enclosed implementation implement this part of N3333: http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2012/n3333.html#per.process.seed ? That to me seems like potentially the most

Hi @ll, compiler-rt implements (for example) the MSVC (really Windows) specific routines compiler-rt/lib/builtins/i386/chkstk.S and compiler-rt/lib/builtins/x86_64/chkstk.S as __chkstk_ms() See <http://msdn.microsoft.com/en-us/library/ms648426.aspx> Is there any special reason why compiler-rt doesn't implement other MSVC specific functions (alias builtins or "compiler

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

Fix typo From: Luo, Yuanke Sent: Friday, September 4, 2020 9:47 PM To: 'Hal Finkel' <hfinkel at anl.gov>; Topper, Craig <craig.topper at intel.com>; Kaylor, Andrew <andrew.kaylor at intel.com>; Philip Reames <listmail at philipreames.com>; llvm-dev at lists.llvm.org; florian_hahn at apple.com; Lu, Hongjiu <hongjiu.lu at intel.com> Subject: RE: [llvm-dev]

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 3, 2009, at 5:24 AM, Ahmed Charles wrote: > Sorry, always end up not replying to the list: > > The main issue with dealing with next this way is that people adding new uses of next will probably not be using c++0x and therefore won't know it's ambiguous and that it needs to be qualified. True. But when this code is compiled under C++0X you get an easy to diagnose, easy

Hi, Yuanke, Thanks for writing this up. Let me back up a bit because the scheme I proposed last week doesn't work without further modification: within a particular "configuration region" (i.e., the code in between the LDTILECFG and the TILERELEASE (or next LDTILECFG)), each tile register can only be used with one shape, and in addition, no register can have its shape changed

Sorry, always end up not replying to the list: The main issue with dealing with next this way is that people adding new uses of next will probably not be using c++0x and therefore won't know it's ambiguous and that it needs to be qualified. There are also two issues with rvalue references and the STL: 1. EquivalenceClasses, in the insert and findLeader functions, it uses map functions

On 3 December 2012 10:42, Mayur Pandey <mayurthebond at gmail.com> wrote: > So this seems to be the cause of the problem. I guess you're mixing two different problems. First, is the possible lack of conformance with the ABI you state, which I can't comment since I don't know that ABI very well. Second, is the fact that clang is not printing correct debug information (or is