similar to: DWARF debug info unit tests: Tests for wrong triple?

On Wed, Mar 20, 2019 at 7:29 PM Eric Christopher <echristo at gmail.com> wrote: > Adding in aprantl here to make sure he's aware. > > Making sure I understand - you're building a compiler on machine a > that llvm doesn't support code generation to and running the llvm > tests on that platform? > Yes, or rather the support is in-progress, but the host platform

On Thu, Jan 23, 2020 at 11:37 AM David Greene <greened at obbligato.org> wrote: > Hubert Tong <hubert.reinterpretcast at gmail.com> writes: > > >> I read this as the refresh being an entirely new GitHub PR. Is that > >> right? Normally I would expect the same PR to be used but the rebase > >> would cause a force-push of the branch which would update

On Wed, Jan 22, 2020 at 4:40 PM David Greene <greened at obbligato.org> wrote: > Hubert Tong <hubert.reinterpretcast at gmail.com> writes: > > > The update process in Phab in rather manual and it does lead to more > noise. > > The GitHub force push risks loss of context for earlier comments (not > just > > in terms of display, like viewing older comments

Sorry - I misread your example and the problem. I see now where LibCallSimplifier creates the select...but we are immediately erasing that select with the code from the godbolt example. Does the real motivating case have no uses of the pow() result value? On Mon, Sep 14, 2020 at 1:03 PM Sanjay Patel <spatel at rotateright.com> wrote: > Yes, I mean just bail out on the transform in >

Hubert Tong <hubert.reinterpretcast at gmail.com> wrote on 10.06.2020 23:51:54: > From: Hubert Tong <hubert.reinterpretcast at gmail.com> > To: Kai Peter Nacke <kai.nacke at de.ibm.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Date: 10.06.2020 23:52 > Subject: [EXTERNAL] Re: [llvm-dev] RFC: Adding support for the z/OS > platform to LLVM and clang

> > Okay, it's just not immediately undefined behaviour. The C model has more > issues because of the problem with how "trap representation" is defined > (which precludes trap representations for unsigned char, two's complement > signed char, etc.). This interpretation is further stressed because C only explicitly ascribes > undefined behaviour to trap

Hello, as discussed here in more detail: https://reviews.llvm.org/D81583 the introduction of the C++20 [[no_unique_address]] attribute exposes an ABI issue on platforms that require special handling for structs/classes that are "equivalent" to a single floating-point member (or in some cases, a "homogeneous" set of floating-point members). This is because we can now for the

On Mon, Sep 14, 2020 at 12:45 PM Sanjay Patel <spatel at rotateright.com> wrote: > Yes, that looks like a bug. The transform is ok in general for negative > numbers, but -Inf is a special-case for pow(), right? > If so, we probably need an extra check of the input with > "isKnownNeverInfinity()". > There is an extra check there already, but it uses

On Sun, 13 Sep 2020 at 15:51, Hubert Tong <hubert.reinterpretcast at gmail.com> wrote: > If you mean "amend" the message in the Web UI before merging, then yes, >> they let you change the message, but it's very easy to forget to do >> that. > > That's what I meant, yes. "Easy to forget" generally goes away when you repeat it enough times.

> > // Members are initialized to poison at object creation. >> p = alloca {i8, i32} // p[0], p[4~7] are poison >> p[0] is an i8, so it shouldn't be poison? > > My interpretation of standard is that reading uninitialized char can also yield trap representation. If uninitialized, char variable has indeterminate value, and C/C++ does not seem to forbid reading trap

Just to clarify: All the LLVM incubator repositories have "enforce linear history" enabled. Neither "Squash and Merge" or "Rebase and Merge" results in a Merge commit in the git history. Steve On Fri, Sep 11, 2020 at 3:32 PM Hubert Tong < hubert.reinterpretcast at gmail.com> wrote: > On Fri, Sep 11, 2020 at 6:12 PM Renato Golin <rengolin at

On Thu, Jan 16, 2020 at 1:17 PM David Greene <greened at obbligato.org> wrote: > Hubert Tong <hubert.reinterpretcast at gmail.com> writes: > > >> I can see how having multiple patches up at once for review might speed > >> things up. But what if a very first patch in a series needs major > >> changes and that affects every single following patch? The

On Wed, Jan 22, 2020 at 5:19 PM David Greene <greened at obbligato.org> wrote: > Hubert Tong <hubert.reinterpretcast at gmail.com> writes: > > > It was already mentioned earlier in the thread that: > > - The individual commits cannot be approved in the sense of approving a > PR. > > Later conversation makes me wonder how often that really happens though.

On Thu, Jan 17, 2019 at 6:51 PM Hubert Tong < hubert.reinterpretcast at gmail.com> wrote: > I'm wondering if this would wreak havoc upon semi-case-sensitive systems > like Windows. I'd like to hear from people who use Git and SVN on Windows. > FWIW, I will of course not do this in any case where there might be a collision due to such file systems. I don't think there

It is UB when a poison is passed to certain operations that raise UB on poison, such as division by poison/dereferencing poison pointer/branching on poison condition/etc. Otherwise, poison is simply propagated, but it does not raise UB Copying poison bytes is okay: // Members are initialized to poison at object creation. p = alloca {i8, i32} // p[0], p[4~7] are poison q = alloca {i8, i32} // we

On Fri, Nov 25, 2016 at 1:42 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > What is the purpose of the union there? > The purpose of the union is to increase portability by ensuring that the placement new is not being performed on insufficiently sized or aligned memory. > I ask because pretty much no compiler will respecting the unioning without > visible accesses in all

On Fri, 11 Sep 2020 at 19:32, Hubert Tong via llvm-dev < llvm-dev at lists.llvm.org> wrote: > There seems to be a split between those who prefer to curate commits >> locally and present them in the PR (i.e. Method 3) as they are to be >> committed (i.e. squash/amend/etc from my workstation and push the result), >> and those who seem to feel that it is better to avoid

On Thu, Jan 23, 2020 at 9:30 AM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hubert, thank you so much for the detailed bisection of what I believe > is the most > problematic GitHub PR =<= Phab difference in terms of review process! > This thread has been focused on a specific aspect of the tooling / process, the thread we had two months ago mentioned

I am seeing only one log entry for such error, so I wondering if this is transient. Does it still fail with retry? - Eric On Fri, Nov 4, 2016 at 6:30 AM Hubert Tong via llvm-dev < llvm-dev at lists.llvm.org> wrote: I'm getting the same error. -- HT On Fri, Nov 4, 2016 at 8:24 AM, Nemanja Ivanovic via llvm-dev < llvm-dev at lists.llvm.org> wrote: It appears that Phabricator is

I am able to do an svn checkout, but commits fail even before I'm asked for authentication. svn: E175002: Commit failed (details follow): svn: E175002: Server sent unexpected return value (400 Bad Request) in response to MKACTIVITY request for '/svn/llvm-project/!svn/act/ef968a87-16e6-4ff1-807a-7f7f88609c97' Is this a server issue? -- HT -------------- next part -------------- An