Page MenuHomePhabricator

JamesNagurne (James Nagurne)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 23 2019, 12:56 PM (16 w, 6 d)

Recent Activity

Wed, Aug 7

JamesNagurne added a comment to D60943: Delay diagnosing asm constraints that require immediates until after inlining.

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

Wed, Aug 7, 12:20 PM · Restricted Project, Restricted Project

Mon, Aug 5

JamesNagurne accepted D65745: [llvm-ar][test] Correct tests marked as expected fails.

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.

Mon, Aug 5, 8:45 AM · Restricted Project

Fri, Jul 26

JamesNagurne added a comment to D64802: [llvm-ar][test] Add tests failing on Darwin.

Hi James,

From my understanding these has been resolving correctly as XFAIL's on upstream Darwin test machines and XFAIL: darwin is used in a few other lit tests. I do not know what cross compiling is tested on the build bots however.

Firstly, does use of XFAIL: system-darwin instead of XFAIL: darwin fix this issue?

Second can you run any of the llvm tests below on your machine and get the expected result? They all use XFAIL: darwin:

  • test\DebugInfo\Generic\empty.ll
  • test\DebugInfo\Generic\gmlt.test
  • test\ExecutionEngine\MCJIT\test-global-ctors.ll
  • test\ExecutionEngine\OrcMCJIT\test-global-ctors.ll

    Finally I believe lit just uses the standard python commands to determine the platform, do the commands below give unexpected output?
import sys
import platform
print(platform.system())
print(sys.platform)

Hopefully this will make finding the cause of the issue easier. If anyone else has suggestions I would be happy to hear them.

Thanks

Fri, Jul 26, 1:50 PM · Restricted Project

Thu, Jul 25

JamesNagurne added a comment to D64802: [llvm-ar][test] Add tests failing on Darwin.

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.

Thu, Jul 25, 9:08 AM · Restricted Project

Jul 12 2019

JamesNagurne added a comment to D64653: clang/test/Driver/fsanitize.c: Fix -fsanitize=vptr using default target.

I committed this for you in rL365981 (it may have broken a Windows build for a long time. I wanted to fix it soon..). Thanks!

any platform that runs this test will fail with the error:

Not-too-ancient Darwin, FreeBSD, Linux, NetBSD, OpenBSD, Solaris, etc support this, but notable exception is Windows:

% clang -target x86_64-windows -fsanitize=vptr -fno-rtti fsanitize.c '-###'
clang-9: error: unsupported option '-fsanitize=vptr' for target 'x86_64-unknown-windows-msvc'
Jul 12 2019, 10:49 PM · Restricted Project
JamesNagurne created D64653: clang/test/Driver/fsanitize.c: Fix -fsanitize=vptr using default target.
Jul 12 2019, 11:25 AM · Restricted Project
JamesNagurne added a comment to rL365872: test/Driver/fsanitize.c: delete -target x86_64-linux-gnu from tests that should….
Jul 12 2019, 11:10 AM

Jul 9 2019

JamesNagurne added a comment to D61694: Boilerplate for producing XCOFF object files from the PowerPC backend..

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.

Jul 9 2019, 3:05 PM · Restricted Project
JamesNagurne added a comment to D61694: Boilerplate for producing XCOFF object files from the PowerPC backend..

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:

Jul 9 2019, 1:39 PM · Restricted Project

Jun 3 2019

JamesNagurne added a comment to D60691: [ARM] Replace fp-only-sp and d16 with fp64 and d32..

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.

Jun 3 2019, 2:57 PM · Restricted Project, Restricted Project

Apr 26 2019

JamesNagurne abandoned D61087: [libcxxabi] Fix build of cxa_guard.cpp on configurations with _LIBCXXABI_HAS_NO_THREADS.

Closing this, as a fix has already been committed and validated on our end.

Apr 26 2019, 10:32 AM · Restricted Project

Apr 25 2019

JamesNagurne added a comment to D61087: [libcxxabi] Fix build of cxa_guard.cpp on configurations with _LIBCXXABI_HAS_NO_THREADS.

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 25 2019, 11:23 AM · Restricted Project
JamesNagurne added inline comments to D61087: [libcxxabi] Fix build of cxa_guard.cpp on configurations with _LIBCXXABI_HAS_NO_THREADS.
Apr 25 2019, 8:57 AM · Restricted Project

Apr 24 2019

JamesNagurne added a comment to D61087: [libcxxabi] Fix build of cxa_guard.cpp on configurations with _LIBCXXABI_HAS_NO_THREADS.

This is an example of a solution, but I'm not married to the mechanisms by which the results are achieved:

Apr 24 2019, 1:14 PM · Restricted Project
JamesNagurne created D61087: [libcxxabi] Fix build of cxa_guard.cpp on configurations with _LIBCXXABI_HAS_NO_THREADS.
Apr 24 2019, 1:09 PM · Restricted Project
JamesNagurne added a comment to rG70ebeabfb833: Rewrite cxa guard implementation..

@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 24 2019, 11:35 AM

Apr 23 2019

JamesNagurne added a comment to rG27df40920369: MS ABI: Support mangling op<=> now that MSVC 2019 has a mangling.

This commit has broken in our downstream tooling, which doesn't use the Microsoft ABI nor (I believe) has modified mangling in any way.

Apr 23 2019, 1:03 PM