similar to: [LLVMdev] llvm/Config/config.h namespace problem

"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, 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

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

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:

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

On 23 November 2017 at 15:05, Santosh wrote: | I am trying to install 'rgl' package in Ubuntu.. Would highly appreciate | your assistance .. I tried several leads available on various discussion | fora and nothing helped so far. Install the _pre-built binary package_ via sudo apt install r-cran-rgl Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

On Wed, 2011-09-14 at 12:24 +0000, Charles Lepple wrote: > Author: clepple-guest > Date: Wed Sep 14 12:24:58 2011 > New Revision: 3225 > URL: http://trac.networkupstools.org/projects/nut/changeset/3225 > > Log: > Silence redefined PACKAGE_ macro warnings > > This should be fixed properly upstream, but in the mean time, the SNMP-based > tools can't use these

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:

Hi All, Duncan, Rolf, Ista, DIrk, Thanks for the suggestions and I tried all of them (as suggested by Duncan, Rolf, Ista and Dirk)... I still get similar error as before while installing 'rgl' package.. I also tried to manually configure "rgl" and got an error message (please see below for the verbatim output). Would highly any further ideas/suggestions! *In my system,

Hi Duncan, and others.. Yes, below are the search results. it is linked to mesa/libGL.so and is again point to libGL.so -> libGL.so.1.2.0 . However, I could not find libGL.so.1.2.0 or its source. Where is libGL.so.1.2.0 expected to be located? /usr/lib/libGL.so.1 /usr/lib/x86_64-linux-gnu/libGL.so /usr/lib/x86_64-linux-gnu/libGL.so.1 /usr/lib/x86_64-linux-gnu/mesa/libGL.so Thanks again,

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

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 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

On 24/11/2017 2:30 PM, Santosh wrote: > Hi All, Duncan, Rolf, Ista, DIrk, > > Thanks for the suggestions and I tried all of them (as suggested by Duncan, > Rolf, Ista and Dirk)... I still get similar error as before while > installing 'rgl' package.. I also tried to manually configure "rgl" and got > an error message (please see below for the verbatim output).

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

On 24/11/2017 5:24 PM, Santosh wrote: > Hi Duncan, and others.. > > Yes, below are the search results. it is linked to mesa/libGL.so and is > again point to libGL.so -> libGL.so.1.2.0?. However, I could not find > libGL.so.1.2.0 or its source. Where is libGL.so.1.2.0 expected to be > located? Mine was in /usr/lib/x86_64-linux-gnu/mesa/. Duncan Murdoch > > >

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

Dear all, I am developing a package, which bundles my most frequently used functions. One of those is a modified version of droplevels from the base package (basically, it preserves any contrast function which was used to create the factor, contrast matrices are not kept, for they could be wrong if a level is dropped). In my NAMESPACE file I've the following directives, which should export

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)