- User Since
- Apr 23 2019, 12:56 PM (112 w, 6 d)
Mar 11 2021
I want to apologize for missing such obvious things. Perhaps I used all of my observational power on my initial investigation. Of course it checks the triple for *hf and then the leading arch for arm, since that's how the property is added to the triple (*-eabihf)
Oh! Sorry, I glazed over that block and missed the set. I suspect that an architecture called '^arm.*hf$' doesn't cause issues in builtins specifically because it seems there's no special casing for anything besides 'armhf'
Mar 10 2021
This commit has broken our downstream toolchain builds which utilizes the llvm runtimes system to compile multiple sets of libraries with a just-built cross compiler.
Oct 14 2020
I believe our teams' downstream Darwin (cross compiler to ARM) builds are failing due to this commit:
Oct 6 2020
Aug 28 2020
Aug 21 2020
Aug 18 2020
This commit is causing build failures in my downstream ARM repository, as well as at least one buildbot (http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux)
Aug 4 2020
Abandoning in lieu of fix in D85215
Moved test to X86 subdirectory
Either of these options sounds good to me.
Aug 3 2020
I apologize for the constant early changes. I forget how phabricator catches and marks things as being referenced, so I was trying to get it to work.
This is a patch fix for D69384, which has broken ARM build bots. I present this as a band-aid since this feature and its test seems to be rather generic.
May 20 2020
May 15 2020
The problem here is the method we reset the variables in the cache back to their cached value.
May 13 2020
Actually, it's very fortuitous that you reminded of this review today.
When @phosek gets back to it, one of you would need to commit it on my behalf.
Apr 16 2020
Unfortunately I don't have commit access.
Could one of you get this onto the upstream?
Apr 15 2020
This commit broke our validations. Specifically, the tests in llvm/test/tools/opt-viewer
Mar 27 2020
@bkramer committed a fix for a crash in LegalizeFloatTypes where this operator appeared in SoftPromoteHalfResult
Jan 31 2020
Jan 30 2020
Jan 27 2020
Jan 23 2020
Moved option into a block guarded by COMPILER_RT_STANDLONE_BUILD, to indicate that it is an option that is available when not utilizing a linked LLVM toolchain and its configuration.
Jan 20 2020
Jan 17 2020
Updated to reflect master -> diff 2, rather than diff 1 -> diff 2
Confirmed that cmake correctly identifies '.S' as ASM, and uses CMAKE_ASM_FLAGS
Jan 13 2020
@phosek or really any other committer, could we get this onto master?
Dec 22 2019
Sadly, I do not have commit access. Could you do the honors @phosek ?
Dec 20 2019
This foreach loop goes over each variable, yes?
If so, then I'm not sure this change does what is required.
Dec 16 2019
Nov 18 2019
This commit has broken a few build bots.
Oct 11 2019
Sadly I'm home from the weekend, so I can't post more diffs for the renaming.
Here's a link to a github search though! I think this would be all the places: https://github.com/llvm/llvm-project/search?q=iterface&unscoped_q=iterface
Our team maintains a downstream embedded ARM clang distribution and some tests from this commit have begun to fail for us.
For a number of these tests, there was a REQUIRES: x86-registered-target at the top, which has now been removed. Specifically, externstatic.c, merge-conflict-test.c, object-float.c, and object.c are failing.
Sep 13 2019
Ah! My apologies. I had not pulled anything new down, as our process tends to hard-stop until an issue is resolved (something I'm thinking needs to be a little more flexible).
As mentioned in an inline comment, the test only works if the sizeof(int) != sizeof(int *) and sizeof(unsigned long long) == sizeof(int)
Aug 27 2019
Aug 23 2019
@arphaman you disabled this test on Windows, but did not specify exactly how it fails.
My team works on an embedded ARM compiler (most similar to arm-none-eabi), and we're now seeing failures from DependencyScannerTest. I can't find a buildbot failure for this test so I can't cross-reference to see if we have the same issue.
Aug 7 2019
In case you haven't seen, this commit breaks non-x86 build bots due to the combination of '-triple x86_64*' and '-S'. Some tests that use this target are only looking for AST dumps, and do not actually require such a target. This is not one of those tests, as it's inspecting assembly.
See clang/test/CodeGen/addrsig.c to see how that is handled (via REQUIRES: x86-registered-target).
Aug 5 2019
Our team independently applied and validated this change for our ARM cross compiler running on darwin, and we shared the same failure modes as the darwin compiler. I feel that this is sufficient evidence that the bug is related to the host, not the target.
Jul 26 2019
Jul 25 2019
Our team maintains a downstream embedded ARM cross compiler, and these tests are failing on our Mac validations.
The key problem here I believe is the 'XFAIL: darwin' doesn't seem to work how you expect it to, and I'm not aware of a good alternative that I can suggest. Hopefully you or someone else has one.
Jul 12 2019
Jul 9 2019
Oh dear... I apologize for that lapse of concentration. You are completely correct, someone had modified the signature in a prior commit, and I hadn't gone back far enough to see it.
Thank you for the response.
Maybe someone can enlighten me as to why the build bots aren't tripping up on this one, but our group is running into this when we pull this commit from the upstream:
Jun 3 2019
Hi Simon et. al., I'm working on a downstream ARM toolchain and have downstreamed this change into our codebase.
We saw that you've fixed the -mfpu=none issue and have taken that as well, but are still running into some issues.
Apr 26 2019
Closing this, as a fix has already been committed and validated on our end.
Apr 25 2019
I saw that too. Not really too thrilled with the fix itself, since it further fragments the source with directives, but it works.
I do have another question for @EricWF regarding the inclusion of unistd.h, but I should probably take that to a separate forum (though I've commented on the original review that added the inclusion).
Apr 24 2019
This is an example of a solution, but I'm not married to the mechanisms by which the results are achieved:
@EricWF is there an implicit expectation that all implementations based off libcxx/libcxxabi supports POSIX?
Our downstream ARM toolchain does not supply a unistd.h as part of its custom libc, and it has not been a problem until this revision.
Apr 23 2019
This commit has broken in our downstream tooling, which doesn't use the Microsoft ABI nor (I believe) has modified mangling in any way.