Undefined reference to `__sync_bool_compare_and_swap_4' for some Leon configurations with gfortran

Joel Sherrill joel at rtems.org
Fri Mar 3 10:20:34 UTC 2017


On Tue, Feb 28, 2017 at 8:27 AM, <Jan.Sommer at dlr.de> wrote:

>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Sebastian Huber [mailto:sebastian.huber at embedded-brains.de]
> > Gesendet: Montag, 27. Februar 2017 15:25
> > An: Sommer, Jan; devel at rtems.org
> > Betreff: Re: AW: AW: AW: Undefined reference to
> > `__sync_bool_compare_and_swap_4' for some Leon configurations with
> > gfortran
> >
> >
> >
> > On 27/02/17 15:15, Jan.Sommer at dlr.de wrote:
> > >> -----Ursprüngliche Nachricht-----
> > >> >Von: Sebastian Huber [mailto:sebastian.huber at embedded-brains.de]
> > >> >Gesendet: Montag, 27. Februar 2017 15:11
> > >> >An: Sommer, Jan;devel at rtems.org
> > >> >Betreff: Re: AW: AW: Undefined reference to
> > >> >`__sync_bool_compare_and_swap_4' for some Leon configurations with
> > >> >gfortran
> > >> >
> > >> >On 27/02/17 15:08,Jan.Sommer at dlr.de  wrote:
> > >>> > >Ok, thanks for the clarification.
> > >>> > >I will try to create a patch for gcc and put rtems CC for the
> discussion.
> > >> >
> > >> >Another option would be to provide the __sync_() stuff also via
> libatomic.
> > >> >
> > > True. I will ask on the gcc mailinglist what they would prefer.
> > >
> >
> > This __sync_() stuff seems to be used in several places in GCC. So,
> changing
> > libbacktrace is probably not enough. We need a general solution for the
> > __sync_() builtins on RTEMS. I don't think GCC can be changed to emit
> > __atomic_() calls for the __sync_() builtins (I would still try to ask).
> The libgcc or
> > libatomic is probably a good place to add them for RTEMS as functions
> > implemented via __atomic_() builtins.
> >
>
> I updated the __sync-check of libbacktrace and now thvee undefined
> references are gone and my test program compiles.
> If there are no objections I would try to push something like the attached
> patch upstream. Do you have any suggestions to which branches?
> I thought about trunk and the gcc-6 branch or do we need further backports
> for older RTEMS versions?
>

>From a gcc perspective, it should be applied to all open branches that this
patch can apply easily to with highest priority on gcc-6-branch and newer.

I am on travel and can't speak to whether this impacts 4.11 tools or not. I
strongly suspect it does though and it would be desirable to fix this on
4.11 and master (e.g. 4.12).

--joel


> Best regards,
>
>    Jan
>
> > --
> > Sebastian Huber, embedded brains GmbH
> >
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
> > Phone   : +49 89 189 47 41-16
> > Fax     : +49 89 189 47 41-09
> > E-Mail  : sebastian.huber at embedded-brains.de
> > PGP     : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170303/e4cf0cd6/attachment-0002.html>


More information about the devel mailing list