On Mon, May 18, 2020 at 9:56 PM Andrey Zhizhikin via
lists.openembedded.org
wrote:
>
> On Thu, May 14, 2020 at 8:22 PM Khem Raj wrote:
> >
> >
> >
> > On 5/14/20 11:19 AM, Adrian Bunk wrote:
> > > On Thu, May 14, 2020 at 10:18:53AM -0700, Khem Raj wrote:
> > >> On 5/14/20 8:29 AM, Adrian Bunk
On Thu, May 14, 2020 at 8:22 PM Khem Raj wrote:
>
>
>
> On 5/14/20 11:19 AM, Adrian Bunk wrote:
> > On Thu, May 14, 2020 at 10:18:53AM -0700, Khem Raj wrote:
> >> On 5/14/20 8:29 AM, Adrian Bunk wrote:
> >>> Disabling -moutline-atomics would also workaround this issue.
> >>
> >> I think this is a
On 5/14/20 11:19 AM, Adrian Bunk wrote:
On Thu, May 14, 2020 at 10:18:53AM -0700, Khem Raj wrote:
On 5/14/20 8:29 AM, Adrian Bunk wrote:
Disabling -moutline-atomics would also workaround this issue.
I think this is a good suggestion and I do not like to revert gcc patches if
we can avoid
On Thu, May 14, 2020 at 10:18:53AM -0700, Khem Raj wrote:
> On 5/14/20 8:29 AM, Adrian Bunk wrote:
> > Disabling -moutline-atomics would also workaround this issue.
>
> I think this is a good suggestion and I do not like to revert gcc patches if
> we can avoid doing that. I will propose a fix to
On 5/14/20 8:29 AM, Adrian Bunk wrote:
Disabling -moutline-atomics would also workaround this issue.
I think this is a good suggestion and I do not like to revert gcc
patches if we can avoid doing that. I will propose a fix to disable
outline-atomics for valgrind on aarch64
And I think
Disabling -moutline-atomics would also workaround this issue.
And I think it would be the right thing to do for Yocto in any case.
-moutline-atomics makes sense for binary distributions that want to
offer both high performance for heavily threaded code on >= ARMv8.1
and support ARMv8.0 in the
On Thu, May 14, 2020 at 07:48:28AM -0700, Khem Raj wrote:
> On Thu, May 14, 2020 at 7:07 AM Adrian Bunk wrote:
>
> > On Thu, May 14, 2020 at 06:56:07AM -0700, Khem Raj wrote:
> > > On Thu, May 14, 2020 at 6:16 AM Adrian Bunk wrote:
> > >
> > > > On Thu, May 14, 2020 at 05:47:48AM -0700, Khem
On Thu, May 14, 2020 at 7:07 AM Adrian Bunk wrote:
> On Thu, May 14, 2020 at 06:56:07AM -0700, Khem Raj wrote:
> > On Thu, May 14, 2020 at 6:16 AM Adrian Bunk wrote:
> >
> > > On Thu, May 14, 2020 at 05:47:48AM -0700, Khem Raj wrote:
> > > > On Thu, May 14, 2020 at 12:38 AM Adrian Bunk wrote:
On Thu, May 14, 2020 at 06:56:07AM -0700, Khem Raj wrote:
> On Thu, May 14, 2020 at 6:16 AM Adrian Bunk wrote:
>
> > On Thu, May 14, 2020 at 05:47:48AM -0700, Khem Raj wrote:
> > > On Thu, May 14, 2020 at 12:38 AM Adrian Bunk wrote:
> > > > On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj
On Thu, May 14, 2020 at 6:16 AM Adrian Bunk wrote:
> On Thu, May 14, 2020 at 05:47:48AM -0700, Khem Raj wrote:
> > On Thu, May 14, 2020 at 12:38 AM Adrian Bunk wrote:
> > > On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> > > > This was added recently, but it seems be chewing more
On Thu, May 14, 2020 at 05:47:48AM -0700, Khem Raj wrote:
> On Thu, May 14, 2020 at 12:38 AM Adrian Bunk wrote:
> > On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> > > This was added recently, but it seems be chewing more than what it
> > > should and causes non glibc packages also
On Thu, May 14, 2020 at 12:38 AM Adrian Bunk wrote:
> On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> > This was added recently, but it seems be chewing more than what it
> > should and causes non glibc packages also depend on it.
> >...
>
> Is this only valgrind (there is a upstream
On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> This was added recently, but it seems be chewing more than what it
> should and causes non glibc packages also depend on it.
>...
Is this only valgrind (there is a upstream bug open for that),
or were there more recipes with a problem?
This was added recently, but it seems be chewing more than what it
should and causes non glibc packages also depend on it.
Signed-off-by: Khem Raj
---
meta/recipes-devtools/gcc/gcc-10.1.inc| 1 +
...se-__getauxval-instead-of-getauxval-.patch | 47 +++
2 files changed,
14 matches
Mail list logo
