search for: znu

...nst A a{}; > void m(B &&other) { > a = std::move(other.a); > } > }; > > int main() { > B b1, b2; > b2.m(std::move(b1)); > } > > Best wishes, > Vit > > <log.txt> > >> 29 марта 2018 г., в 7:06, David Zarzycki <dave at znu.io <mailto:dave at znu.io>> написал(а): >> >> Can you be more specific? What version of clang are you using to build LLVM? And what exactly is the error that you’re seeing? >> >>> On Mar 28, 2018, at 23:38, vit9696 via llvm-dev <llvm-dev at lists.llvm.org &l...

Hello, May I ask anyone responsible to either fix or revert r326109 and r326110, which effectively broke LLVM compilation with clang? Str is const now (https://reviews.llvm.org/D43436#C985082NL45 <https://reviews.llvm.org/D43436#C985082NL45>), and later on a move constructor on const is performed (https://reviews.llvm.org/D43436#C985082NL64

...9 20:33 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com <mailto:david.bolvansky at gmail.com>>: > I did > > https://bugs.llvm.org/show_bug.cgi?id=37368 <https://bugs.llvm.org/show_bug.cgi?id=37368> > > 2018-05-09 20:29 GMT+02:00 David Zarzycki <dave at znu.io <mailto:dave at znu.io>>: > I’d wager that the if-else chain is being converted to a "switch statement” during an optimization pass and the __builtin_expect() hint is lost. Can you file a bug? https://bugs.llvm.org <https://bugs.llvm.org/> > > >> On May 9, 20...

I did https://bugs.llvm.org/show_bug.cgi?id=37368 2018-05-09 20:33 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > I did > > https://bugs.llvm.org/show_bug.cgi?id=37368 > > 2018-05-09 20:29 GMT+02:00 David Zarzycki <dave at znu.io>: > >> I’d wager that the if-else chain is being converted to a "switch >> statement” during an optimization pass and the __builtin_expect() hint is >> lost. Can you file a bug? https://bugs.llvm.org >> >> >> On May 9, 2018, at 1:57 PM, Dávid Bolvan...

...com> wrote: > >  > The x86 backend is extremely aggressive in turning cmov with memory operands into branches because that is often faster even for poorly predicted branches due to the forced stall in the cmov. > >> On Fri, Sep 13, 2019 at 11:19 PM David Zarzycki <dave at znu.io> wrote: >> I’m struggling to find cases where __builtin_unpredictable() works at all. Even if we ignore cmp/br into switch conversion, it still doesn’t work: >> >> int test_cmov(int left, int right, int *alt) { >> return __builtin_unpredictable(left < right...

Hello, #define likely(x) __builtin_expect((x),1) // switch like char * b(int e) { if (likely(e == 0)) return "0"; else if (e == 1) return "1"; else return "f"; } GCC correctly prefers the first case: b(int): mov eax, OFFSET FLAT:.LC0 test edi, edi jne .L7 ret But Clang seems to ignore _builtin_expect hints in this case.

Thanks, interesting. But a fix needs to be made since branch predictor hints are broken in a valid C++20 code: https://godbolt.org/g/dpSDqd Dňa st 9. 5. 2018, 20:40 David Zarzycki <dave at znu.io> napísal(a): > Hi Dávid, > > Looks like you can defeat the switch conversion by adding a dummy asm(“”): > > #define likely(x) __builtin_expect((x),1) > > // switch like > char * b(int e) { > if (likely(e == 0)) > return "0"; >...

I’m struggling to find cases where __builtin_unpredictable() works at all. Even if we ignore cmp/br into switch conversion, it still doesn’t work: int test_cmov(int left, int right, int *alt) { return __builtin_unpredictable(left < right) ? *alt : 999; } Should generate: test_cmov: movl $999, %eax cmpl %esi, %edi cmovll (%rdx), %eax retq But currently generates: test_cmov: movl $999,

Hi James, Non-Apple people can’t “see radar”. Do you work at Apple? In either case, the clang development email list would be the right start for this. Also, if you work at Apple, please consider reaching out to the DevTools department directly. Dave > On Mar 19, 2018, at 12:21, James Gregurich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > hi. > > Is there interest

hi. Is there interest in enhancing the objc++ compiler to make objc mechanisms friendly to the newer features of c++? For instance... 1) making blocks movable so that they can capture things like unique_ptr<> and still be moved off the stack 2) making @property declarations work with move-only types like unique_ptr<> 3) enabling std::weak_ptr<> to weakly store an objc pointer

Can you be more specific? What version of clang are you using to build LLVM? And what exactly is the error that you’re seeing? > On Mar 28, 2018, at 23:38, vit9696 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > May I ask anyone responsible to either fix or revert r326109 and r326110, which effectively broke LLVM compilation with clang? > > Str is

The title says it all. I get this every time I try to clone the repo. I don't know how to get past it...I'm not even sure what it's complaining about... $ git clone https://github.com/llvm/llvm-project.git Cloning into 'llvm-project'... remote: Enumerating objects: 2558, done. remote: Counting objects: 100% (2558/2558), done. remote: Compressing objects: 100% (90/90),

...fail as the valid range // of signed 3-bit values is [-4:3] The above code does not currently fail and instead fails for pip.setInt arguments with values in [-4:-1] which is actually unexpected and the reason I started this email thread. /Riyaz From: David Zarzycki [mailto:dave at znu.io] Sent: Wednesday, April 4, 2018 11:47 AM To: Reid Kleckner <rnk at google.com> Cc: David Blaikie <dblaikie at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; Riyaz.Puthiyapurayil at synopsys.com; nd <nd at arm.com> Subject: Re: [llvm-dev] llvm::PointerIntPair -- is thi...

How is -mmacosx-version-min=10.9 being set? LLVM_COMPILE_FLAGS? Or CMAKE_CXX_COMPILE? > On May 2, 2018, at 19:22, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I described this off-list to Zac, but for anyone else who is following, simply specifying the target triple is not enough to have the build system set an older macOS deployment target. I.e the 6.0.0-rc1

As first discussed in the giant "New LLVM git repository conversion prototype" thread, I've pushed a git tag that allows git-describe to be used for generating human readable commit names on master. The tag is "llvmorg-10-init", to be interpreted as "the initial commit with major version number 10". The idea is to add similar tags along with future version bumps.

...le mode 100644 index 0000000000000000000000000000000000000000..1385ccc0303c5a3819822b3140181c456310ac25 GIT binary patch literal 174 zcmeAS at N?(olHy`uVBq!ia0vp^Ahs3<6Od&66MF|pNtU=qlmzFem6RtIr7}3C<R_&n zc;+Uirv{}arc at T5Otk?j3h;Ds45_$vX0jn4g8~P$=EMK<OADR;Hk4*?Y>Hdwz#(D$ zHg03j)ZnU|RqjQ5;vNcAd3R at 8F!b%roz#2kV%FPZ1=HWXePO*qB<>fR{A1k%47=?4 VI-QIdgn?!=c)I$ztaD0e0s!hTJX8Px literal 0 HcmV?d00001 diff --git a/src/public/stylesheets/cloud/layout.css b/src/public/stylesheets/cloud/layout.css index 60b5c91..d40b4ab 100644 --- a/src/public/stylesheets/cloud/layout.css +++ b/s...

I described this off-list to Zac, but for anyone else who is following, simply specifying the target triple is not enough to have the build system set an older macOS deployment target. I.e the 6.0.0-rc1 binaries I've just uploaded have the same deployment target problem. Looking at the 5.0.0 and 6.0.0-rc1 binaries, I can confirm that their deployment target was too new: Load command 9

The sign extension is correct. Otherwise setInt(-1) won’t work. If you don’t want sign extension, then use ‘unsigned’ and not ‘int’ in the template arguments. > On Apr 4, 2018, at 14:34, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'd argue that bitfield sign extensions are surprising and are usually a source of bugs. It would be much more explicit and

> On Apr 30, 2018, at 15:05, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On Apr 30, 2018, at 2:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: >> On Mon, Apr 30, 2018 at 11:14 AM, John McCall <rjmccall at apple.com> wrote: >>> The LLVM address space design has pushed well beyond the sensible boundaries >>> of

> On Apr 30, 2018, at 2:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > On Mon, Apr 30, 2018 at 11:14 AM, John McCall <rjmccall at apple.com> wrote: >> The LLVM address space design has pushed well beyond the sensible boundaries >> of less-is-more and really needs some concerted effort to actually define the expected >> properties of different