similar to: [LLVMdev] [RFC] Relax the rules on const auto&? (was Re: r203179 - [C++11] Replacing iterators redecls_begin() and redecls_end() ...)

> On 24 Mar 2015, at 14:55, Aaron Ballman <aaron at aaronballman.com> wrote: > > On Tue, Mar 24, 2015 at 9:48 AM, Rinaldini Julien > <julien.rinaldini at heig-vd.ch> wrote: >> Hi, >> >> I want to *tag* some functions with some *flags*. I was using annotate((“myFlag”)) and everything was working fine until I tried on ObjC method. It seems that clang just

On 3 March 2014 01:48, Tobias Grosser <tobias at grosser.es> wrote: > I am not a C++11 expert, but I must say I was very glad for the hint Duncan > gave me. If there are no technical concerns, I am very much in favor of this > addition. +1 --renato

I think this issue is that we were not using the INTERCEPTOR macros to define these functions. The following patch seems to work for me to get the build linking again, however, I cannot test -- when I run check-asan, I get: 2> lit.py: lit.common.cfg:59: fatal: Invalid llvm_tools_dir config attribute: 'E:/llvm/2013/$(Configuration)/bin' ~Aaron On Thu, Oct 23, 2014 at 1:20 PM, Aaron

http://llvm.org/bugs/show_bug.cgi?id=21241 ? 2014-10-23 10:18 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: > On Thu, Oct 23, 2014 at 1:15 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 1:13 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> Yes it is. >>> Are you doing a Debug or Release build?

On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > I don't think this is the right approach. > > Currently we intentionally define malloc etc without changing the > names and (when stuff works ok) the linker just links all the mem > allocator calls with calls to our RTL. This is kind of a link-time > interception. How could that work

On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >> On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> I don't think this is the right approach. >>> >>> Currently we intentionally define malloc etc

compiler-rt libs must be built with /MT, so the MSVS build is doing the wrong thing here. 2014-10-23 12:52 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: > On Thu, Oct 23, 2014 at 3:42 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 3:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >>> On Thu, Oct 23, 2014 at 2:57

On Thu, Oct 23, 2014 at 1:13 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Yes it is. > Are you doing a Debug or Release build? > Using ninja? Release build, cmake + MSVC (not using ninja). Perhaps I have it configured stupidly; I have it as an out-of-tree folder, did: E:\llvm\crt_build>cmake -DLLVM_CONFIG_PATH=E:\llvm\2013\Debug\bin -G "Visual Studio 12"

On Thu, Oct 23, 2014 at 3:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Oct 23, 2014 at 2:57 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >>>> On Thu, Oct

On Mon, Jul 15, 2019 at 2:43 PM Siva Chandra <sivachandra at google.com> wrote: > > > On 7/15/19 1:22 PM, Aaron Ballman via llvm-dev wrote: > > > On Mon, Jul 15, 2019 at 1:02 PM Siva Chandra <sivachandra at google.com> wrote: > > >> On Fri, Jul 12, 2019 at 8:32 AM Aaron Ballman <aaron at aaronballman.com> wrote: > > >>>> llvm-libc

Fixed formatting. On Mon, Oct 10, 2011 at 9:13 PM, Aaron Ballman <aaron at aaronballman.com>wrote: > I would still fix the code formatting even though you merely > uncommented it (just to be consistent with the rest of the code). But > functionally-speaking, I think your patches are good. > > ~Aaron > -------------- next part -------------- An HTML attachment was

On 7/15/19 1:22 PM, Aaron Ballman via llvm-dev wrote: > On Mon, Jul 15, 2019 at 1:02 PM Siva Chandra <sivachandra at google.com> wrote: >> On Fri, Jul 12, 2019 at 8:32 AM Aaron Ballman <aaron at aaronballman.com> wrote: >>>> llvm-libc is an implementation of the C standard library targeting C11 >>>> and above. >>> Any particular reason for C11

https://www.visualstudio.com/en-us/news/vs2015-vs.aspx Is it time? 2016-03-31 12:03 GMT-07:00 Aaron Ballman via llvm-dev < llvm-dev at lists.llvm.org>: > On Thu, Mar 31, 2016 at 2:57 PM, Zachary Turner <zturner at google.com> > wrote: > > > > > > On Tue, Mar 29, 2016 at 10:42 AM Aaron Ballman <aaron at aaronballman.com> > > wrote: > >>

On Fri, Jul 12, 2019 at 8:32 AM Aaron Ballman <aaron at aaronballman.com> wrote: > > llvm-libc is an implementation of the C standard library targeting C11 > > and above. > > Any particular reason for C11 as opposed to C17? Two reasons: 1. The C++17 standard refers to the C11 standard. 2. C11 is sufficiently modern while not closing doors for users requiring compliance

There are certainly enough people making commits that work with VS2015 but not VS2013 that the "would it be useful" question is pretty well answered. I've already brought up the idea on my team, as it's obviously coming and we need time to coordinate with internal consumers of the toolchain. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Zachary

What is the procedure now? Do we just wait for someone else to look at it and commit (I'm guessing that you don't have commit access)? cfe-commits is in the CC. On Tue, Oct 11, 2011 at 6:55 PM, Aaron Ballman <aaron at aaronballman.com>wrote: > Looks good to me! > > Thanks! > > ~Aaron > > On Tue, Oct 11, 2011 at 2:26 AM, Nikola Smiljanic <popizdeh at

On 31 May 2016 at 21:24, Aaron Ballman <aaron at aaronballman.com> wrote: > Are we sure that github's svn integration works with common tools on > Windows, like TortoiseSVN? That's a good question. Can you try them out and report back? cheers, --renato

> In general, I'm not too keen on adding more calling conventions unless > there's a really powerful need for one from an ABI perspective. This > sounds more like an optimization than an ABI need. I think that is the case. > What's more, I > worry (a little bit) about confusion that could be caused with the > __vectorcall calling convention (which we do not

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();

FWIW, no objections from me, after all I proposed this 3 months ago :) Probably Aaron Ballman should comment though since the primary objection last time was his. On Fri, Jul 29, 2016 at 2:00 PM Sean Silva <chisophugis at gmail.com> wrote: > On Fri, Jul 29, 2016 at 1:23 PM, Robinson, Paul via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> There are certainly