svn commit: r354803 - in stable: 11/contrib/llvm/lib/Transforms/InstCombine 12/contrib/llvm/lib/Transforms/InstCombine

[Ronald Klop]

On Thu, 21 Nov 2019 20:07:46 +0100, Dimitry Andric <dim at freebsd.org> wrote:

> On 21 Nov 2019, at 16:06, Ronald Klop <ronald-lists at klop.ws> wrote:
>>
>> On Mon, 18 Nov 2019 08:04:59 +0100, Dimitry Andric <dim at freebsd.org>  
>> wrote:
>>> Author: dim
>>> Date: Mon Nov 18 07:04:59 2019
>>> New Revision: 354803
>>> URL: https://svnweb.freebsd.org/changeset/base/354803
>>>
>>> Log:
>>>  MFC r354724:
>>> Merge commit 5bbb604bb from llvm git (by Craig Topper):
>>>   [InstCombine] Disable some portions of foldGEPICmp for GEPs that
>>>    return a vector of pointers. Fix other portions.
>>>   llvm-svn: 370114
>>> This should fix instances of 'Assertion failed: (isa<X>(Val) &&
>>>  "cast<Ty>() argument of incompatible type!"), function cast, file
>>>  /usr/src/contrib/llvm/include/llvm/Support/Casting.h, line 255', when
>>>  building openjdk8 for aarch64 and armv7.
>>> Reported by:	jbeich
>>>  PR:		236566
>>>
>>
>>
>> Are there plans for an errata notice for releng-12.1 with this fix?  
>> That would keep Openjdk8 as a pkg on aarch64 after 12.0 goes EOL and  
>> pkgs will be build on 12.1.
>
> There should be no need for this, as release versions (and stable
> branches) have their copies of clang compiled with assertions disabled.
>
> Hence, the assertion reported in PR 236566 cannot occur, unless you have
> explicitly turned them on again and recompiled the toolchain components.
>
> I have tried compiling the original test case from the PR on both
> 12.0-RELEASE and 12.1-RELEASE.
>
> On 12.0-RELEASE, which has clang version 6.0.1 (tags/RELEASE_601/final
> 335540), it complains that the -fno-delete-null-pointer-checks and
> -faddrsig options are unknown, but this is to be expected.  The former
> was important to get the original assertion.  If I remove both those
> options, the test case compiles just fine.
>
> On 12.1-RELEASE, which has clang version 8.0.1 (tags/RELEASE_801/final
> 366581), the test case compiles just fine, out of the box.
>
> -Dimitry
>

Dimitry,

Thank you for testing and your quick answer.

Regards,
Ronald.