search for: jdenni

Hi, Is it intended that llvmc should search PATH for llc? For example, this means that llvmc 2.7 can invoke llc 2.8: % echo $PATH /home/jdenny/installs/llvm/2.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games % /home/jdenny/installs/llvm/2.7/bin/llvmc test.ll llc: Unknown command line argument '-f'. Try: 'llc -help' % strace -f

On Wed, May 16, 2018 at 12:24 PM, <paul.robinson at sony.com> wrote: > > > > -----Original Message----- > > From: Justin Bogner [mailto:justin at justinbogner.com] On Behalf Of Justin > > Bogner > > Sent: Wednesday, May 16, 2018 12:16 PM > > To: llvm-dev > > Cc: jdenny.ornl at gmail.com; Robinson, Paul > > Subject: Re: [llvm-dev] RFC:

On Wed, May 16, 2018 at 12:38 PM, Joel E. Denny <jdenny.ornl at gmail.com> wrote: > On Wed, May 16, 2018 at 12:24 PM, <paul.robinson at sony.com> wrote: > >> >> >> > -----Original Message----- >> > From: Justin Bogner [mailto:justin at justinbogner.com] On Behalf Of >> Justin >> > Bogner >> > Sent: Wednesday, May 16, 2018

> I don't know how you proceed to debug FileCheck failures, but for me most of the time I'll have to figure out which "RUN" line fail and try to execute it manually and then remove the FileCheck pipe to get the raw input and then painfully tried to match the FileCheck error to the actual input. Yeah, not very different from what you described here. If I 'm creating or

Hi, Joel E. Denny <jdenny <at> etinternational.com> writes: > > Hi, > > Is it intended that llvmc should search PATH for llc? For example, this > means that llvmc 2.7 can invoke llc 2.8: > [...] This is fixed in 2.8+ - llvmc now searches the directory it resides in first.

Hi Mikhail, On Thu, 28 Oct 2010, Mikhail Glushenkov wrote: > Joel E. Denny <jdenny <at> etinternational.com> writes: > > Is it intended that llvmc should search PATH for llc? For example, this > > means that llvmc 2.7 can invoke llc 2.8: > > [...] > > This is fixed in 2.8+ - llvmc now searches the directory it resides in first. I just built r117553 from

Sorry if I wasn't clear about my use case. In my daily dev work, I do many local "ninja check"s, or "llvm-lit" on a subdirectory as a quick(er) smoke test if I am making changes in that area (e.g. "llvm-lit ../llvm/test/CodeGen"). Nothing wrong here, as indeed nothing changed here. But in case of a test failure, I want to run just that test: bin/llvm-lit

...: > I was curious to know if you had any luck in getting openssh's sftp > server properly configured to allow chrooted sftp logins? I have had > no success and need something quickly. Dear Mike, Unfortunately, I did not succeed to have it work. I got in contact with James Dennis <jdennis at law.harvard.edu>, who send me a chroot patch. I applied the patch and did not succeed to log into a chrooted account. The patch is quite simple. I don't understand why it does not work. Any idea? Best regards, Jean-Michel

On Thu, Jun 18, 2020 at 3:37 PM Chris Tetreault <ctetreau at quicinc.com> wrote: > We’re talking about verbose output right? Verbose isn’t the default. > I'm fairly certain the issue in this thread is just the verbosity of -dump-input=fail. Yes, -vv makes it even more verbose by annotating input lines with good matches, etc., but that's not part of the "new

> -----Original Message----- > From: Justin Bogner [mailto:justin at justinbogner.com] On Behalf Of Justin > Bogner > Sent: Wednesday, May 16, 2018 12:16 PM > To: llvm-dev > Cc: jdenny.ornl at gmail.com; Robinson, Paul > Subject: Re: [llvm-dev] RFC: [FileCheck] CHECK-DAG for multiple > occurrences of string > > Paul Robinson <paul.robinson at sony.com> writes:

Paul Robinson <paul.robinson at sony.com> writes: >> From: Joel E. Denny [mailto:jdenny.ornl at gmail.com] >>> On Mon, May 7, 2018 at 12:56 PM, <paul.robinson at sony.com> wrote: >>>> 1. In a CHECK-DAG group, don't let the matches for patterns overlap. >>>> 2. Add a new CHECK-DAG-N directive, where N is some integer, to express

Hi, Given this LLVM assembly: @a = global i8* getelementptr (i8* null, i64 mul (i64 ptrtoint (i32* getelementptr (i32* null, i32 1) to i64), i64 2)) llc fails an assertion: llc: /home/jdenny/llvm-svn/include/llvm/Support/Casting.h:202: typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X = llvm::ConstantInt, Y = llvm::Value*]: Assertion `isa<X>(Val)

Hi Nick, On Tue, 26 Oct 2010, Nick Lewycky wrote: > Joel E. Denny wrote: > > Given this LLVM assembly: > > > > @a = global i8* getelementptr (i8* null, i64 mul (i64 ptrtoint (i32* > > getelementptr (i32* null, i32 1) to i64), i64 2)) > > > > llc fails an assertion: > > > > llc: /home/jdenny/llvm-svn/include/llvm/Support/Casting.h:202:

"Joel E. Denny" <jdenny at etinternational.com> writes: > The LLVM headers llvm-c/Target.h and llvm/Target/TargetSelect.h include > the header llvm/Config/config.h, which defines common macros, such as > PACKAGE_BUGREPORT. If a project that uses LLVM includes any of these > headers, the project's own macros of the same names can be redefined. > > Most

Hi, The LLVM headers llvm-c/Target.h and llvm/Target/TargetSelect.h include the header llvm/Config/config.h, which defines common macros, such as PACKAGE_BUGREPORT. If a project that uses LLVM includes any of these headers, the project's own macros of the same names can be redefined. Most advice I have seen says that installed headers should never define such common macros. Thus, an

On Thu, Oct 28, 2010 at 3:47 PM, Joel E. Denny <jdenny at etinternational.com> wrote: > For example, for my platform, llc folds the add but not the getelementptr > in: > >  @a = global i8* getelementptr (i8* null, i64 add (i64 3, i64 2)) This gets folded when it's read in; there's no other way to represent a constant 'i64 add (i64 3, i64 2)' in LLVM than 'i64

Joel E. Denny wrote: > Hi, > > Given this LLVM assembly: > > @a = global i8* getelementptr (i8* null, i64 mul (i64 ptrtoint (i32* getelementptr (i32* null, i32 1) to i64), i64 2)) > > llc fails an assertion: > > llc: /home/jdenny/llvm-svn/include/llvm/Support/Casting.h:202: typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =

As for the ordering issue... from the command line, I tend to set verbosity high, and so I pipe to a pager and search for "error:". I prefer errors before the input dump then. My point is that it should be configurable if we change the default ordering. Joel On Thu, Jun 18, 2020 at 1:13 PM Joel E. Denny <jdenny.ornl at gmail.com> wrote: > Thanks for bringing this discussion

I just stumbled across r332416, which was modifying a test with multiple identical CHECK-DAG directives, which reminded me I needed to get back to you about this... sorry for the slow response. > From: Joel E. Denny [mailto:jdenny.ornl at gmail.com] >> On Mon, May 7, 2018 at 12:56 PM, <paul.robinson at sony.com> wrote: >>> 1. In a CHECK-DAG group, don't let the matches

Right now, the tests try to accomplish the following 1. Define a sequence of instructions (e.g a,b,c) 2. Insert that sequence into k places with an unique instruction between them to make sure the outliner will yank them out *without overlaps* 3. Check for k calls to an outlined function 4. Check that the outlined sequence still exists in the program This can result in some pretty long tests