search for: jfbastien

On Thu, Jun 27, 2019 at 5:19 PM JF Bastien <jfbastien at apple.com> wrote: > On Jun 27, 2019, at 5:05 PM, Siva Chandra <sivachandra at google.com> wrote: > On Wed, Jun 26, 2019 at 10:27 AM JF Bastien <jfbastien at apple.com> wrote: > > 3. If there is a specification, we should follow it. The scope that we need includes most...

On Thu, Aug 1, 2019 at 6:38 PM JF Bastien <jfbastien at apple.com> wrote: > > > > > On Aug 1, 2019, at 9:20 AM, Alexander Potapenko <glider at google.com> wrote: > > > > On Thu, Aug 1, 2019 at 6:09 PM JF Bastien <jfbastien at apple.com> wrote: > >> > >> Hi Alexander, > >> > >&...

...et here is unused because it's replaced immediately without reads . So > it can be trimmed. I will try the patch and let you know. > > On Thu, Aug 1, 2019 at 9:51 AM Alexander Potapenko <glider at google.com> > wrote: > >> On Thu, Aug 1, 2019 at 6:38 PM JF Bastien <jfbastien at apple.com> wrote: >> > >> > >> > >> > > On Aug 1, 2019, at 9:20 AM, Alexander Potapenko <glider at google.com> >> wrote: >> > > >> > > On Thu, Aug 1, 2019 at 6:09 PM JF Bastien <jfbastien at apple.com> >> w...

+1, i'm just glad you're making progress on a promising option! On Sat, Dec 28, 2019 at 8:33 PM JF Bastien <jfbastien at apple.com> wrote: > The guy on the phone said that wouldn’t be a problem 🤷‍♂️ > I hope that stays correct! Ideally we’d have the same deal: indeterminate > number of people, ordering off the menu. I’ll check with you if that’s not > the case. > > > On Dec 28, 2019, at 7:...

On Tue, Nov 19, 2019 at 10:46 AM JF Bastien <jfbastien at apple.com> wrote: > And I do agree that if someone were to come in and put in the significant > amounts of work to make LLVM directly usable in security-sensitive places, > then we could support that. But none of that should have anything to do > with the security group or its me...

On Thu, Aug 1, 2019 at 6:09 PM JF Bastien <jfbastien at apple.com> wrote: > > Hi Alexander, > > The code doesn’t compile. Could you send a godbolt.org link that shows the issue? Sorry about that, here's the link: https://godbolt.org/z/-PinQP Lines 4 to 8 are initializing |acpar|. If I'm understanding correctly, the store to 8(...

On Wed, Jun 26, 2019 at 10:27 AM JF Bastien <jfbastien at apple.com> wrote: >> 3. If there is a specification, we should follow it. The scope that we need includes most of the C Standard Library; POSIX additions; and some necessary, system-specific extensions. This does not mean we should (or can) follow the entire specification -- there will...

...an Jose. > > On Sat, Dec 28, 2019, 8:47 PM Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > +1, i'm just glad you're making progress on a promising option! > > On Sat, Dec 28, 2019 at 8:33 PM JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote: > The guy on the phone said that wouldn’t be a problem 🤷‍♂️ > I hope that stays correct! Ideally we’d have the same deal: indeterminate number of people, ordering off the menu. I’ll check with you if that’s not the case. > &g...

On Jul 29, 2019, at 10:58 AM, JF Bastien <jfbastien at apple.com> wrote: >> I think that Rui rolled this out in an incredibly great way with LLD, incorporating a lot of community feedback and discussion, and (as you say) this thread has accumulated many posts and a lot of discussion, so I don’t see the concern about lack of communication. &...

> On Jan 23, 2019, at 4:15 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > If we claim to support a Thing, then we should accept patches to fix when the Thing breaks. Whether a bot verifies that the Thing works, is not really relevant; "support" means "we say this works and will fix it when it breaks." > > A bot is a service to the community in

Hello, Here is one question regarding the LLVM TableGen: Which file in the llvm/lib/Target/X86 folder describes how the bits in the EFLAGS register are modified by the x86 instructions? For example, in the "X86InstrInfo.td" file, lines 2134-2135, it says: let SchedRW = [WriteALU], Defs = [EFLAGS], Uses = [EFLAGS] in { def CLC : I<0xF8, RawFrm, (outs), (ins), "clc",

...llvm.org] On Behalf Of Zachary Turner via llvm-dev Sent: Thursday, May 10, 2018 3:00 PM To: JF Bastien Cc: via llvm-dev Subject: Re: [llvm-dev] Using C++14 code in LLVM Consider me on board with the highest version we can come to an agreement on :) On Thu, May 10, 2018 at 11:50 AM JF Bastien <jfbastien at apple.com<mailto:jfbastien at apple.com>> wrote: On May 10, 2018, at 11:35 AM, Zachary Turner <zturner at google.com<mailto:zturner at google.com>> wrote: If it's the only thing we can agree then I'll take it, but I just worry that 3 years from now we're going...

Consider me on board with the highest version we can come to an agreement on :) On Thu, May 10, 2018 at 11:50 AM JF Bastien <jfbastien at apple.com> wrote: > > On May 10, 2018, at 11:35 AM, Zachary Turner <zturner at google.com> wrote: > > If it's the only thing we can agree then I'll take it, but I just worry > that 3 years from now we're going to start another 3 year discussion, so > that...

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of JF > Bastien via llvm-dev > > I’m not a fan of C and C++ supporting anything but 8 bits per byte. > Realistically, C and C++ on such targets are different languages from 8- > bit-per-byte C and C++, and therefore code isn’t portable from one to the > other. Having done

> On Jun 12, 2019, at 9:38 PM, James Y Knight <jyknight at google.com> wrote: > >  >> On Tue, Jun 11, 2019 at 12:08 PM JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> I think we want option 2.: keep volatile memcpy, and implement it as touching each byte exactly once. That’s unlikely to be particularly useful for every direct-to-hardware

On Thu, May 10, 2018 at 3:06 PM JF Bastien <jfbastien at apple.com> wrote: > On May 10, 2018, at 1:50 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > Last time this came up, there were a lot of people that were stuck on GCC > 4.9 due to ABI reasons. I think forcing that upgrade is going to be the > most disrupti...

> On Feb 7, 2019, at 11:01 AM, paul.robinson at sony.com wrote: > > It seems the CMake changes have landed; but the docs are still a bit out of date? > CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN. > > I’m. Not sure how one updates the website’s docs, I had assumed the RST files would automatically get rebuilt and pushed?

Hi Vishal, Ruijie, Thanks for your interest in the project. To get started, the first task would be to merge the 5 patches on top of trunk llvm. The list of patches are listed in the project description: http://llvm.org/OpenProjects.html#llvm_mergesim Please create an account in llvm phabricator (reviews.llvm.org) if you haven't already, and put your patches there. Let me know if you have

...cts. So I think LLD is maybe also a good candidate to test this? - Raphael > On Jul 30, 2019, at 8:38 AM, Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 30/07/2019 01:57, Chris Lattner via llvm-dev wrote: >> On Jul 29, 2019, at 10:58 AM, JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote: >>>> I think that Rui rolled this out in an incredibly great way with LLD, incorporating a lot of community feedback and discussion, and (as you say) this thread has accumulated many posts and a lot of discussion, so I don’t...

At Microsoft, we believe that we gain a competitive advantage by making the Visual Studio versioning story as complicated as possible. To wit: The compiler in the first VS 2015 release was version 19.00. For each update/hotfix release, we bumped that version by .01. When VS 2017 was released, we decided to keep the major compiler version the same to signify backwards-binary-compatibility with the