similar to: 16-bit bytes support

> 16-bit byte was a major pain back in the day, and we never fixed all > known failures. In part, it's because C standard really wants 8-bit chars. So no real solution? > Btw, why is DCPU16 still a thing? :) https://github.com/techcompliant/. It's a separate team not related to Mojang which took the idea. They are on alpha now. Also because

Hi all, FlexyCore, the company I am working for, use LLVM to generate binary for ARM platform. We are very fulfilled with LLVM, and FlexyCore will be pleased to contribute on this software. We need debug support in ARM binary, but, in LLVM 2.4, this support is not activated for ARM backend. Consequently, I made small modifications in order to activate it (see the patch in attach file). My

Hello, I want to compile a LLVM file into an executable running on ARM platform. I use LLVM 2.0 with the following command lines: llvm-as -f -o test.bc test.ll llc -march=arm -mcpu=arm1136j-s -mattr=+v6 -f -o test.s test.bc arm-linux-gnu-as -mcpu=arm1136j-s test.s With the last command, I obtain the following error: rd and rm should be different in mul The bad instruction is

Hi Mikaël, Thanks for the patch. Some comments: 1. Please don't use tabs. 2. Index: lib/Target/ARM/ARMInstrInfo.cpp =================================================================== --- lib/Target/ARM/ARMInstrInfo.cpp (revision 14) +++ lib/Target/ARM/ARMInstrInfo.cpp (working copy) @@ -904,7 +904,8 @@ return TAI->getInlineAsmLength(MI-

Hi Mikael, You are obtaining warning, not an error, right? The most arm cores, including arm1136, can execute mul with rd = rm. So, you can ignore this warning. Lauro 2007/6/12, Peltier, Mikael <m-peltier at ti.com>: > > > > > Hello, > > > > I want to compile a LLVM file into an executable running on ARM platform. > > I use LLVM 2.0 with the following

Thanks for the commit. FlexyCore works only on ARM EABI Linux target for now. This binary with Dwarf information could be debugged with a gdb-server 6.8 without problem on our side. If you are working on ARM Linux target, could you send us LLVM source file, and gdb version ? But if you are using ARM Darwin as Anton suggest, we are unable to test this for now. We are open to help on this

Hi Evans, Currently, we have not test all debug functionnalities, this will be done with the progress of our project. Could you explain more in details (by mail if possible) what is the problem with aggregates and debugging ? Could you also provide C program or llvm source file that exposes this problem in order to see what we can do? During our roadmap progress, FlexyCore will not hesitate to

Hello, I want to find information/documentation on how reorganize stack frame (add other information, etc.) & how add new calling convention into ARM backend? I think it is needed to modify lowering of CALL, RET & FORMAL_ARGUMENT instruction, and also to modify emitPrologue & emitEpilogue functions. What are the others things to modify in order to realize my

Hi, I would like to log the errors to stderr and to a file, but it doesn't seem possible for now. I tried ``` <errorlog>icecast-error.log</errorlog> <errorlog>-</errorlog> ``` but the last setting erases the previous ones so I can only print to one of them. Could you add this feature? Have a good day, Mikaël Fourrier

On Dec 11, 2008, at 8:23 AM, Mike-1 wrote: > > Thanks for the commit. > > FlexyCore works only on ARM EABI Linux target for now. This binary > with > Dwarf information could be debugged with a gdb-server 6.8 without > problem on > our side. Good to hear. Are you able to examine aggregates? > > > If you are working on ARM Linux target, could you send us LLVM

Hello, I search information in order to access address (i.e. value) of label directly in llvm assembler file. This can be useful to realize jump table from address, etc. I generate the file branch.ll from a C file. In this file, we saw that branches are realized by affecting virtually an id to each label and use a switch in order to find the right target. I want to know if there is

> It's definitely doable, but I'd be worried about the maintenance burden. Yes, that is a problem. We are currently not allowed to reveal our target (which has 16-bit bytes, and registers with non-power-of-two bit widths) fully, and therefore not able to submit it upstream. One idea we have toyed with is to create a simple "dummy" version of our target, just to be able

I've committed the patch with some fixes. It allows ARM target to generate Dwarf information. However, I did not have much luck debugging llvm produced executables. I would appreciate it very much if you can put the debug support to test and contribute more patches. Thanks, Evan On Dec 10, 2008, at 8:38 AM, Mike-1 wrote: > > Hi all, > > FlexyCore, the company I am working

Hi, I'm with a team using 16-bit bytes for an out-of-tree target. The AsmPrinter framework's implementation of the DWARF debugging format is not very good at distinguishing between target-sized bytes (which is the more common use) and 8-bit-bytes. The DWARF standard itself seems not very good in this regard, actually. So we have had to hack our way around this. I.e., at some call-sites of

Back in 2009 there was some discussion of the practicality of supporting char sizes greater than 8-bit: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-September/thread.html#6349 http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/thread.html#26025 with the consensus seemingly being "quite doable, please get a good patch and submit". However the current code appears (to my

On Sat, Oct 15, 2011 at 12:26 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Sat, Oct 15, 2011 at 7:38 AM, Thomson <lilotom at gmail.com> wrote: >> I just found that some samples used link.exe from Visual Studio to generate >> the final image, does LLVM has a replacement for link.exe to generate the >> final binary? I'm not related to the topic

This buildbot seems to have been failing for a while (though it's hard for me to identify the root cause in the logs, as I mentioned in another thread, so it's hard to say if it's the same failure, or if the failure is consistent, etc) - anyone watching it/caring aobut it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at

On Sat, Oct 15, 2011 at 7:35 PM, Ivan Krasin <krasin at google.com> wrote: > I'm not related to the topic starter, but I see at least one huge > disadvantage of the dependency on link.exe. > W/o such a dependency it would be possible reliably generate Windows > executables on Linux or Mac, which has its own benefits (e.g. > distributed compilation) GRUB, the Grand Unified

Hi llvm team! I'm currently working on the extended version of llvm-ld, which has an ability to check if all the symbols present (and fail if some symbols are not resolved), treat archives in the right way (link all the object files in the archive if it's specified as the regular input, not as -l) and the most important to my project feature: to link against bitcode "shared

On 08/12/11 03:56 PM, Ivan Krasin wrote: > Hi llvm team! > > I'm currently working on the extended version of llvm-ld, which has an > ability to check if all the symbols present (and fail if some symbols > are not resolved), treat archives in the right way (link all the object > files in the archive if it's specified as the regular input, not as -l) Is that the