Displaying 3 results from an estimated 3 matches for "__rt_raise".
Did you mean:
__gi_raise
2014 Sep 08
2
[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
...r.
>
I think its better to avoid pulling in a dependency on the target libc,
particularly if you want to permit the use of compiler-rt in a bare-metal
environment. This implementation conforms to the specification and can be
overridden if the libc wishes to catch the div-by-zero.
We could use __rt_raise(2, 2), which would need to call signal as well, so
you end up growing a dependency on the target environment's libc
implementation. I think that expanding the responsibility of compiler-rt
from supporting the code generation from the compiler to integrating into
the target environment's li...
2014 Sep 06
2
[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
On Fri, Sep 5, 2014 at 11:32 AM, Jonathan Roelofs <jonathan at codesourcery.com
> wrote:
> Sergey,
>
> Not that it'll save you much hassle, but here's an implementation of
> __aeabi_idiv0 and __aeabi_ldiv0 that I've been sitting on for a while.
>
> I vaguely remember compnerd suggesting that I don't commit them to
> compiler_rt, but I don't remember
2014 Sep 09
2
[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
...ace it with the
implementation that you prefer.
> Since returning zero is consistent with the EABI, I don't think we
> should deviate from that norm, not without a lot of thought, at least.
Yes, although the current implementation also is consistent with EABI.
> > We could use __rt_raise(2, 2), which would need to call signal as well,
> so
> > you end up growing a dependency on the target environment's libc
> > implementation. I think that expanding the responsibility of compiler-rt
> > from supporting the code generation from the compiler to integrating i...