search for: maxatomicinlinewidth

...ndric 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...

...t; >> 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....

On Sun, Aug 5, 2018 at 5:49 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> 7.0.0-rc1 was just tagged (from the branch at r338847). >> >> It's early in the release process, but I'd like to find out what the >> status is of the branch

...ed 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...

...omicPromoteWidth = 64;", the variable SoftFloat is not properly set, > so a simple "if (!SoftFloat)" won't cut in there. It seems SoftFloat is > being set on HandleTargetFeatures() which is a virtual method, probably > called indirectly. Do you have a better place to set MaxAtomicInlineWidth = > 64? I have asked on #gcc what gcc does. I have posted a detailed description in the bug, but the summary is that there is some cooperation with the kernel going on that should make it safe to set MaxAtomicInlineWidth to 64 when targeting linux armv6 or newer. Hard float using it then just b...

...ime "MaxAtomicPromoteWidth = 64;", the variable SoftFloat is not properly set, so a simple "if (!SoftFloat)" won't cut in there. It seems SoftFloat is being set on HandleTargetFeatures() which is a virtual method, probably called indirectly. Do you have a better place to set MaxAtomicInlineWidth = 64? cheers, --renato On 13 May 2013 13:56, Renato Golin <renato.golin at linaro.org> wrote: > Identified a while before the release, there is an issue with 64-bit > atomics on ARM that was making Clang mis-compile a lot of code, including > Clang itself. > > http://llvm.o...

Identified a while before the release, there is an issue with 64-bit atomics on ARM that was making Clang mis-compile a lot of code, including Clang itself. http://llvm.org/bugs/show_bug.cgi?id=15429 Attached is a patch proposed by Benjamin with the corrections to the test. I'm not an expert on how Clang lowers C11 atomics, but the resulting IR seems correct, and after self-hosting Clang

> I have asked on #gcc what gcc does. I have posted a detailed > description in the bug, but the summary is that there is some > cooperation with the kernel going on that should make it safe to set > MaxAtomicInlineWidth to 64 when targeting linux armv6 or newer. Hard > float using it then just becomes a consequence of it implying armv7. > > I know think we need something like the attached patch (with tests and > comments added). OK. The attached patch has comments and a test. Renato, what do you thin...

...spíndola <rafael.espindola at gmail.com> wrote: > * In ABIs that don't use external functions for atomics (linux hard > float at least), we incorrectly decide to use function calls. > This seems to be the problem in my box, and Benjamin's hint did solve the problem (setting MaxAtomicInlineWidth). However, I'm not sure what relation that variable has to do with choosing library calls or not. If it's just a matter of variable sizes (allowing direct atomic calls on 64-bit VFP instructions), that it's possible that the fix is correct. I have applied it and Clang compiles code tha...

> This seems to be the problem in my box, and Benjamin's hint did solve the > problem (setting MaxAtomicInlineWidth). However, I'm not sure what relation > that variable has to do with choosing library calls or not. If it's just a > matter of variable sizes (allowing direct atomic calls on 64-bit VFP > instructions), that it's possible that the fix is correct. For the hard float ABI I think...

...AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > I have asked on #gcc what gcc does. I have posted a detailed > > description in the bug, but the summary is that there is some > > cooperation with the kernel going on that should make it safe to set > > MaxAtomicInlineWidth to 64 when targeting linux armv6 or newer. Hard > > float using it then just becomes a consequence of it implying armv7. > > > > I know think we need something like the attached patch (with tests and > > comments added). > > OK. The attached patch has comments and a te...

I think this is two bugs in one: * In ABIs that don't use external functions for atomics (linux hard float at least), we incorrectly decide to use function calls. * In ABIs that do use external function calls (non hard float linux?), we don't have code to actually generate the calls. See the thread in http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130415/078021.html. The

Hi Benjamin, Several people (including me) are hitting this bug on ARM: http://llvm.org/bugs/show_bug.cgi?id=15429 >From my investigations it happens on Ubuntu 12.10+ but not on 12.04. From Tom Gail's, it happens with --enable-optimized and doesn't without. You seem to have a clue on what that happens, can you shed some light on the matter? I see this error when self-hosting Clang