search for: __builtin_eh_return

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 without optimizations, becaus...

...szek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/19/2018 7:21 PM, 陳韋任 wrote: >> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to it, but others don't. May I know why it's so on Hexagon? > > Our exception handling runtime uses __builtin_eh_return. Does this mean that you know what it does? If so, please could you document it somewhere? David

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 without optimizations, because the optimizer will then remove t...

...t 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 4-way FAT PPC compilation, it > tries to compile this file and fails during the LowerOperation > function. Turning --enable-eh off makes the error go away. Could you please send me .bc, which fails? I'll try to figure out, what is going wrong. -- With best regard...

2018-01-19 23:00 GMT+08:00 Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org>: > On 1/15/2018 6:49 AM, 陳韋任 via llvm-dev wrote: > >> - EH_RETURN: >> >> I see some targets define their own EH_RETURN SDNode, others don't. >> What is EH_RETURN, and under what circumstances I should define my own >> EH_RETURN SDNode? >> > > This

On 1/19/2018 7:21 PM, 陳韋任 wrote: > I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower > to it, but others don't. May I know why it's so on Hexagon? Our exception handling runtime uses __builtin_eh_return. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

...<llvm-dev at lists.llvm.org> wrote: >> >> On 1/19/2018 7:21 PM, 陳韋任 wrote: >>> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to it, but others don't. May I know why it's so on Hexagon? >> >> Our exception handling runtime uses __builtin_eh_return. > > Does this mean that you know what it does? If so, please could you document it somewhere? I don't actually, but I can find out. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

...t; > 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 4-way FAT PPC compilation, it > > tries to compile this file and fails during the LowerOperation > > function. Turning --enable-eh off makes the error go away. > Could you please send me .bc, which fails? I'll try to figure out, what > is going wrong. >...

...e with Duncan: can't the target (which knows the capabilities > of the currently selected subtarget) set the value of > SupportsExceptionHandling correctly? > 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 4-way FAT PPC compilation, it tries to compile this file and fails during the LowerOperation function. Turning --enable-eh off makes the error go away. It may be my lack of understanding, but it appears that having -- enable-eh set during compilation of llvm-gcc is causing...

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

Hi all, 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. If this is okay, then I can clean the patch up and submit it. -bw Index: gcc/llvm-backend.cpp =================================================================== ---

...ote: >>> >>> On 1/19/2018 7:21 PM, 陳韋任 wrote: >>>> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower >>>> to it, but others don't. May I know why it's so on Hexagon? >>> >>> Our exception handling runtime uses __builtin_eh_return. >> >> Does this mean that you know what it does? If so, please could you >> document it somewhere? > > I don't actually, but I can find out. > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Lin...

...ompilation 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 4-way FAT PPC compilation, it > > > tries to compile this file and fails during the LowerOperation > > > function. Turning --enable-eh off makes the error go away. > > Could you please send me .bc, which fails? I'll try to figure out, what > > i...

On Jan 9, 2013, at 2:38 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 9 Jan 2013, at 04:49, Marc J. Driftmeyer wrote: > >> It's not a coincidence that GCC 4.2.1 is the baseline on FreeBSD considering the licensing of GPL restrictions on new releases. > > [With my FreeBSD hat on] > > Our plan for 10.0 is to ship clang only, with gcc 4.2.1