similar to: [LLVMdev] Goal for 3.5: Library-friendly headers

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Goal for 3.5: Library-friendly headers"

2013 Nov 11
0
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
I don't think NDEBUG is that easy. We use assert liberally[1] in templated code in headers. What about cast<>, which has assert(isa<...>...)? On ELF, you have an ODR problem, and you'll get either one or the other based on the whims of the dynamic linker. You could probably get things to the point that it sort of works, but I don't think we could support it without
2013 Nov 10
0
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On Sun, Nov 10, 2013 at 01:42:24PM +0000, Alp Toker wrote: > |#undef NetBSD|| > ||#undef mips|| > ||#undef sparc|| > ||#undef INT64_MAX|| > ||#undef alloca| > > This is not OK to do globally -- even if LLVM doesn't care about the > definition, maybe embedding applications or OS headers do? Given that 3 of the 5 #undefs are directly relevant for me -- they exist
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 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
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 Nov 11
0
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
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 not modify API. class structure (member offset, vtables) should be stable and
2014 Jan 03
2
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On 03/01/2014 21:55, Chandler Carruth wrote: > > On Tue, Nov 12, 2013 at 1:20 AM, Chris Lattner <clattner at apple.com > <mailto:clattner at apple.com>> wrote: > > n Nov 11, 2013, at 12:09 PM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com>> wrote: > > >> Even when you have a !NDEBUG build, the platform assert() is pretty
2013 Nov 12
3
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On Nov 11, 2013, at 12:09 PM, Alp Toker <alp at nuanti.com> wrote: >> Even when you have a !NDEBUG build, the platform assert() is pretty >> crummy on Windows and generates, at best a UTF-16 dump, or sometimes >> just pops up a dialog. WebKit and other projects take the same approach >> and define their own assertion macros to deal with this portably. >>
2013 Nov 11
0
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On 11/11/2013 19:16, Alp Toker wrote: > 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/ >>>
2013 Nov 10
1
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On 10/11/2013 14:26, Joerg Sonnenberger wrote: > On Sun, Nov 10, 2013 at 01:42:24PM +0000, Alp Toker wrote: >> |#undef NetBSD|| >> ||#undef mips|| >> ||#undef sparc|| >> ||#undef INT64_MAX|| >> ||#undef alloca| >> >> This is not OK to do globally -- even if LLVM doesn't care about the >> definition, maybe embedding applications or OS headers
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
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 Jan 31
7
[LLVMdev] [cfe-dev] Status of SEH?
On 30/01/2014 22:57, Daniel Berlin wrote: > On Thu, Jan 30, 2014 at 2:34 PM, Alp Toker <alp at nuanti.com> wrote: >> On 30/01/2014 22:06, Daniel Berlin wrote: >>> Actually, the policy actually says the right thing, you removed a >>> sentence, which says: >>> "Please contact the oversight group for more details." >> >> To be clear, I
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
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
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: