similar to: [LLVMdev] llvm-gcc won't bootstrap

On Apr 19, 2007, at 2:37 PM, David Greene wrote: > Got a strange problem. With our modified llvm here,llvm-gcc won't > bootstrap. It fails compiling unwind-dw2.c during translation from > the gcc IR to llvm. It fails with -O0 -emit-llvm so according to > the docs, this is strictly a frontend bug. A run of delta produced > an 18 line testcase with nothing remarkable in it.

I can't boostrap LLVM CFE at FreeBSD with current LLVM and LLVM CFE CVS sources. GCC bootstrap terminated with error: /usr/home/wanderer/pkg/build/llvm/objcfe/gcc/xgcc -B/usr/home/wanderer/pkg/build/llvm/objcfe/gcc/ -B/home/wanderer/pkg/build /llvm/night/cfe/i386-unknown-freebsd5.3/bin/ -B/home/wanderer/pkg/build/llvm/night/cfe/i386-unknown-freebsd5.3/lib/ -isystem

Firstly, apologies if this is not the right place to be asking this question--feel free to point me in the correct direction. I could be doing something wrong here but stackoverflow didn't feel like the correct place for this since there's so little there about LLVM ORC. Basically, I have a reproduction case (below) where if I throw an exception before I call JITSymbol::getAddress()

Hi David, This looks like bad eh-frame data due to a failure to fix up the frame descriptor entries: <debug: adding frame> EHFrameAddr: 0x7feae5827000, EHFrameLoadAddr: 0x00000000e5827000, EHFrameSize: 60 ==64588==ERROR: AddressSanitizer: SEGV on unknown address 0x7feae5827020 (pc 0x7feae886d970 bp 0x000000000001 sp 0x7ffca10e75f8 T0) Eyeballing the code in RuntimeDyldELF (vs

On Aug 28, 2007, at 11:35 PM, Chris Lattner wrote: > On Aug 28, 2007, at 11:20 PM, Duncan Sands wrote: > >>> This is a (very) rough patch to fix building LLVM with exceptions on >>> PPC Darwin. Basically, it puts the burden of adding the "--enable- >>> eh" >>> on the specific target, which is where I think it should go. >> >> I

Hi David, Thanks very much for that. I'll continue to dig in as time permits, and I'll update the bug report with my progress once it's filed. Cheers, Lang. On Mon, Apr 17, 2017 at 6:42 PM, David Lurton <dlurton at gmail.com> wrote: > Thanks Lang. I think I'll go the bug creation route. I have an email out > to llvm-admin requesting an account on bugs.llvm.org.

So I couldn't get exceptions to work on PPC darwin. After much digging and confusion, there seem to be two separate issues. The gcc testsuite is running the version of the unwinding code that was built with the local (llvm-)gcc, which doesn't work because nobody has implemented builtin_return_address for that target. So that's one problem. More seriously, the version of the

Hi David, Sorry to hear. Has anyone followed up with you yet? I've continued to dig in to this in my spare time and I've found the issue. It's a use-after-free, rather than any sort of memory smashing. ORC is currently failing to deregister the EH-frame section when the JIT is torn down (but *is* deallocating the memory for it). Normally that's not disastrous (though it does

Hello, Bill > It may be my lack of understanding, but it appears that having -- > enable-eh set during compilation of llvm-gcc is causing extra files > to be compiled. Oh, no. They are always compiled. > They do. However, it doesn't seem to stop it from failing during > compilation of unwind-dw2.c for libgcc -- it has > "__builtin_eh_return" in it. During

Hello, Juergen > Ty->dump() prints "{double, double}" in the failing case (just before my > introduced assert). The answer is simple. The code in question contains extended IEEE FP argument / return type (aka 'long double'). By default it's lowered into struct {double, double} as you already saw and sparc currently does not provide any argument layout hooks. There

Hi Anton, thanks for the fast response. Ty->dump() prints "{double, double}" in the failing case (just before my introduced assert). HTH, and regards, Juergen On 10/30/09 16:19, Anton Korobeynikov wrote: > Hello, Juergen > >> With the full patch, I get the assertion of the 'unhandled REAL_TYPE!', >> so I wonder what needs to be done in order to get

Hi I'm working on the XCore target and am having difficulty building libgcc. Background: If I use a libgcc built by llvm3.0-gcc with my current clang-llvm3.3 compiler, exceptions 'seem' to work. Trying to rebuild libgcc however breaks exception handling - they aren't caught! I thus assumed I needed to focus on the unwind code and particularly functions that call

The first buildbot failure I can readily find was Monday, 26oct2009 around 7PM PDT. The assertion is Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file /Volumes/Sandbox/Buildbot/llvm/

On 8/29/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello, Bill > > > It may be my lack of understanding, but it appears that having -- > > enable-eh set during compilation of llvm-gcc is causing extra files > > to be compiled. > Oh, no. They are always compiled. > > > They do. However, it doesn't seem to stop it from failing during > >

2018-01-24 0:23 GMT+08:00 Ben Craig <ben.craig at ni.com>: > The high level of what happens is that __builtin_eh_return forces a spill > of all the non-volatile registers. The unwinder then has a starting point > for populating and adjusting those non-volatile registers. > > > > This approach usually requires that the function calling > __builtin_eh_return be built

On Aug 28, 2007, at 11:20 PM, Duncan Sands wrote: > Hi Bill, > >> This is a (very) rough patch to fix building LLVM with exceptions on >> PPC Darwin. Basically, it puts the burden of adding the "--enable-eh" >> on the specific target, which is where I think it should go. > > I don't like it. LLVM has plenty of features that are not supported > on

> > The problem is with libgcc2, which contains libcalls needed to support > some operations > your processor cant directly do. > Yes, I mix up libgcc2 with libcpp... I have advanced a little, commenting out the fp functions. Now, it stucks at unwind-dw2.c. MipsISelLowering.cpp gives the error: Unsupported calling convention. By the way, I understand that these functions are

Hello, At this moment I have built from scratch a gcc compiler for ARM and I have in the classpath the binaries. arm-elf-gcc -v Using built-in specs. Target: arm-elf Configured with: ../gcc-4.3.3/configure --target=arm-elf --prefix=/tmp/arm-cortex-toolchain --enable-interwork --enable-multilib --enable-languages=c,c++ --with-newlib --disable-shared --with-gnu-as --with-gnu-ld Thread model:

Hi, This happens when attempting to install any package. There were no such problems on 11.0. Some other ways to trigger the problem: curlGetHeaders("http://bugs.r-project.org") There are no problems with the first two calls, but then the crash always happens on the third call. tf <- tempfile() download.file("http://cran.r-project.org/",tf,method="libcurl")

Anton, I went with the first alternative with some success. However, now I get some errors during the build of libgcc with 'multiply defined symbols'. One thing I noticed is the following fact: Definition in unwind-pe.h: static const unsigned char * read_sleb128 (const unsigned char *p, _Unwind_Sword *val) --- GCC 4.2.4 bootstrapped on Solaris/SPARC -bash-3.00$ nm unwind-dw2.o | grep