similar to: [LLVMdev] [PATCH] 3.3 Release fix on ARM - atomics

Hi Rafael, As you mentioned in the bug, we should only apply this change when hard-float is set, which it is by default on armv7a, I presume. >From that part of the code, I can infer that by the time "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

On 13 May 2013 10:59, Renato Golin <renato.golin at linaro.org> wrote: > Hi Rafael, > > As you mentioned in the bug, we should only apply this change when > hard-float is set, which it is by default on armv7a, I presume. > > From that part of the code, I can infer that by the time > "MaxAtomicPromoteWidth = 64;", the variable SoftFloat is not properly set, >

> 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

Shouldn't you also support Thumb? And what about after v7 (e.g. v8) which AFAIK also supports these? On Mon, May 13, 2013 at 11:54 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

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

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

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

On 13 May 2013 19:54, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Renato, what do you think? I am currently building it on a chromebook > to make sure if fixes the bootstrap, but that will take some time. > There's also the test that fails, which I have in my patch. It should fail to you too. Maybe we should also test armv5 on your test, to make sure the

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,

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

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, i'm trying to make some experiments with the ARM backend (llvm 2.1) and therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. however, the llvm-gcc frontend seems to cause troubles with single precision floating point values, i.e., they are not converted correctly to the particular target format (double precision works as expected). it seems the problem is related to

hi, Dale Johannesen wrote: > On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: >> i'm trying to make some experiments with the ARM backend (llvm 2.1) >> and >> therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. >> >> however, the llvm-gcc frontend seems to cause troubles with single >> precision floating point values, i.e., they are

On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: > hi, > > i'm trying to make some experiments with the ARM backend (llvm 2.1) > and > therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. > > however, the llvm-gcc frontend seems to cause troubles with single > precision floating point values, i.e., they are not converted > correctly > to the

On 13 May 2013 18:38, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I know think we need something like the attached patch (with tests and > comments added). > I was afraid you were going to suggest that... ;) If that's the consensus, than I'll merge our patches, test and commit. cheers, --renato -------------- next part -------------- An HTML attachment was

> There's also the test that fails, which I have in my patch. It should fail > to you too. No, that test is using a bsd triple, so my patch doesn't change it. I don't know how the various BSDs implement this. > Maybe we should also test armv5 on your test, to make sure the behaviour > remains different (and documented). The current behavior (with and without the patch)

On 10 May 2013 16:21, Rafael Espí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

On Mon, 22 Oct 2007, Dale Johannesen wrote: > In principle I think keeping IEEE float and double in an endian- > independent form in the IR files is a good idea. BUT: I'm told > retaining the ability to use files in the existing format is a > requirement (so floats still need to occupy 8 bytes). Since ARM target > doesn't currently work that one is a reasonable

On Mar 21, 2011, at 3:44 AM, Anton Lokhmotov wrote: >> Adding half float to LLVM IR is *only* reasonable if you have hardware >> that supports half float, or if you want to add softfloat operations >> for these. > Yes, our graphics hardware natively supports some fp16 arithmetic > operations. Ok. >> Just like C compilers need to know sizeof(long), sizeof(void*) and

On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > The problem I've had is building an LLVM cross-compiler from Linux/ > x86 to Linux/ARM (as has another llvm-dev poster). Someone > mentioned to me off-list that he managed to get it to build, but I > haven't been able to reproduce the build using his instructions > (I'll post my results in another thread).