similar to: Difference in EHType between ARM and AArch64

Hi, :If I compile this file with debugging enabled (clang/LLVM TOT) int main() { } I get the error Error: inconsistent uses of .cfi_sections From the 2.27 binutils assemblers. It seems that 2.27 doesn't like the .cfi_sections .debug_frame directive following previous .cfi directives. The assemblers seem to be happy if the .cfi_sections directive precedes any other .cfi directive. Is

Hi, I just updated from r190763 to r191137 and started getting failures in generated assembly language when debug info is enabled. Here is the test case: // Compile and run for every target. // RUN: %ecc -g -o %t %s && %t // FAIL: %armecc -g -o %t %s && %armrun %t // FAIL: %armebecc -g -o %t %s && %armebrun %t // RUN: %i386ecc -g -o %t %s && %i386run %t // FAIL:

Interesting. File please? Thanks. On Sep 21, 2013 6:01 AM, "Richard Pennington" <rich at pennware.com> wrote: > Hi, > > I just updated from r190763 to r191137 and started getting failures in > generated assembly language when debug info is enabled. Here is the test > case: > > // Compile and run for every target. > // RUN: %ecc -g -o %t %s && %t

If it thinks the symbol is in the BSS section, then it should never have tried to use .comm to emit it I think. On x86 it does not try to mix and match, which is why it works. AFAIK comm symbols are regarded as having no section, rather than being bss, so I think it's a bug in whatever code printed that .comm statement. I'll look into this tomorrow. > Eric Christopher

Hi Gents, For those of us with out-of-tree backends which are not 32bit, the msp430 backend is a useful vehicle for examining changes and testing out ideas. So I was wondering about enabling debug output on the MSP430 backend so that I can illustrate a few issues to Adrian and you on the variable pieces side. (there doesn't appear to be any specific person claiming the msp430 code right

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

Thanks for reducing that for me! The outliner pulls out the following: OUTLINED_FUNCTION_0: // @OUTLINED_FUNCTION_0 .cfi_sections .debug_frame .cfi_startproc // %bb.0: adrp x29, g1 add x29, x29, :lo12:g1 adrp x30, g2 // This adrp shouldn’t have been outlined. ret It shouldn’t be pulling out that adrp. There’s a special case for arps in

Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from

Jeremy, Could you send/attach a small test case that demonstrates the problem? It doesn't need to go past the stage that creates a .o. Also, what version of gnu as are you using? Unless it conflicts with a fundamental llvm/clang philosophy, we are trying to keep Mips assembly compatible with AS. Also, keep in mind that the Mips llvm assembler is current development and is not considered

I was told that my writeup lacked an example and details so I reproduced the code that X uses and I was able to boil down the issue to a couple of lines of code. Sorry again for the length of this email. Code was compiled on OpenBSD with clang 3.0-release. ======================================================================== With -O0 which works as X expects:

Hi, All I am trying to implement a llvm backend. But I encountered the following problem when running the backend: "Fatal error: error in backend: WinEH not implemented for this target" This error is triggered by function processFunctionBeforeFrameFinalized() defined in class TargetFrameLowering. Can anyone help? Thanks a lot! Zhiguo [cid:image001.jpg at 01D50970.C9344210]

Sorry, I was using a modified compiler, which by coincidence made the bug much easier to reproduce. In some rare cases, the compiler will use x30 as a general-purpose register; in that case, outlining breaks because the "ret" branches to the wrong address.  Testcase (reproduce with "clang -O3 --target=aarch64-pc-linux-gnu -mllvm -enable-machine-outliner"): extern long g1;

> Is it safe to say the MC work provides a (new) foundation for > implementing ARM EH? Or, is providing ARM EH independent of the ARM-MC > work? The latter. MC stuff helps somehow though. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Mon, Sep 27, 2010 at 09:14:05AM -0700, Jason Kim wrote: > On Mon, Sep 27, 2010 at 8:50 AM, Dennis Taul <dtaul at codeaurora.org> wrote: > > > > I am new to LLVM but have perused the code alongside using llvm-gcc > > and CLANG to build ARM EABI objects. > > > > Based on this superficial analysis it appears that LLVM currently does > > not support the

Hi all, I'm experimenting with compiling some Mips code which is normally built with a gcc cross toolchain with clang instead. This code targets the Cavium Octeon, and uses some of that CPU's crypto engine features which are implemented in coprocessor 2. The inline asm for the crypto code uses instructions of the form "dmtc2 %0, 0xNNNN" - that is the coprocessor register is