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

[Jessica Clarke]

On 26 Aug 2020, at 19:33, Dimitry Andric <dim at FreeBSD.org> wrote:
> 
> On 26 Aug 2020, at 19:13, Ian Lepore <ian at FreeBSD.org> wrote:
>> 
>> On Wed, 2020-08-26 at 19:04 +0200, Mateusz Guzik wrote:
>>> On 8/26/20, Jung-uk Kim <jkim at freebsd.org> wrote:
>>>> Author: jkim
>>>> Date: Wed Aug 26 16:55:28 2020
>>>> New Revision: 364822
>>>> URL: https://svnweb.freebsd.org/changeset/base/364822
>>>> 
>>>> 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 github.com:llvm/llvm-project.git
>> c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1)
>> 
>> maybe
>> 
>> clang version 9.0.1 for FreeBSD (git at github.com:llvm/llvm-project.git
>> 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 https://reviews.llvm.org/D69925 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.

Jess