similar to: [LLVMdev] about llvm2.7's inline assembly

Hello, I get this error when compiling this code with llvm-gcc: error: unsupported inline asm: input constraint with a matching output constraint of incompatible type! #include <stdio.h> #include <stdlib.h> #include <sys/time.h> #include <sys/types.h> #include <unistd.h> int main(void) {

Hi Cristian, this is (part of) bug 3373, see http://llvm.org/bugs/show_bug.cgi?id=3373 > FD_ZERO(&rfds); //this is the error line ... > # define __FD_ZERO(fdsp) \ > do { \ > int __d0, __d1; \ > __asm__ __volatile__ ("cld; rep;

Hi Sang Kil Cha, > Whenever I compile a C program containing "FD_SET" function using llvm-gcc > 2.7 (with -emit-llvm option), I got the following inline assembly in my > llvm byte code: this comes directly from your system headers (/usr/include/bits/select.h) and as such doesn't really have anything to do with llvm-gcc: #if defined __GNUC__ && __GNUC__ >= 2 #

+ CBL mailing list On Thu, Jun 27, 2019 at 11:08 AM Bill Wendling <isanbard at gmail.com> wrote: > [Adding the correct cfe-dev mailing list address.] > > On Thu, Jun 27, 2019 at 11:06 AM Bill Wendling <isanbard at gmail.com> wrote: > >> Now that ASM goto support has landed, Nick Desaulniers and I wrote up a >> document describing how to expand clang's

What about SelectionDAG representation? Currently we expand callbr to INLINEASM_BR and BR. Both of which are terminators. But in order to support outputs we would need to put CopyFromReg nodes between them. ~Craig On Thu, Jun 27, 2019 at 12:18 PM Nick Desaulniers via cfe-dev < cfe-dev at lists.llvm.org> wrote: > + CBL mailing list > > > On Thu, Jun 27, 2019 at 11:08 AM Bill

I think this is fine, except that it stops at the point where things actually start to get interesting and tricky. How will you actually handle the flow of values from the callbr into the error blocks? A callbr can specify requirements on where its outputs live. So, what if two callbr, in different branches of code, specify _different_ constraints for the same output, and list the same block as a

Thanks Duncan, It seems the bug has been reopened. After reading the comments related to the bug report, it was not clear if this is fixed in llvm-gcc, or just in clang. Thanks, Cristi On Feb 16, 2010, at 3:44 PM, Duncan Sands wrote: > Hi Cristian, this is (part of) bug 3373, see > http://llvm.org/bugs/show_bug.cgi?id=3373 > >> FD_ZERO(&rfds); //this is the error

> this comes directly from your system headers (/usr/include/bits/select.h) > and as such doesn't really have anything to do with llvm-gcc: iirc there were some fixincludes hacks for FD_ZERO thing. Maybe are presented presented in one version and does not - in another, thus the difference... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

Hi Anton, >> this comes directly from your system headers (/usr/include/bits/select.h) >> and as such doesn't really have anything to do with llvm-gcc: > iirc there were some fixincludes hacks for FD_ZERO thing. Maybe are > presented presented in one version and does not - in another, thus the > difference... IIRC the fixincludes hack was done so that the asm would not

[Adding the correct cfe-dev mailing list address.] On Thu, Jun 27, 2019 at 11:06 AM Bill Wendling <isanbard at gmail.com> wrote: > Now that ASM goto support has landed, Nick Desaulniers and I wrote up a > document describing how to expand clang's implementation of ASM goto to > support output constraints. The work *should* be straight-forward, but as > always will need to

Hi, Apologies this is a bit lengthy. TLDR: I'm using Dragonegg + LLVM 3.2 and uClibc, and am finding that using the Fast register allocator (i.e. -optimize-regalloc=0) causes miscompilation of setsockopt calls (5-arg system calls). The problem doesn't happen with the default register allocation path selected. It can be worked around by manually simplifying the system call setup

Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for

Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for

hi, I try to build hello.cpp using both llvmg++ and GNU g++, the generate llvm bytecode's size is about 960K, and the size of binary code generated by g++ is only 13K. Could anyone explain the difference between the two result? BWT: I rebuild the cfrontend in RH linux9.0, but when I build the hello.cpp the llvmG++ reports warnings too, it shows: ----------------------------- [yue at RH9

(Andrew, please sit these in the -mm tree for cooking) Create a paravirt.h header for (almost) all the critical operations which need to be replaced with hypervisor calls. For the moment, this simply includes no_paravirt.h, where all the native implementations now live. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Zachary Amsden <zach@vmware.com>

(Andrew, please sit these in the -mm tree for cooking) Create a paravirt.h header for (almost) all the critical operations which need to be replaced with hypervisor calls. For the moment, this simply includes no_paravirt.h, where all the native implementations now live. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Zachary Amsden <zach@vmware.com>

Okay, let's try this again. I've taken all the source and header files needed to build libstdc++ and libsupc++, and put together a small and very simple Makefile that automates the process. Anyone interested can grab the whole thing from here: http://goanna.cs.rmit.edu.au/~emil/dietstdcxx.1.tar.bz2 (101KB) Usage instructions: 1) Run GNU make: $ gmake This will produce dietstdcxx.bc

hi, when using the execution engine (no matter, if JIT or Interpreter) i get the following assertion as soon as i use boost::shared_ptr: /build/buildd/llvm-2.5/lib/Target/X86/X86CodeEmitter.cpp:522: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && "JIT does not support inline asm!\n"' failed.

I'm another new person to LLVM. I can't successfully compile and execute a simple C++ program. The compiler seems to work, as it produces a.out and a.out.bc files, but I get a whole bunch of warnings: WARNING: Found global types that are not compatible: "struct.std::messages<wchar_t>"* %_ZN9__gnu_cxx10messages_cE [16 x sbyte]*

Hi all, I've been looking at finding common ground between the VMI, Xen and other paravirtualization approaches, and after some discussion, we're getting somewhere. These first two patches are the fundamentals, stolen mainly from the VMI patches: removing assumptions about the kernel running in ring 0, and macro-izing all the obvious para-virtualize-needing insns. The third patch is