similar to: Not getting bug email

Thanks. I have gone that route and there was no response. What constitutes 'particularly urgent'? In regards to D30107<https://reviews.llvm.org/D30107> it some fairly obvious defect(s) and there are a few bugs open in your database about the issue, but it seems an area that doesn't get much interest (related to DynamicLibrary class). Thanks again.

Ughs, I'm not dying to wait months...but if it thats the way it is, then its the way it is. Tends to be so many commits in a day it seemed it was being lost in the noise/clique. I did try to add some notes to the bug tracker, but new logins are disabled, and the email to get one never replied...but I guess that's another topic! Thanks again, definitely alleviated some frustrations.

That's odd... Have the branch created as usual? On Fri, Jan 13, 2017 at 9:28 AM, Hans Wennborg <hans at chromium.org> wrote: > Oh wait, the branch on the git mirror doesn't look right! > > Anton, can you take a look? The first commit on the branch for llvm is: > > ------------------------------------------------------------------------ > r291843 | hans | 2017-01-12

On Fri, Jan 31, 2020 at 6:09 AM Robinson, Paul via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > > > -----Original Message----- > > From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of John > Marshall > > via cfe-dev > > Sent: Friday, January 31, 2020 7:04 AM > > To: Jonas Devlieghere via cfe-dev <cfe-dev at lists.llvm.org> >

Around 3:30am Pacific (so ~7 hours ago) I got a brief flurry of emails from jetbrains.com, apparently related to llvm.org bugzillas, anybody know what that was about? Thanks, --paulr

> On Feb 2, 2017, at 8:20 AM, David Blaikie <dblaikie at gmail.com> wrote: > > The goal/intent is that debug info does not affect code generation. There are (many?) bugs. I think Apple folks (cc'd Adrian) may be looking at this a bit recently, not sure. > > The fixes aren't usually too invasive (usually involve something counting instructions where it needs to skip

I'd like to (re)start a discussion on a few gotchas in FileCheck that I've noticed working on various tests in llvm's suites. This begain in a review [1], but I'll try to summarize here so it gets the right audience before decisions are made on it (so to speak). 1: https://reviews.llvm.org/D77227 The main sticking point is the abundance of checks in FileCheck tests that appear to

The term "target" is somewhat overloaded. When llvm-config tells you it was built with the X86 target, that actually includes a variety of closely related architectures, such as x86_64, i386, and so on. Within the x86_64 architecture, there are many individual processor implementations that LLVM understands, such as Skylake, Bulldozer, and many many more. What *clang* means by

Thanks, Galina. It doesn't explain why the test worked on some bots but not this one, but Justin's workaround is okay with me. --paulr From: Galina Kistanova [mailto:gkistanova at gmail.com] Sent: Thursday, November 09, 2017 10:09 AM To: Robinson, Paul Cc: Davide Italiano; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Problem with 'sed' on one Windows bot? There is nothing

I'm not familiar with the target instruction set, but if "MOV PC, R0" is not a return instruction, I'm guessing that the sequence starting at A39C is a dispatch through a jump table. The jump table would be considered part of the instruction stream and included in the scope of the line table. This is not a case where you would see end_sequence; my mistake. The line table does

(resend to the list) And of course, just as I say that, my next ninja build shows the line only once. On reflection I am less sure that the lack of a [N/M] line means they are from the same invocation. Surely ninja could spawn two links, which then independently report "Creating library" after ninja emits the [N/M] lines. --paulr From: llvm-dev [mailto:llvm-dev-bounces at

There should be a line-table entry for the end of the function, which appears to be missing from the dump you provided. llvm-dwarfdump should report this address with 'end_sequence' in the Flags. Are you using a different dumper? I am not sure but my guess would be that inline data is not represented in the line table. The line table's primary purpose is to inform the debugger

Hello All, I have converted c program into assembly code for alpha target using following commands clang -emit-llvm matrix.c -c -o matrix.bc llc -march=alpha matrix.bc -o matrix.s Now how to convert matrix.s assembly file into executable file of alpha target? Any help is appreciated Thanks in advance !! Thanks, Bala -------------- next part -------------- An HTML attachment was scrubbed...

As Davide suggests, most likely it's a bot software installation snafu. But the simpler sed script works perfectly, and I'll do that for now. I had understood that LLVM expected people to install GnuWin32, but maybe it's not sufficiently well specified about versions and whatnot. --paulr > -----Original Message----- > From: davide.italiano at gmail.com [mailto:davide.italiano

I've verified that none of the files I tried to check in had Windows-style line endings. It's something else. --paulr From: vsk at apple.com [mailto:vsk at apple.com] On Behalf Of Vedant Kumar Sent: Thursday, November 22, 2018 9:38 AM To: Robinson, Paul Cc: zturner at google.com; jyknight at google.com; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] 'git llvm push' not working

Since there's no "[2663/3121] " line between the two messages, the two lines are from the same link.exe invocation. I don't know why link.exe thinks it needs to print this line twice, ninja doesn't have anything to do with it. On Mon, Nov 19, 2018 at 6:57 PM <paul.robinson at sony.com> wrote: > I'm more concerned about seeing the message come out twice, which

Currently the LLVMbugs list only receives emails when a new bug is filed or an existing bug gets finally resolved. The gcc-bugs list on the other hand receives an email for every new comment in bugzilla. This leads to much better transparency, because you can easily see which bugs are currently being worked on; while the current LLVMbugs setup left you totally in the dark. So my suggestion would

On Wed, Apr 22, 2020 at 10:34 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Apr 22, 2020 at 9:28 AM Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: >> > >> > >> > >> > > -----Original Message-----

The bot has been failing its CMake step for a while now. Probably fallout from renaming Msf to MSF. Can somebody get this straightened out? It's one of the bots that run VS2013 AFAICT which makes it useful to me. Thanks, --paulr

It's worth remembering that there are two syntactically similar but semantically different kinds of "expression" in DWARF. A DWARF expression computes a value; if the available value is a pointer, you add DW_OP_deref to express the pointed-to value. A DWARF location expression computes a location, and adds various operators to express locations that a (value) expression cannot, such