On Fri, 28 Aug 2020, Jakub Jelinek wrote:
> > As far as `-fexceptions' and `-fasynchronous-unwind-tables' are concerned
> > it aligns with my understanding, i.e. in this specific scenario we need
> > `-fasynchronous-unwind-tables' for libcalls (all of them) so that an
>
> -fasynchronous-unwin
On Fri, Aug 28, 2020 at 5:47 PM Ramana Radhakrishnan
wrote:
>
> On Wed, Aug 26, 2020 at 12:08 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Tue, Aug 25, 2020 at 6:32 PM Maciej W. Rozycki wrote:
> > >
> > > Hi Kito,
> > >
> > > > I just found the mail thread about div mod with -fnon-call-
On Fri, Aug 28, 2020 at 04:40:48PM +0100, Maciej W. Rozycki wrote:
> As far as `-fexceptions' and `-fasynchronous-unwind-tables' are concerned
> it aligns with my understanding, i.e. in this specific scenario we need
> `-fasynchronous-unwind-tables' for libcalls (all of them) so that an
-fasyn
On Wed, Aug 26, 2020 at 12:08 PM Richard Biener via Gcc-patches
wrote:
>
> On Tue, Aug 25, 2020 at 6:32 PM Maciej W. Rozycki wrote:
> >
> > Hi Kito,
> >
> > > I just found the mail thread about div mod with -fnon-call-exceptions,
> > > I think keeping the default LIB2_DIVMOD_EXCEPTION_FLAGS uncha
On Wed, 26 Aug 2020, Jakub Jelinek wrote:
> On Wed, Aug 26, 2020 at 01:08:00PM +0200, Richard Biener via Gcc-patches
> wrote:
> > You only need -fexceptions for that, then you can throw; from a signal
> > handler
> > for example. If you want to be able to catch the exception somewhere up
> > th
On Wed, Aug 26, 2020 at 01:08:00PM +0200, Richard Biener via Gcc-patches wrote:
> You only need -fexceptions for that, then you can throw; from a signal handler
> for example. If you want to be able to catch the exception somewhere up
> the call chain all intermediate code needs to be compiled so
On Tue, Aug 25, 2020 at 6:32 PM Maciej W. Rozycki wrote:
>
> Hi Kito,
>
> > I just found the mail thread about div mod with -fnon-call-exceptions,
> > I think keeping the default LIB2_DIVMOD_EXCEPTION_FLAGS unchanged
> > should be the best way to go.
> >
> > Non-call exceptions and libcalls
> > ht
Hi Maciej:
Thanks for your explanation, I am OK with this change for the RISC-V port now,
but I think I don't have permission to approve this patch since it's
more than RISC-V port specific,
maybe you need approval from Richard Biener.
On Wed, Aug 26, 2020 at 12:33 AM Maciej W. Rozycki via Gcc-p
Hi Kito,
> I just found the mail thread about div mod with -fnon-call-exceptions,
> I think keeping the default LIB2_DIVMOD_EXCEPTION_FLAGS unchanged
> should be the best way to go.
>
> Non-call exceptions and libcalls
> https://gcc.gnu.org/legacy-ml/gcc/2001-06/msg01108.html
>
> Non-call except
Hi Maciej:
I just found the mail thread about div mod with -fnon-call-exceptions,
I think keeping the default LIB2_DIVMOD_EXCEPTION_FLAGS unchanged
should be the best way to go.
Non-call exceptions and libcalls
https://gcc.gnu.org/legacy-ml/gcc/2001-06/msg01108.html
Non-call exceptions and libca
Hi Maciej:
Thanks for your patch, I tried to compile all target libraries with
-O0 and got link error as you describe, it's really confusing about
the error message, __pthread_mutex_lock and __pthread_mutex_unlock are
undefined, it turns out the root cause is the __umoddi3 called
_Unwind_Resume an
11 matches
Mail list logo
