svn commit: r364822 - in head/crypto/openssl/crypto: aes/asm bn/asm chacha/asm ec/asm modes/asm poly1305/asm sha/asm

Jessica Clarke jrtc27 at
Wed Aug 26 18:42:54 UTC 2020

On 26 Aug 2020, at 19:33, Dimitry Andric <dim at> wrote:
> On 26 Aug 2020, at 19:13, Ian Lepore <ian at> wrote:
>> On Wed, 2020-08-26 at 19:04 +0200, Mateusz Guzik wrote:
>>> On 8/26/20, Jung-uk Kim <jkim at> wrote:
>>>> Author: jkim
>>>> Date: Wed Aug 26 16:55:28 2020
>>>> New Revision: 364822
>>>> URL:
>>>> Log:
>>>> Fix Clang version detection.
>>>> We prepend "FreeBSD" to Clang version string.  This broke
>>>> compiler test
>>>> for
>>>> AVX instruction support.
>>> What about other software checking in similar fashion? imo the right
>>> fix is to stop mucking with the way clang reports itself
>> Maybe it would be better to not modify the start of the string.
>> Instead of
>> FreeBSD clang version 9.0.1 (git at
>> c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1)
>> maybe
>> clang version 9.0.1 for FreeBSD (git at
>> c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1)
> We have been doing this since, well, forever. And this way actually
> originates from upstream, we only define the CLANG_VENDOR macro. I see
> no reason to change this after all those years.
> A better question is, why these perl scripts "suddenly" started failing?
> Or have they also failed since forever, and it was only noticed now?

Ah, digging deeper it gets more interesting. All those scripts check
for "based on LLVM X.Y", a suffix printed for vendor builds. However,
that was dropped in as it's redundant,
thereby breaking this detection. So it's fallout from LLVM 10.

Also the scripts aren't failing in a sense, they just don't know what
compiler is in use so they fall back on not enabling AVX.


More information about the svn-src-all mailing list