[Openmp-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Hans Wennborg via Openmp-dev]

On Wed, Aug 22, 2018 at 10:33 PM, Dimitry Andric <dimitry at andric.com> wrote:
> On 22 Aug 2018, at 18:45, Hans Wennborg <hans at chromium.org> wrote:
>>
>> On Wed, Aug 22, 2018 at 3:48 AM, Dimitry Andric <dimitry at andric.com> wrote:
>>> On 22 Aug 2018, at 05:58, Wei Mi <wmi at google.com> wrote:
>>>>
>>>> On Fri, Aug 17, 2018 at 1:27 PM, Dimitry Andric <dimitry at andric.com> wrote:
>>>> On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>>> On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote:
>>>>>> This is a regression caused by https://reviews.llvm.org/rL323281:
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> r323281 | wmi | 2018-01-23 23:27:57 +0000 (Tue, 23 Jan 2018) | 12 lines
>>>>>>
>>>>>> Adjust MaxAtomicInlineWidth for i386/i486 targets.
>>>>>>
>>>>>> This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
>>>>>> Currently, all  MaxAtomicInlineWidth of x86-32 targets are set to 64. However,
>>>>>> i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg.
>>>>>> So in this patch MaxAtomicInlineWidth is reset as follows:
>>>>>> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported.
>>>>>> For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg.
>>>>>> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b.
>>>>>
>>>>> This seems to be somewhat undesirable. Does *anyone* care about real
>>>>> i386 support at this point? NetBSD certainly doesn't and I think we are
>>>>> already the odd man for a number of cases like this.
>>>>
>>>>
>>>> Yes, and since this causes quite a number of regressions for us, I would
>>>> really prefer this revision to be reverted, at least in the 7.0.0
>>>> branch.  I have already reverted it locally in our FreeBSD project
>>>> branch for importing llvm/clang 7.0.0.  Hans, what is your opinion about
>>>> this?
>>>>
>>>> -Dimitry
>>>>
>>>>
>>>> Sorry I missed the thread for quite a while. Dimitry, I am very confused because you reported the issue in https://bugs.llvm.org/show_bug.cgi?id=34347#c6, so you want r323281 to be reverted and let llvm to generate cmxchg8b instruction for i486?
>>>
>>> Since it's been doing this for a number of years now, I don't think it would be bad at all, at least not for FreeBSD.  At least, a lot more effort is needed to supply properly working atomic libcalls for 64 bit values on i386.  (They can't be implemented without at least a bit of kernel assistance.)
>>
>> According to the release schedule we should tag RC2 today. Do you
>> think there's any chance of getting this figured out by today?
>
> Since I'm testing on FreeBSD 11.x, and that will take quite a while to get any new changes, I'd say it's safer to revert for now, at least on the branch.  At least then I can build and test the RCs on i386-freebsd. :)

I've reverted on trunk in r340666 and merged to the 7.0 branch in
r340667. Also +Craig fyi for X86.

Unfortunately this happened after RC2 which was tagged yesterday, but
perhaps you can do a test run against the tip of the branch, and then
later RC3 of coures?

Also, is there a bug filed somewhere to track fixing the FreeBSD side?
It would be great if we could reinstate this patch again before the
next release.

Thanks,
Hans