This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: nvptx abort implementation
Hi Tom!
My last comment on this, I promise (or hope?). ;-P
On Thu, 3 May 2018 11:45:57 +0200, Tom de Vries <Tom_deVries@mentor.com> wrote:
> On 05/03/2018 11:42 AM, Thomas Schwinge wrote:
> > On Thu, 3 May 2018 11:30:19 +0200, Tom de Vries <Tom_deVries@mentor.com> wrote:
> >> On 05/03/2018 10:39 AM, Thomas Schwinge wrote:
> >>> On Wed, 2 May 2018 19:36:53 +0200, Tom de Vries <Tom_deVries@mentor.com> wrote:
> >>>> IV.
> >>>>
> >>>> I'd prefer a robust abort implementation that:
> >>>> - does not depend on the __builtin_trap gcc bug being fixed, and
> >>>
> >>> Why not just do that? (Even just on trunk, given that the current
> >>> implementation as used for release branches will effectively also abort?)
> >>
> >> Well, what you're saying here is that a robust implementation is not
> >> needed, given that you think that the current implementation will work
> >> in all the use cases you can think of and think of as relevant.
> >>
> >> I OTOH think that with a robust implementation, it will work in all use
> >> cases.
> >
> > Well, what I don't understand is why your proposed 'abort' implementation
> > is more robust than a '__builtin_trap' one (with GCC fixed, of course)?
>
> Because it is guaranteed to work with versions of GCC that are not
> fixed, of course ;)
Then a) exercise your GCC nvptx maintainer status to backport the
(supposedly trivial) GCC fix to active release branches, or b) just wait
a few years ;-) until the not-fixed GCC versions have become obsolete.
Option b) seemed fine to me given that -- as far as I understand -- the
behavior/change is not actually observable by users.
Grüße
Thomas