similar to: [LLVMdev] Question about bug #18622#

On 02/04/2013 09:32 PM, Anton Korobeynikov wrote: >> am I wrong or the ARM c++ exceptions handling does not work? > Yes, it's still work-in-progress option disabled by default. You might > want to give it a try via special cmdline line -mllvm > -arm-enable-ehabi Ohhh I see, thanks for the input! > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics

Hi all, I remember the discussion about promoting the integrated ARM assembler as the default option, but I don't remember the outcome. While compiling on ARM, I noticed that clang is not setting the integrated-as by default and is calling GAS before LD, which sometimes cause confusion (GAS doesn't like using r13 as a GPR, for instance). While this is unpredictable in Thumb, it's

Hi dear list, I tried to build llvm+clang on an OpenSuse BuildServer for ARM. The build was carried out with CMake 2.8.11. In the installation step I got the following error: > [26815s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/llvm-3.4.99-336.1.arm/usr/lib/libLLVMSupport.so > [26815s] CMake Error at lib/Support/cmake_install.cmake:45 (FILE): > [26815s] file RPATH_CHANGE could

Hi Renato, > is there anything holding the integrated assembler back from being on by default? For ARM-ELF, a couple missing pieces I see: 1) The assembly parser does not parse the ARM-ELF directives. 2) The Exception Handling ABI does not appear to be supported. Try this: $ echo "void a(){}" | clang -target arm-none-linux-gnueabi -mllvm -arm-enable-ehabi -integrated-as -c -xc -

> am I wrong or the ARM c++ exceptions handling does not work? Yes, it's still work-in-progress option disabled by default. You might want to give it a try via special cmdline line -mllvm -arm-enable-ehabi -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi, I'm not sure if this is the right mailing list for my question, so please redirect me if this is the wrong place for the following question: Am I allowed to include R.dll and Rblas.dll in other software ? In my case I'm want to run some R commands from a Python script and save the results. I tried RPy2 which has some trouble running on Windows. Regards, Uwe -- Dr. rer. nat.

Hello, am I wrong or the ARM c++ exceptions handling does not work? See the difference between assembly generated by clang and gcc with the following test code: #include <stdio.h> #include <exception> # test.cpp int main() { try { throw 20; } catch (int e) { printf("Exception Nr %d occurred\n", e); } return 0; }

Hi Keith, Anton, Logan, Last time we spoke about ARM unwinding, we agreed to have both CFI and directive variants in ARM, so that both EH and debuggers/profilers could correctly unwind the stack. The problem, obviously, is that we now have redundant information and I decided to have a go commoning them up. One of the issues, I think, is GNU compatibility (so GAS can generate the tables correctly

On 15 March 2014 17:06, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > I would like to know what do you mean by "commoning them up"? Hi Logan, That'd be reducing ARM directives in favour of CFI, but as I said (and you too), GNU compatibility will probably be an issue for a very long time. > For the space issue, I personally don't think this is a big issue.

Folks, We're having some discussions about the behaviour of exception handling and Dwarf sharing unwind logic, tables, etc. and it seems that the code around it wasn't designed with any particular goal in mind, but evolved (like the EHABI) and now we're seeing the results from it. The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional vs.

I thought the ARM EHABI added a twist to this because it created some upward dependency from the unwinder to libc++abi. Other than that, I don’t have any strong feeling where it lives. -Nick On Jan 30, 2015, at 12:33 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 30 January 2015 at 20:17, Saleem Abdulrasool <compnerd at compnerd.org> wrote: >> There is a valid

You may also need to use: -mllvm -enable-correct-eh-support -mllvm -arm-enable-ehabi-descriptors -Chris On Feb 4, 2013, at 3:47 PM, Abdoulaye Walsimou Gaye wrote: > On 02/04/2013 09:32 PM, Anton Korobeynikov wrote: >>> am I wrong or the ARM c++ exceptions handling does not work? >> Yes, it's still work-in-progress option disabled by default. You might >> want to give

Xen 3.4 xen-unstable.hg from yesterday with debian etch on 64bit arch Intel/Lenovo Q35 Mainboard with VT-d enabled Bootoptions iommu=1 vtd=1 pci.backhide for a PCI-E nvidia graphiccard xm dmesg Error messages includes: [VT-D] iommu.c: 1694:d32767 iommu: mapping reserved region failed [VT-D] iommu.c: 1542:d0 intel_iommu_add_device: context mapping failed If i try to start my HVM by xm create

Hi Greg, I'd also like to see the integrated assembler enabled, though I'm only very weakly connected to the 32-bit backend. > 1) The assembly parser does not parse the ARM-ELF directives. Renato asked about inline assembly here, but I think the key question is over the directives LLVM itself decides to generate as a result of Clang invocations. I had a very brief encounter last year

On Thu, Feb 13, 2014 at 5:52 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 13 February 2014 13:47, Evgeniy Stepanov <eugenis at google.com> wrote: >> Hm, I see that -funwind-tables on arm-linux-androideabi target >> replaces this "cantunwind" with a proper unwind table. >> Hence http://llvm-reviews.chandlerc.com/D2762. > > If Android is

I'm trying to figure out if there is a way to figure out what processor resource is used by which instruction during scheduling. This is purely for debugging purposes. Since I'm somewhat new to LLVM it is a bit difficult for me to figure this out. Initial idea was to insert comments in the generated assembly which would tell me what what resource is used. MachineInstr has a uint8_t

Clang optimizes code by replacing some parts with efficient library functions. For example the following code: for (i=0;i<size;++i) dest[i]=src[i]; will be compiled to (target=ARM assembly): bl __aeabi_memcpy(PLT) The compile cmd: /usr/share/android-arm-l14-toolchain/bin/clang31 -cc1 -triple arm-none-linux-androideabi -S -target-abi aapcs-linux -target-cpu arm1022e

Joerg, Referring to your patch https://reviews.llvm.org/rL291172. / switch (MAI->getExceptionHandlingType()) {// // case ExceptionHandling::SjLj:// // case ExceptionHandling::DwarfCFI:// // case ExceptionHandling::ARM:// //*isCFIMoveForDebugging = true;*// //*if (MAI->getExceptionHandlingType() != ExceptionHandling::DwarfCFI)*/*/ /**/ break;/*/ // for (auto &F:

I'd love to hear more details. Are you saying that this infinite loop is a limitation of EHABI table format, and not something that can be fixed in the compiler? Meanwhile, please notice that gcc behavior matches current clang behavior that I described above. We would not want to create an incompatibility. On Fri, Feb 14, 2014 at 8:42 PM, Logan Chien <tzuhsiang.chien at gmail.com>

Hi, I recently tried to build libcxxabi on ARM/Linux but looks like libunwind is not providing the necessary symbols needed, precisely _Unwind_SjLj_RaiseException and related functions are missing. Did anyone have any success with this before? Thanks, ismail -------------- next part -------------- An HTML attachment was scrubbed... URL: