similar to: [LLVMdev] [cfe-dev] Status of SEH?

Displaying 20 results from an estimated 8000 matches similar to: "[LLVMdev] [cfe-dev] Status of SEH?"

2013 Dec 11
3
[LLVMdev] [cfe-dev] Phabricator email
On 11 December 2013 17:35, Alp Toker <alp at nuanti.com> wrote: > I noticed a few contributors have been landing patches without responding to > my review comments. Oh, that happened to me too, but it turns out you have to press the "clowncopterize" after making comments inlilne, or Phabricator won't publish them. You can see them, we can't. cheers, --renato
2014 Jun 06
2
[LLVMdev] buildbot failure in LLVM on sanitizer-x86_64-linux (-Wframe-larger-than)
On 06/06/2014 02:33, Alexey Samsonov wrote: > Hi Alp, > > This warning should be fixed by r210301. However, consider > investigating why the frame size appears to be that large. I believe > we build this code with GCC as well and have seen no complaints > from its implementation of -Wframe-larger-than. CC'ing in llvmdev. Like Chandler said it could just be due to lack of
2014 Jun 25
2
[LLVMdev] Phabricator and private reviews
On 25/06/2014 21:03, Eli Bendersky wrote: > On Wed, Jun 25, 2014 at 10:44 AM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com>> wrote: > > For whatever reason, patches posted to the Phabricator website > still aren't being sent to the mailing list, making it difficult > for us to review them. > > I've raised this issue a couple
2014 Jun 25
12
[LLVMdev] Phabricator and private reviews
For whatever reason, patches posted to the Phabricator website still aren't being sent to the mailing list, making it difficult for us to review them. I've raised this issue a couple of times in the last few weeks. In practice this has a detrimental effect to the development workflow because it means that code is being seen only by a small group of individuals who have web accounts.
2013 Dec 11
0
[LLVMdev] [cfe-dev] Phabricator email
On 11/12/2013 17:48, Renato Golin wrote: > On 11 December 2013 17:35, Alp Toker <alp at nuanti.com> wrote: >> I noticed a few contributors have been landing patches without responding to >> my review comments. > Oh, that happened to me too, but it turns out you have to press the > "clowncopterize" after making comments inlilne, or Phabricator won't >
2014 Feb 27
3
[LLVMdev] Future of the LLVM OpenMP runtime
On 26/02/2014 09:03, David Chisnall wrote: > On 25 Feb 2014, at 23:13, Alp Toker <alp at nuanti.com> wrote: > >> Now that we've kick-started the LLVM OpenMP runtime discussion, I want to make a concrete proposal to get a test suite up and running for the LLVM OpenMP runtime. I don't think the current setup as an LLVM subproject is sustainable going forward without some
2014 Jun 25
5
[LLVMdev] Phabricator and private reviews
On 25/06/2014 21:18, Eli Bendersky wrote: > > > > On Wed, Jun 25, 2014 at 11:10 AM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com>> wrote: > > > On 25/06/2014 21:03, Eli Bendersky wrote: > > On Wed, Jun 25, 2014 at 10:44 AM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com> <mailto:alp at nuanti.com
2013 Nov 11
3
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On 11/11/2013 19:08, Chris Lattner wrote: > On Nov 11, 2013, at 9:56 AM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com>> wrote: >> Done :-) >> >> The patchset is 532K so I've put it online: >> >> http://www.nuanti.com/tmp/llvm-api-stability/ >> >> The bulk edits are split out and noted. They were refactored with an
2013 Nov 10
8
[LLVMdev] Goal for 3.5: Library-friendly headers
With the recent thread on using C++11 in LLVM/clang, one of the recurring themes was a desire to make the internal headers more consumable. While I don't personally want any kind of stability guarantee for internal headers, I do think we can do more to ensure that any given snapshot of the headers is consumable from different compilers and build configurations. In practice this means
2014 Jul 01
4
[LLVMdev] Usability of phabricator review threads for non-phab-users
On 01/07/2014 21:28, Alp Toker wrote: > Specifically the problem I've been seeing is that people using the > website are unable to CC mailing list-based developers. As a result I > don't get copied in on responses to my review comments, and rarely get > any kind of direct mail with threading. You end up having to dig up > historic responses in the mailing list archive
2014 May 05
2
[LLVMdev] 3.4 branch gcc 4.9 build error
On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Mon, May 5, 2014 at 8:11 AM, Alp Toker <alp at nuanti.com> wrote: > >> I suspect that pulling in clang header fixes r201729, r202911 and r207606 >> to 3.4.1 will resolve libstdc++ / glibc compatibility issues people have >> been having with 3.4: >> >> r201729:
2013 Dec 10
4
[LLVMdev] lit: deprecating trailing \ in RUN lines
On 10/12/2013 19:47, Jim Grosbach wrote: > > On Dec 10, 2013, at 11:26 AM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com>> wrote: > >> >> On 10/12/2013 18:03, Jim Grosbach wrote: >>>> That causes dissonance between what the compiler sees and what >>>> lit.py sees for no particularly good reason. One of the nice
2014 Jun 25
4
[LLVMdev] Phabricator and private reviews
I have to agree with Alp here. I’ve seen a number of review threads that either seem to be missing emails or in which the emails arrive days in unintelligible orders. I don’t know that we need to cut off use of it, but we need to prioritize resolving this issue. —Owen On Jun 25, 2014, at 10:59 AM, Eric Christopher <echristo at gmail.com> wrote: > I don't think it's all
2013 Nov 11
2
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On 11/11/2013 07:37, NAKAMURA Takumi wrote: > 2013/11/10 Alp Toker <alp at nuanti.com>: >> #ifndef NDEBUG >> >> This is the biggest violation. NDEBUG should only ever be used in source >> files. That way if something is crashing we can swap in a debug build >> without rebuilding every single dependent application. Win! > I wish; > > - NDEBUG may
2014 May 05
3
[LLVMdev] 3.4 branch gcc 4.9 build error
On 04/05/2014 02:30, Tom Stellard wrote: > On Sat, May 03, 2014 at 12:32:02AM +0100, Alp Toker wrote: >> On 02/05/2014 20:45, Tuncer Ayaz wrote: >>> Bump. >>> >>> Is it really unsupported to build llvm from scratch with gcc 4.9 and >>> libstdc++ 4.9? Should I file a bugzilla ticket instead? >> Obviously LLVM/clang should compile out of the box
2014 Feb 25
6
[LLVMdev] Future of the LLVM OpenMP runtime
Now that we've kick-started the LLVM OpenMP runtime discussion, I want to make a concrete proposal to get a test suite up and running for the LLVM OpenMP runtime. I don't think the current setup as an LLVM subproject is sustainable going forward without some form of testing support, automated or otherwise. The motivation: It's difficult to make changes to the source without some
2014 Jul 17
2
[LLVMdev] Fwd: Re: [PATCH] [TABLEGEN] Do not crash on intrinsics with names longer than 40 characters
On 17/07/2014 20:27, Eric Christopher wrote: > Hi Alp, > > On Thu, Jul 17, 2014 at 6:25 AM, Alp Toker <alp at nuanti.com> wrote: >> Hi Manuel, >> >> Here's another commit authored through the web interface where no discussion >> or reviewership information is apparent on the mailing list. > If you look at the phab review, it's the same there. Does
2014 May 06
2
[LLVMdev] 3.4 branch gcc 4.9 build error
On Mon, May 05, 2014 at 11:42:28PM +0100, Alp Toker wrote: > > On 05/05/2014 20:51, Richard Smith wrote: > > On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth > > <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: > > > > On Mon, May 5, 2014 at 8:11 AM, Alp Toker <alp at nuanti.com > > <mailto:alp at nuanti.com>>
2013 Nov 11
0
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On Nov 11, 2013, at 9:56 AM, Alp Toker <alp at nuanti.com> wrote: > Done :-) > > The patchset is 532K so I've put it online: > > http://www.nuanti.com/tmp/llvm-api-stability/ > > The bulk edits are split out and noted. They were refactored with an internal tool, so it's not a big hassle to keep this up to date until 3.4 is out the door. > > A handful
2013 Dec 10
2
[LLVMdev] lit: deprecating trailing \ in RUN lines
On 10/12/2013 18:03, Jim Grosbach wrote: >> That causes dissonance between what the compiler sees and what lit.py >> sees for no particularly good reason. One of the nice properties of >> lit tests is that they're also valid compiler inputs, so trailing >> slash is a bit unfortunate. >> > > How does the backslash break this in any way? The backslash is