similar to: [LLVMdev] arm code generation

Hello, I'm trying to do the following and encountering problems with the generated arm assembly code: I've got an application in two parts that i've compiled into llvm bitcode using: llvm-gcc -emit-llvm -c part1.c -o part1.bc llvm-gcc -emit-llvm -c part2.c -o part2.bc Then I link them together: llvm-ld part1.bc part2.bc -o combined.bc Now I use the ARM backend via llc to

Some doxygen annotations are attached to the wrong entry, which can be misleading. This patch fixes the mistake everywhere I could find it. --- include/llvm/InstrTypes.h | 54 ++++++++++++++++++++-------------------- include/llvm/MC/MCDirectives.h | 42 +++++++++++++++--------------- include/llvm/Pass.h | 10 +++--- 3 files changed, 53 insertions(+), 53 deletions(-) diff

On Thu, Mar 28, 2013 at 1:49 PM, Eric Christopher <echristo at gmail.com>wrote: > On Thu, Mar 28, 2013 at 1:46 PM, Anton Korobeynikov <asl at math.spbu.ru> > wrote: > >> Sounds fine to me. I just wanted some convenient and consistent naming. > >> I think it conflicts a bit with the triples (-win32 currently means > >> msvc I think), > > Right.

On Thu, Mar 28, 2013 at 1:46 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Sounds fine to me. I just wanted some convenient and consistent naming. >> I think it conflicts a bit with the triples (-win32 currently means >> msvc I think), > Right. But this is again a historical (and LLVM-specific) artifact, > because I doubt anyone uses such triplet outside to

When I request a write-before-read memory barrier on x86 I would expect to get an assembly instruction that would enforce this ordering (mfence, xchg, cas), but it just turns into a nop. 1. ; ModuleID = 'test.bc' 2. target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128" 3. target

Hello, > If anybody has an idea of how to fix this (other than using another > version of gcc because I am sick of compiling), I would appreciate. I > can offer backtraces or shell access if anybody is interested, just > ask me what you need. This was fixed couple of months ago. Please consider using current svn top of tree, not 2.3 release. -- WBR, Anton Korobeynikov

2008/9/21 Anton Korobeynikov <asl at math.spbu.ru>: > Hello, > >> If anybody has an idea of how to fix this (other than using another >> version of gcc because I am sick of compiling), I would appreciate. I >> can offer backtraces or shell access if anybody is interested, just >> ask me what you need. > This was fixed couple of months ago. Please consider

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: da1742791d8c0c0a8e5471f181549c4726a5c5f9 commit: 7527631e900d464ed2d533f799cb0da2b29cc6f0 [8/22] virtio-mem: Paravirtualized memory hotplug config: x86_64-randconfig-b002-20200505 (attached as .config) compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0 reproduce: git checkout

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: da1742791d8c0c0a8e5471f181549c4726a5c5f9 commit: 7527631e900d464ed2d533f799cb0da2b29cc6f0 [8/22] virtio-mem: Paravirtualized memory hotplug config: x86_64-randconfig-b002-20200505 (attached as .config) compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0 reproduce: git checkout

> Sounds fine to me. I just wanted some convenient and consistent naming. > I think it conflicts a bit with the triples (-win32 currently means > msvc I think), Right. But this is again a historical (and LLVM-specific) artifact, because I doubt anyone uses such triplet outside to mean msvc compatibility. > but that'll probably be ok ultimately - internal function names are easy to

> And be warned that the PC doesn't point at the next instruction when you use it like this - I believe you don't need to modify it at all if you swap the pop and the .long. Bernie, is it related to ARM pipeline? I'm interesting in this, is there any other additional information? On Fri, Mar 8, 2013 at 4:59 AM, Tim Northover <t.p.northover at gmail.com>wrote: > Hi Ashi,

Hi, Oscar > at all, it would be great if you reflect your changes on the file list > inside the corresponding CMakeLists.txt when you add, remove or rename a > .cpp file. Isn't is possible for cmake just to glob everything in the corresponding directory? -- WBR, Anton Korobeynikov

On Monday 04 January 2010 05:16:40 Jeffrey Yasskin wrote: > On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > LLVM's TCO already handles mutual recursion. > > Only for fastcc functions Yes. > compiled with -tailcallopt, right? If you use the compiler, yes. > http://llvm.org/docs/CodeGenerator.html#tailcallopt > > I believe

Hi, Chris > If the assembler is a limitation, the best solution would be to add a > direct PECOFF writer. There is a start of direct ELF and Macho writers > already in the tree. They are not production quality, but could be a > useful place to start looking. Well, maybe. But in any case I doubt there will be 'open' support for CV debug format :) -- WBR, Anton

On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > On Monday 04 January 2010 03:33:06 Simon Harris wrote: >> On 04/01/2010, at 3:01 PM, Jon Harrop wrote: >> > I am certainly interested in tail calls because my HLVM project relies >> > upon LLVM's tail call elimination. However, I do not understand what tail >> > calls LLVM

Hello, Chuck > I've had a look at the stubs before and I think I'm circumventing them > in the example program since I populate the table and compile the > functions in the order so that things never need to be done lazily, but > I'll look further. Well, anyway stubs are definitely wrong from windows64 and this should be fixed, otherwise funny stuff can happen from time to

I noticed that the base64 functions in util.c don't produce the same results as other versions that implement RFC 1421 (and its successors). This results in PEM files that can only be decoded by tinc itself. Is this intentional? Below is a diff to make tinc's base64 functions match what everyone else does. This will break existing key files, though, which is unfortunate. - todd diff

Hello, Kevin > build process I described in my original message. So the difference is > more subtle; maybe a difference in the layout of structs or something. Also, there can be another ABI differences. > llvmoutput.c:17976: warning: pointer targets in passing argument 1 of > 'longjmp' differ in signedness Hrm, are you using setjmp/longjmp stuff? They're definitely not

Hello, Kevin. > Well, I already use custom includes with these options: "-nostdlib > -nostdinc -Ipsptoolchain/psp/include > -Ipsptoolchain/lib/gcc/psp/4.1.0/include". But that seems not enough. > GCC has some target-specific behaviour compiled in? Well, in general - yes. However, I'm not sure up to which margin. -- WBR, Anton Korobeynikov

Hello, Bill > This merge should go *much* more smoothly than the last merge -- it > could hardly be worse, right? ;-) I already did a test compile of > llvm-test with the patch and it compiled the programs without a > problem. Devang is currently testing it as well so that I have a > second opinion. One thing, which we already saw: please carefully check, that you won't