Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 05 Aug 2017 19:48:03 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 221029] AMD Ryzen: strange compilation failures using poudriere or plain buildkernel/buildworld
Message-ID:  <bug-221029-8-ertGMjpYtL@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-221029-8@https.bugs.freebsd.org/bugzilla/>
References:  <bug-221029-8@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221029

--- Comment #54 from Nils Beyer <nbe@renzel.net> ---
(In reply to Don Lewis from comment #53)

> Interestingly both node and libreoffice core files indicate that c++ died=
 at the same place.

that sounds strange - the main feature of these failures is arbitrariness, =
and
now you have some kind of equal repetition.

Do you have any possibility to generate that again - probably with a
self-written program?

I cannot test this at moment as both my Ryzen boxes are frozen dead - and t=
hey
are at my work-place where I'll be not until Monday.

The reason I ask is because the Linux users got some momentum due to two
Phoronix articles about these segfaults:

    https://www.phoronix.com/scan.php?page=3Dnews_item&px=3DRyzen-Test-Stre=
ss-Run
    https://www.phoronix.com/vr.php?view=3D25016

Unfortunately, the author relied on segfaults with "conftest" stuff which w=
as
not a very wise choice to prove that there is something wrong. "conftest" is
meant to segfault, isn't it?

So, if we can provide something that reliably segfaults on an AMD but not o=
n an
Intel that would be something. Would be a pity if AMD finally says: "see, t=
here
is no problem with the Ryzen; you just have done it wrongly all the time"...

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-221029-8-ertGMjpYtL>