Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Sep 2020 17:48:33 +0200
From:      Dimitry Andric <dim@FreeBSD.org>
To:        Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>
Cc:        freebsd-current@freebsd.org
Subject:   Re: clang build buggy code with certain CPUTYPE setting
Message-ID:  <6AA016B6-EEAC-4580-B7F0-9D274ADA9E73@FreeBSD.org>
In-Reply-To: <20200926114045.GA31128@plan-b.pwste.edu.pl>
References:  <20200926114045.GA31128@plan-b.pwste.edu.pl>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_6C302055-441C-4F4A-9B7C-EC1B2E1846F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 26 Sep 2020, at 13:40, Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> =
wrote:
>=20
> I have done a few builds of CURRENT in a row one or two weeks apart. =
The
> builds with CPUTYPE?=3Damdfam10 set produce buggy code, for example =
while
> running mergemaster I get this error:
>=20
> PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and
> include the crash backtrace, preprocessed source, and associated run
> script.
> Stack dump:
> 0.      Program arguments: cc --version
> #0 0x00000000040ede6e (/usr/bin/cc+0x40ede6e)
> #1 0x00000000040ec0e5 (/usr/bin/cc+0x40ec0e5)
> #2 0x00000000040ee550 (/usr/bin/cc+0x40ee550)
> #3 0x000000080553babe (/lib/libthr.so.3+0x19abe)
> Illegal instruction
> make: "/usr/src/share/mk/bsd.compiler.mk" line 181: Unable to =
determine
> compiler type for CC=3Dcc.  Consider setting COMPILER_TYPE.
>=20
> The 13-CURRENT world built without CPUTYPE runs fine, the same for
> recent 12.2-STABLE world build with CPUTYPE?=3Damdfam10 on the same
> machine.

Hi Marek,

In r365507 (on 2020-09-09) I committed a fix for amdfam10:

------------------------------------------------------------------------
r365507 | dim | 2020-09-09 20:11:04 +0200 (Wed, 09 Sep 2020) | 17 lines

Merge commit e6bb4c8e7 from llvm git (by Craig Topper):

  [X86] SSE4_A should only imply SSE3 not SSSE3 in the frontend.

  SSE4_1 and SSE4_2 due imply SSSE3. So I guess I got confused when
  switching the code to being table based in D83273.

  Fixes PR47464

This should fix builds with -march=3Damdfam10 emitting SSSE3 =
instructions
such as pshufb, which lead to programs crashing with SIGILL on such
processors.

Reported by:    avg
MFC after:      6 weeks
X-MFC-With:     r364284

So I expect that the "Illegal instruction" you are seeing is an SSSE3
instruction. If this happens with your base compiler, please get a
known-good copy from one of the snapshot images. Ensure your /usr/src is
r365507 or later, then do a full buildworld and reinstall.

-Dimitry


--Apple-Mail=_6C302055-441C-4F4A-9B7C-EC1B2E1846F6
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.2

iFwEARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCX29i0gAKCRCwXqMKLiCW
o9GbAJYiNkXYA4MMCdi1DQ7JPi+S9TUJAKDw8QLjUFqT5ntPcuLEDqCO6rOtXg==
=HBEa
-----END PGP SIGNATURE-----

--Apple-Mail=_6C302055-441C-4F4A-9B7C-EC1B2E1846F6--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6AA016B6-EEAC-4580-B7F0-9D274ADA9E73>