similar to: 8.0 Regression with __builtin_constant_p.

Hi Bill, I committed a fix already as r355743 [1], and it fixes `test2` as well. I believe we should merge this into 8.0. /Eric [1] https://github.com/llvm/llvm-project/commit/680e865c313a80b6ec329abde61e1f0c66bdc103 On Fri, Mar 8, 2019 at 5:46 PM Bill Wendling <isanbard at gmail.com> wrote: > Hi Eric, > > The attached patch may help matters, though it now fails because

On Mon, Nov 16, 2020 at 4:10 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Nov 16, 2020 at 2:44 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > > > > > On Mon, Nov 16, 2020 at 2:12 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> On Mon, Nov 16, 2020 at 1:55 PM Mehdi AMINI <joker.eph at

On Mon, Nov 16, 2020 at 6:14 PM Sean Silva <chisophugis at gmail.com> wrote: > > > On Mon, Nov 16, 2020 at 4:48 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> >> >> On Mon, Nov 16, 2020 at 4:10 PM David Blaikie <dblaikie at gmail.com> wrote: >> >>> On Mon, Nov 16, 2020 at 2:44 PM Mehdi AMINI <joker.eph at gmail.com> wrote:

Hi, I am using the llvm libraries compiled with the C++14 standard with a host application that is compiled with the C++17 standard (Both on Windows/MSVC). I am running into an incompatibility for which I filed a bug report: https://bugs.llvm.org/show_bug.cgi?id=44131 However, I was wondering if C++17 host applications are even supported? Regards, Machiel van Hooren

On Aug 10, 2018, at 9:35 PM, Eric Fiselier <eric at efcs.ca> wrote: > > Part of me is still concerned with the future, and the filesystems which are yet to exist. > Me too. But it is best to target modern systems when targeting future systems adds an unnecessary cost. When future systems come into being, it is likely because future hardware is making those future systems

On Mon, Nov 16, 2020 at 4:48 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Mon, Nov 16, 2020 at 4:10 PM David Blaikie <dblaikie at gmail.com> wrote: > >> On Mon, Nov 16, 2020 at 2:44 PM Mehdi AMINI <joker.eph at gmail.com> wrote: >> > >> > >> > >> > On Mon, Nov 16, 2020 at 2:12 PM David Blaikie <dblaikie at

HI Guys, I recently tried VERY hard to override the database configuration bassed on ENV vars or actual API calls. This task is almost next to impossible. I know that the database.yml file is parsed as ERB but that is sane for simple ENV replacement if you want to actually change which database adaptor it is (requires extra config/params) it becomes messy. I found

On Mon, Nov 16, 2020 at 2:12 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Nov 16, 2020 at 1:55 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > On Mon, Nov 16, 2020 at 12:55 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> I will say I'm not a huge fan of adding even more names for things in > >> this fairly

[ please CC: me as I'm not subscribed ] On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla-daemon at cs.uiuc.edu wrote: > http://llvm.org/bugs/show_bug.cgi?id=3756 > > Chris Lattner <clattner at apple.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- >

Sure, I guess that splitting the arrayref/stringref headers out is a fine first step. -Chris > On Jul 5, 2017, at 5:07 PM, Zachary Turner <zturner at google.com> wrote: > > Re-writing StringRef / ArrayRef etc to use the exact same API is a good idea long term, but there's a lot of ugly messy details that need to be dealt with. There's thousands of uses of take_front /

Hello again! I took a stab at PR4898[1]. The attached patch improves Clang's __builtin_constant_p support so that the Linux kernel is happy. With this improvement, Clang can determine if __builtin_constant_p is true or false after inlining. As an example: static __attribute__((always_inline)) int foo(int x) { if (__builtin_constant_p(x)) return 1; return 0; } static

While porting LLDB over to StringRef, I am continuously running into difficulties caused by the fact that StringRef cannot be constructed from nullptr. So I wanted to see peoples' thoughts on removing this restriction from StringRef. To be clear, I'm only using LLDB as a motivating example, but I'm not requesting that it be done because LLDB is some kind of special case. If it is to

Pierre Habouzit wrote: > [ please CC: me as I'm not subscribed ] > > On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla-daemon at cs.uiuc.edu wrote: >> http://llvm.org/bugs/show_bug.cgi?id=3756 >> >> Chris Lattner <clattner at apple.com> changed: >> >> What |Removed |Added >>

Yes, that proposal makes sense to me: the split would be between things that *are* known to be subsumed into later versions of C++, and therefore are a compatibility library. What do you think about this as an implementation approach: - Rewrite StringRef (et al) to use the exact same APIs as std::string_view. Keep the StringRef name for now. - When cmake detects that C++’17 mode is supported,

On Mar 15, 2009, at 6:16 PM, Nick Lewycky wrote: > Pierre Habouzit wrote: >> [ please CC: me as I'm not subscribed ] >> >> On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla- >> daemon at cs.uiuc.edu wrote: >>> http://llvm.org/bugs/show_bug.cgi?id=3756 >>> >>> Chris Lattner <clattner at apple.com> changed: >>> >>>

I actually was working on an updated patch for the LLVM-side of this, also. :) I was just working on some test cases; I'll post it soon. It's somewhat different than yours. I haven't touched the clang side yet, but I think it needs to be more complex than what you have there. I think it actually needs to be able to evaluate the intrinsic as a constant _false_ in the front-end in some

Having watched a similar library go through this exact evolution, I really doubt we want to make any split around "things known to be in C++ in the future"... It turns out that this is nearly impossible to predict and precludes a tremendous amount of useful utilities. For example, there is no indication that the range helpers LLVM provides will ever end up in C++'s standard library,

Fair enough, i sort of regret mentioning that specific method of splitting originally. For the record, i think any splitting should make sense on its own merit without considering tablegen, and hopefully the end result of "tablegen eventually depends on less stuff" would happen naturally On Sun, Jun 4, 2017 at 10:37 AM Chris Lattner <clattner at nondot.org> wrote: > > >

On Wed, Jul 5, 2017 at 7:14 PM Sean Silva <chisophugis at gmail.com> wrote: > On Wed, Jul 5, 2017 at 6:46 PM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Having watched a similar library go through this exact evolution, I >> really doubt we want to make any split around "things known to be in C++ in >> the future"...

On Wed, Jul 5, 2017 at 8:14 PM Zachary Turner <zturner at google.com> wrote: > Is there actually a valid use case for using the entire Support library > though? > > One thing that splitting solves is that I can have StringRef and ArrayRef > split up and committed by tomorrow. The same can't be said for the entire > Support library :) > Huh? I'm asking what is