- User Since
- Apr 23 2019, 12:56 PM (16 w, 6 d)
Wed, Aug 7
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).
Mon, Aug 5
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.
Fri, Jul 26
Thu, Jul 25
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.