similar to: [LLVMdev] Advice to API inconsistency between different versions

Hello all, I am writing test cases which are dedicated to be executed by llvm-lit. Most of my test cases have the same logic but different types. For example: // RUN: %clang_cc1 -fsyntax-only func (int a) { a = 3; } // RUN: %clang_cc1 -fsyntax-only func (char a) { a = 3; } // RUN: %clang_cc1 -fsyntax-only func (unsigned a) { a = 3; } Now I put them in three different test cases but it

Hi - Not sure if anyone else saw this or cares about a decompiler (not personally tested) https://github.com/draperlaboratory/fracture I wonder if they have been in contact with anyone in the community in getting this upstreamed. Does it look interesting to anyone else? (thoughts/random comments/feedback)

On Thu, Apr 3, 2014 at 11:50 AM, Jevin Sweval <jevinsweval at gmail.com> wrote: > On Wed, Apr 2, 2014 at 1:57 AM, "C. Bergström" <cbergstrom at pathscale.com> wrote: >> Hi - >> >> Not sure if anyone else saw this or cares about a decompiler (not personally >> tested) >> https://github.com/draperlaboratory/fracture >> >> I wonder if

Dear all, I use the clang frontend to produce the control flow graph of a C program through this command: clang -Xclang -analyze -Xclang -analyzer-checker=debug.DumpCFG test.c The produced information contains all the basic blocks identified by labels, e.g. B1, B2, etc. along with their predecessors and successors. Is there a way to get the starting address of each of these basic block? I would

Hello everyone, I want to decide whether a function is executed or not. For example (the value of cond is not determined at compile time): br i1 %cond, label %if, label %else if: ... call void f() ... br label %exit else: ... br label %exit We could say that function f is control dependent on cond and may not be executed. On the other hand: br i1 %cond, label %if, label %else

The only VHDL to LLVM project that I know of is nvc. [0] I haven't tried it personally and from a cursory look through the source it seems like there is a LLVM backend and a "native" backend (not sure what that means). If you're really crazy you might want to see if you could massage GHDL [1] (VHDL GCC frontend) + DragonEgg [2] (LLVM backend for GCC) to get you LLVM IR. I'm

On Wed, Jul 17, 2013 at 9:06 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > To maintain the semantics of ordinary function calls, the prefix data > must have a particular format. Specifically, it must begin with a > sequence of bytes which decode to a sequence of machine instructions, > valid for the module's target, which transfer control to the point >

As much as I like this idea for it's use in languages with type systems like Haskell and Scheme, this proposal would limit LLVM to non-Harvard architectures. That's generally a really small minority of all processors, but it would mean there could never be a clang-avr. An alternative you could use is, instead of using the function pointer as the variable where you are referring to a

On Mar 28, 2014, at 3:32 PM, Bob Wilson <bob.wilson at apple.com> wrote: > There are new conflicts several times a day, on average. I rebased them on Wednesday on top of svn 204791. If you want to try them out, it would be best to roll back to that revision. > > I’ll rebase them one more time when we commit them, but it’s such a moving target (and takes a fair bit of work), that

Hi, I would like to propose that we introduce a mechanism in IR to allow arbitrary data to be stashed before a function body. The purpose of this would be to allow additional data about a function to be looked up via a function pointer. Two use cases come to mind: 1) We'd like to be able to use UBSan to check that the type of the function pointer of an indirect function call matches the

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/asm/bitops.h#L68 Here is one example that I found. Are the inline assembly arguments ambiguous in size? -Jevin Sent from my mobile device. Typos are par for the course. On Jul 10, 2013, at 5:47 PM, Jim Grosbach <grosbach at apple.com> wrote: On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at

Hello LLVMer, I use dragonegg to generate LLVM bitcode. Then I use LLVM interpreter to execute what I get from compilation. However an error occurred and the error message is: "LLVM ERROR: Code generator does not support intrinsic function 'llvm.objectsize.i64'!." As far as I know, objectsize intrinsic is equivalent to gcc built-in function __builtin_object_size. But I don't

On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at gmail.com> wrote: > On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> Jim Grosbach wrote: >>> To say that another way, is the assembler correctly diagnosing a previously >>> unnoticed problem in the project source code, or is the assembler not >>>

[this time compeled the mail]. The autogen.sh of opusfile doesn't work for me: Updating build configuration files for opusfile, please wait.... configure.ac:8: installing `./install-sh' configure.ac:8: installing `./missing' Makefile.am:10: Libtool library used but `LIBTOOL' is undefined Makefile.am:10: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'

hi everyone! i know it's a little off-topic here, but can somebody with svn commit access please consider this: --- vorbis-tools/configure.in~ 2005-04-07 20:28:23.460547245 +0200 +++ vorbis-tools/configure.in 2005-04-07 20:28:23.460547245 +0200 @@ -161,7 +161,7 @@ AC_MSG_WARN(libspeex missing) have_libspeex=no, [$SPEEX_LIBS] ) -AC_CHECK_HEADER(speex.h,,

On 20 May 2014 16:08, RICHARD STUCKEY <richard.stuckey at virgin.net> wrote: > Consider a function which contains an infinite loop: any algorithm which > could determine whether that function is called or not would effectively be > an algorithm that could determine whether the program containing that > function halts or not. Equally, deciding whether the function contains an

Hi Reid, Thanks for the reply. Comments inline below. Regards, Eric On 9/29/14, 5:51 PM, Reid Kleckner wrote: > I think any port will involve some changes, but it's really hard to > say which porting approach will be the least painless beforehand. > Aside from _MSC_VER incompatibilities messing up portability headers, > I think any changes you make to support clang on Windows

<snip> > @@ -3157,19 +3155,18 @@ LIBSELINUX="" > AC_ARG_WITH(selinux, > [ --with-selinux Enable SELinux support], > [ if test "x$withval" != "xno" ; then > + save_LIBS="$LIBS" > AC_DEFINE(WITH_SELINUX,1,[Define if you want SELinux support.]) > SELINUX_MSG="yes" > AC_CHECK_HEADER([selinux/selinux.h],

Tomas Janousek <tjanouse at redhat.com> wrote in news:20070413132731.GA8281 @redhat.com: > - SQL_LIBS="$SQL_LIBS -lsqlite3 -lz" > + SQLITE_LIBS="$SQLITE_LIBS -lsqlite3 -lz" Hi, this patch fixes a build error during cross compilation to a system without the libz target package: --- dovecot-2.2.15.org/configure.ac 2014-10-25

configure.in patches for 2.9.9p2: 1. Allow --with-pcre to take a path specifying the root of the PCRE install (ROOT/include, ROOT/lib) 2. Ditto for --with-zlib 3. $no_libnsl and $no_libsocket can be determined programmatically 4. Check for innetgr, getspnam, and util in the default $LIBS before checking in -lrpc, -lgen, and -lutil, respectively 5. dirname() is in -lgen on some