Page MenuHomePhabricator

JamesNagurne (James Nagurne)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 23 2019, 12:56 PM (160 w, 5 d)

Recent Activity

Mar 6 2022

JamesNagurne added inline comments to D114786: [libc++] Remove the ability to use the std::nullptr_t emulation in C++03 mode.
Mar 6 2022, 3:14 PM · Restricted Project, Restricted Project

Mar 4 2022

JamesNagurne added inline comments to D114786: [libc++] Remove the ability to use the std::nullptr_t emulation in C++03 mode.
Mar 4 2022, 12:58 PM · Restricted Project, Restricted Project

Feb 24 2022

JamesNagurne added a comment to D114786: [libc++] Remove the ability to use the std::nullptr_t emulation in C++03 mode.

Hi Louis,

Feb 24 2022, 12:49 PM · Restricted Project, Restricted Project
JamesNagurne added inline comments to rG6d58f4ab071e: [MachineOutliner] NFC: Hide LRU-related stuff behind helper functions.
Feb 24 2022, 12:29 PM
JamesNagurne added inline comments to rG6d58f4ab071e: [MachineOutliner] NFC: Hide LRU-related stuff behind helper functions.
Feb 24 2022, 11:24 AM

Feb 23 2022

JamesNagurne added inline comments to rG6d58f4ab071e: [MachineOutliner] NFC: Hide LRU-related stuff behind helper functions.
Feb 23 2022, 11:25 PM
JamesNagurne updated subscribers of rG6d58f4ab071e: [MachineOutliner] NFC: Hide LRU-related stuff behind helper functions.

https://reviews.llvm.org/D100704

Feb 23 2022, 3:57 PM

Feb 15 2022

JamesNagurne added a comment to rGa1862d78eb45: Set LLVM_FORCE_USE_OLD_TOOLCHAIN to disable VS2019 checks.

Hi, I'm actually wondering how this is working for anyone.

Feb 15 2022, 1:12 PM

Dec 6 2021

JamesNagurne committed rGcc3bb8558018: [llvm][Hexagon] Generalize VLIWResourceModel, VLIWMachineScheduler, and… (authored by JamesNagurne).
[llvm][Hexagon] Generalize VLIWResourceModel, VLIWMachineScheduler, and…
Dec 6 2021, 2:24 PM
JamesNagurne closed D113150: Lift VLIWResourceModel, VLIWMachineScheduler, and ConvergingVLIWScheduler into CodeGen/VLIWMachineScheduler.
Dec 6 2021, 2:24 PM · Restricted Project
JamesNagurne updated the diff for D113150: Lift VLIWResourceModel, VLIWMachineScheduler, and ConvergingVLIWScheduler into CodeGen/VLIWMachineScheduler.

Updating diff to most recent: Want to see if CI actually starts working..

Dec 6 2021, 11:36 AM · Restricted Project

Nov 19 2021

JamesNagurne committed rG241df03ce5f0: [NFC] Test commit, add whitespace to end-of-line (authored by JamesNagurne).
[NFC] Test commit, add whitespace to end-of-line
Nov 19 2021, 4:23 PM

Nov 17 2021

JamesNagurne added inline comments to D113150: Lift VLIWResourceModel, VLIWMachineScheduler, and ConvergingVLIWScheduler into CodeGen/VLIWMachineScheduler.
Nov 17 2021, 1:50 PM · Restricted Project
JamesNagurne updated the diff for D113150: Lift VLIWResourceModel, VLIWMachineScheduler, and ConvergingVLIWScheduler into CodeGen/VLIWMachineScheduler.

Apologies. I uploaded the full diff again, rather than the refinement I wanted to.

Nov 17 2021, 1:44 PM · Restricted Project
JamesNagurne updated the diff for D113150: Lift VLIWResourceModel, VLIWMachineScheduler, and ConvergingVLIWScheduler into CodeGen/VLIWMachineScheduler.
  • Made ViewMISChedDAG a global option to match ForceTopDown et al.
  • Optimized includes in VLIWMachineScheduler.h
  • Replaced vectors in VLIWMachineScheduler.h with SmallVector
  • Ran clang-format on all changes, which includes the entirety of the VLIWMachineScheduler files, as they are treated as 'new' files
Nov 17 2021, 1:41 PM · Restricted Project

Nov 9 2021

JamesNagurne added a comment to D110261: [libc++][release] Do not force building the runtimes with -fPIC.

As-is, this patch will have the unintended effect that Clang and the
LLVM libraries (not only the runtime ones like libc++) will also be
built with -fPIC in the release.

Nov 9 2021, 11:12 AM · Restricted Project, Restricted Project, Restricted Project, Restricted Project
JamesNagurne added a comment to D113150: Lift VLIWResourceModel, VLIWMachineScheduler, and ConvergingVLIWScheduler into CodeGen/VLIWMachineScheduler.

I committed a small patch (https://reviews.llvm.org/rGa721ddbae983), it changes releaseTopNode and releaseBottomNode, you'll need to rebase before merging.

Performance tests look ok.

Thanks!

Nov 9 2021, 10:49 AM · Restricted Project

Nov 4 2021

JamesNagurne added inline comments to D113150: Lift VLIWResourceModel, VLIWMachineScheduler, and ConvergingVLIWScheduler into CodeGen/VLIWMachineScheduler.
Nov 4 2021, 11:24 AM · Restricted Project

Nov 3 2021

JamesNagurne added a comment to D113150: Lift VLIWResourceModel, VLIWMachineScheduler, and ConvergingVLIWScheduler into CodeGen/VLIWMachineScheduler.

Comments for review added.

Nov 3 2021, 3:52 PM · Restricted Project
JamesNagurne added a comment to D113150: Lift VLIWResourceModel, VLIWMachineScheduler, and ConvergingVLIWScheduler into CodeGen/VLIWMachineScheduler.

This review is not yet formatted, but I'll upload a formatted version prior to commit once we find the changes sufficient. I wanted to avoid unrelated code changes from being injected into the review.

Nov 3 2021, 3:39 PM · Restricted Project
JamesNagurne requested review of D113150: Lift VLIWResourceModel, VLIWMachineScheduler, and ConvergingVLIWScheduler into CodeGen/VLIWMachineScheduler.
Nov 3 2021, 3:37 PM · Restricted Project

Sep 29 2021

JamesNagurne accepted D110673: [clang] Don't modify OptRemark if the argument is not relevant.
Sep 29 2021, 2:23 PM · Restricted Project
JamesNagurne added a comment to D110673: [clang] Don't modify OptRemark if the argument is not relevant.

You're welcome! Surprising that no downstream clang was running with the old PM and assertions...

Sep 29 2021, 2:22 PM · Restricted Project
JamesNagurne added a comment to D110673: [clang] Don't modify OptRemark if the argument is not relevant.

Perhaps you could reproduce my error -round-trip-args on the -cc1 command line?

Sep 29 2021, 1:05 PM · Restricted Project
JamesNagurne added a comment to D110673: [clang] Don't modify OptRemark if the argument is not relevant.

The trigger for the remark I'm seeing is llvm::shouldInline in InlineAdvisor.cpp ((https://github.com/llvm/llvm-project/blob/2240deb9766cc080b351016b0d7f975d7249b113/llvm/lib/Transforms/IPO/Inliner.cpp#L425) which is called in a top-level AlwaysInlinerLegacyPass

Sep 29 2021, 1:03 PM · Restricted Project
JamesNagurne added a comment to D110673: [clang] Don't modify OptRemark if the argument is not relevant.

I'll take a quick look tomorrow, but the general idea is that on calling ParseOptimizationRemark on line 1909 with a -cc1 command line containing -Rpass=inline -Rno-pass, Opts.OptimizationRemarkMissed and Opts.OptimizationRemarkAnalysis are set to valid patterns (Regex is ".*", Pattern is "", and Kind is RK_Missing). This happens around line 1909 in the change set.

Sep 29 2021, 12:25 AM · Restricted Project

Sep 28 2021

JamesNagurne added a comment to rGe1ed02181ffc: [clang] Make -Rpass imply -Rpass=.*.
Sep 28 2021, 2:28 PM
JamesNagurne added a comment to rGe1ed02181ffc: [clang] Make -Rpass imply -Rpass=.*.

Have they added a way to do that? I recall there being some discussions, but as far as I know, I'd have to XFAIL the whole test, not just specific lines.
Either way, this isn't a blocking issue on our end. I just wanted to bring it up in case someone else has the same problem and can see from where it originates.

Sep 28 2021, 2:22 PM
JamesNagurne added a comment to rGe1ed02181ffc: [clang] Make -Rpass imply -Rpass=.*.

I don't think that -Rpass turns on pass-misses/analysis, that'd be -Rpass-analysis/-Rpass-missed.

Sep 28 2021, 7:01 AM

Sep 27 2021

JamesNagurne added a comment to rGe1ed02181ffc: [clang] Make -Rpass imply -Rpass=.*.

Pass manager problems? That crossed my mind because we have been slow on the uptake of the new PM, but seeing the behavior in the clang function made me believe that it couldn't have been the case. Wouldn't just making -Rpass not turn on pass-misses and pass-analysis solve the issue?

Sep 27 2021, 8:21 PM
JamesNagurne raised a concern with rGe1ed02181ffc: [clang] Make -Rpass imply -Rpass=.*.

In this commit, our team is seeing a failure in the optimization_remark.c test you modified, but not on a line you changed. The failure occurs on line 16, and I'm trying to understand why other upstream targets aren't seeing the same.
The relevant command line options are:

Sep 27 2021, 3:56 PM

Sep 22 2021

JamesNagurne updated subscribers of D110261: [libc++][release] Do not force building the runtimes with -fPIC.

Adding relevant people from my team.

Sep 22 2021, 10:21 AM · Restricted Project, Restricted Project, Restricted Project, Restricted Project

Aug 10 2021

JamesNagurne updated subscribers of D107838: [CSSPGO] Do not use getCanonicalFnName in pseudo probe descriptor decoding.
Aug 10 2021, 9:12 AM · Restricted Project

Jul 30 2021

JamesNagurne added a comment to D104328: [libc++] Always build libc++ and libc++abi with -fPIC.

Hi all,

Jul 30 2021, 12:31 PM · Restricted Project, Restricted Project, Restricted Project

Jul 2 2021

JamesNagurne added a comment to D105310: Mark SRet argument as pointer in SelectionDAGISel::LowerArguments.

I suspect this affects arm64_32, at least in terms of the generated SelectionDAG.

Jul 2 2021, 11:41 AM · Restricted Project

Jul 1 2021

JamesNagurne updated the summary of D105310: Mark SRet argument as pointer in SelectionDAGISel::LowerArguments.
Jul 1 2021, 12:48 PM · Restricted Project
JamesNagurne requested review of D105310: Mark SRet argument as pointer in SelectionDAGISel::LowerArguments.
Jul 1 2021, 12:48 PM · Restricted Project

Mar 11 2021

JamesNagurne added a comment to rG8bd2722f65cf: [compiler-rt] Normalize i?86 to i386 and armv* to arm for….

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)

Mar 11 2021, 1:36 PM
JamesNagurne added a comment to rG8bd2722f65cf: [compiler-rt] Normalize i?86 to i386 and armv* to arm for….

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 11 2021, 12:49 PM
JamesNagurne added a comment to rG8bd2722f65cf: [compiler-rt] Normalize i?86 to i386 and armv* to arm for….

The toplevel CMakeLists also does happen to have such a case though, see https://github.com/llvm/llvm-project/blob/main/compiler-rt/CMakeLists.txt#L111-L114. IMO that also would lose all the details between various arm architecture variants. But maybe that just doesn't trigger for ones that are sensitive enough for the distinction to matter?

Mar 11 2021, 12:37 PM
JamesNagurne added a comment to rG8bd2722f65cf: [compiler-rt] Normalize i?86 to i386 and armv* to arm for….

I'm sorry about that. Do I guess correctly that you're building with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR enabled, as otherwise, clang would just look for all files in the same directory, and expect all of them to be named libclang_rt.builtins-arm.a or something like that? In such a setup, I guess that one doesn't want the normalization - but I hadn't really expect it to break anything either.

Mar 11 2021, 10:20 AM

Mar 10 2021

JamesNagurne updated subscribers of rG8bd2722f65cf: [compiler-rt] Normalize i?86 to i386 and armv* to arm for….

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.

Mar 10 2021, 3:07 PM

Oct 14 2020

JamesNagurne added a comment to D88977: Reapply [ADT] function_ref's constructor is unavailable if the argument is not callable..

I believe our teams' downstream Darwin (cross compiler to ARM) builds are failing due to this commit:

Oct 14 2020, 2:17 PM · Restricted Project

Oct 6 2020

JamesNagurne added a comment to D88767: Show register names in DWARF unwind info..

In llvm/test/DebugInfo/dwarfdump-debug-frame-simple.test

Oct 6 2020, 2:10 PM · Restricted Project

Aug 28 2020

JamesNagurne added a comment to D53005: Implement machine unroller utility class.

I am working on an out of tree target and this would be useful.
So what is the status of this patch?

Aug 28 2020, 1:39 PM

Aug 21 2020

JamesNagurne added a comment to D83174: Teach AttachPreviousImpl to inherit MSInheritanceAttr attribute.

Unfortunately, I had to revert the change as it was causing some buildbots to fail. I reverted in 58c305f466d1f78adb10e7295b9bc9fc192a6e09. Some failures include:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/20294
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/13600

I'm not certain why b.h is not being found by those builders. Do you mind investigating?

Aug 21 2020, 10:03 AM · Restricted Project

Aug 18 2020

JamesNagurne added a comment to rG04a6ea5d77e7: [GlobalISel] Add a combine for sext_inreg(load x), c --> sextload x.

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)

The errors seem to stem from the std::tuple implementation. Could it be that the buildbot and my downstream are using older, unsupported library implementations?

Could be, but I'm not certain. In any case, I've just changed them to use std::make_tuple now instead in ed353445248.

Aug 18 2020, 2:58 PM
JamesNagurne added a comment to rG04a6ea5d77e7: [GlobalISel] Add a combine for sext_inreg(load x), c --> sextload x.

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 18 2020, 12:49 PM

Aug 4 2020

JamesNagurne abandoned D85148: Fix ARM build bots failures due to disabled x86_64-apple target.

Abandoning in lieu of fix in D85215

Aug 4 2020, 8:57 AM · Restricted Project
JamesNagurne updated the diff for D85148: Fix ARM build bots failures due to disabled x86_64-apple target.

Moved test to X86 subdirectory

Aug 4 2020, 6:12 AM · Restricted Project
JamesNagurne added a comment to D85148: Fix ARM build bots failures due to disabled x86_64-apple target.

Either of these options sounds good to me.

Aug 4 2020, 6:07 AM · Restricted Project

Aug 3 2020

JamesNagurne added a comment to D85148: Fix ARM build bots failures due to disabled x86_64-apple target.

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.

Aug 3 2020, 12:12 PM · Restricted Project
JamesNagurne updated the summary of D85148: Fix ARM build bots failures due to disabled x86_64-apple target.
Aug 3 2020, 12:09 PM · Restricted Project
JamesNagurne set the repository for D85148: Fix ARM build bots failures due to disabled x86_64-apple target to rG LLVM Github Monorepo.
Aug 3 2020, 12:09 PM · Restricted Project
JamesNagurne requested review of D85148: Fix ARM build bots failures due to disabled x86_64-apple target.
Aug 3 2020, 12:08 PM · Restricted Project
JamesNagurne added a comment to D69384: [HotColdSplit] Add unlikely attribute to outlined function.

This test case has been failing on many of the ARM and AArch64 bots all weekend, e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/19408, would you mind looking into this?

Here's the log of one of the failures (from http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/19408/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Acoldentrycount.ll):

******************** TEST 'LLVM :: Transforms/HotColdSplit/coldentrycount.ll' FAILED ********************
Script:
--
: 'RUN: at line 4';   /home/tcwg-buildslave/worker/clang-cmake-armv7-quick/stage1/bin/opt -hotcoldsplit -hotcoldsplit-threshold=0 -codegenprepare -S < /home/tcwg-buildslave/worker/clang-cmake-armv7-quick/llvm/llvm/test/Transforms/HotColdSplit/coldentrycount.ll | /home/tcwg-buildslave/worker/clang-cmake-armv7-quick/stage1/bin/FileCheck /home/tcwg-buildslave/worker/clang-cmake-armv7-quick/llvm/llvm/test/Transforms/HotColdSplit/coldentrycount.ll
--
Exit Code: 2

Command Output (stderr):
--
LLVM ERROR: Trying to construct TargetPassConfig without a target machine. Scheduling a CodeGen pass without a target triple set?
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /home/tcwg-buildslave/worker/clang-cmake-armv7-quick/stage1/bin/opt -hotcoldsplit -hotcoldsplit-threshold=0 -codegenprepare -S 
FileCheck error: '<stdin>' is empty.
FileCheck command line:  /home/tcwg-buildslave/worker/clang-cmake-armv7-quick/stage1/bin/FileCheck /home/tcwg-buildslave/worker/clang-cmake-armv7-quick/llvm/llvm/test/Transforms/HotColdSplit/coldentrycount.ll

--

********************
Aug 3 2020, 10:18 AM · Restricted Project

May 20 2020

JamesNagurne added a comment to D72947: [CMake] llvm/runtimes: Do not override LLVM_* variables with just-built LLVM configurations.

Sorry for being late to the party on this.

There's really only a handful of variables in LLVMConfig.cmake that can actually be different between LLVM and the project using LLVM. Might it make sense to just handle those as special? We already do handle LLVM_PTHREAD_LIB specially for exactly the same reason you describe in the description.

May 20 2020, 11:27 AM · Restricted Project

May 15 2020

JamesNagurne abandoned D72947: [CMake] llvm/runtimes: Do not override LLVM_* variables with just-built LLVM configurations.

The problem here is the method we reset the variables in the cache back to their cached value.

May 15 2020, 9:45 AM · Restricted Project

May 13 2020

JamesNagurne added a comment to D72947: [CMake] llvm/runtimes: Do not override LLVM_* variables with just-built LLVM configurations.

Actually, it's very fortuitous that you reminded of this review today.

May 13 2020, 4:24 PM · Restricted Project
JamesNagurne added a comment to D72947: [CMake] llvm/runtimes: Do not override LLVM_* variables with just-built LLVM configurations.

When @phosek gets back to it, one of you would need to commit it on my behalf.

May 13 2020, 3:51 PM · Restricted Project

Apr 16 2020

JamesNagurne added a comment to D78241: Fix opt-viewer tests failing after move from cgi.escape to html.escape.

Unfortunately I don't have commit access.
Could one of you get this onto the upstream?

Apr 16 2020, 1:23 PM · Restricted Project

Apr 15 2020

JamesNagurne created D78241: Fix opt-viewer tests failing after move from cgi.escape to html.escape.
Apr 15 2020, 1:46 PM · Restricted Project
JamesNagurne added a comment to rG4b428e8f18c7: Convert old python3 cgi method into the new html one.

This commit broke our validations. Specifically, the tests in llvm/test/tools/opt-viewer

Apr 15 2020, 1:46 PM
JamesNagurne created D78229: Pass system PYTHONPATH into lit-spawned shells.
Apr 15 2020, 12:04 PM · Restricted Project

Mar 27 2020

JamesNagurne updated subscribers of D29014: [SelDag] Add FREEZE.

@bkramer committed a fix for a crash in LegalizeFloatTypes where this operator appeared in SoftPromoteHalfResult

Mar 27 2020, 1:10 PM · Restricted Project

Jan 31 2020

JamesNagurne added a comment to D72950: [CMake] compiler-rt: Add COMPILER_RT_BUILTINS_ENABLE_PIC.

Thanks @phosek

Jan 31 2020, 4:07 PM · Restricted Project, Restricted Project

Jan 30 2020

JamesNagurne added a comment to D72947: [CMake] llvm/runtimes: Do not override LLVM_* variables with just-built LLVM configurations.

This looks reasonable to me, @smeenai & @beanz do you see any problem with this?

Jan 30 2020, 1:38 PM · Restricted Project

Jan 27 2020

JamesNagurne added a comment to D72952: [libunwind] Set LIBUNWIND_ASM_SOURCES to the ASM source language from C.

This broke my build, for both mingw and linux, with both cmake 3.10.2 and 3.16.2 - the assembly files don't get built at all. Reproducible on linux with a plain "cmake .." (in llvm-project/libunwind/build) without further args.

Is some custom build config needed for this to work?

Ok, so it seems this works when built via the main llvm cmakefile, but not standalone. So I guess the libunwind cmakefiles needs some extras for hooking this up, that are included only when built standalone.

I fixed this in https://reviews.llvm.org/rG0e0c65264aeb6f66b6f711884c55cdbf66d975f6, but building assembly files as assembly instead of C breaks building for mingw, for which I sent an additional patch at D73436, essentially conditionally reverting this change for mingw targets.

Jan 27 2020, 11:07 AM · Restricted Project

Jan 23 2020

JamesNagurne updated the diff for D72950: [CMake] compiler-rt: Add COMPILER_RT_BUILTINS_ENABLE_PIC.

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 23 2020, 2:01 PM · Restricted Project, Restricted Project

Jan 20 2020

JamesNagurne added inline comments to D72950: [CMake] compiler-rt: Add COMPILER_RT_BUILTINS_ENABLE_PIC.
Jan 20 2020, 11:12 AM · Restricted Project, Restricted Project

Jan 17 2020

JamesNagurne updated the diff for D72952: [libunwind] Set LIBUNWIND_ASM_SOURCES to the ASM source language from C.

Updated to reflect master -> diff 2, rather than diff 1 -> diff 2

Jan 17 2020, 3:49 PM · Restricted Project
JamesNagurne added a comment to D72952: [libunwind] Set LIBUNWIND_ASM_SOURCES to the ASM source language from C.

The diff here looks weird ... it looks like a diff against your previous diff instead of a diff against master? (Phabricator says the line you're deleting has LANGUAGE ASM instead of LANGUAGE C, as it does on master.)

Jan 17 2020, 3:49 PM · Restricted Project
JamesNagurne updated the diff for D72952: [libunwind] Set LIBUNWIND_ASM_SOURCES to the ASM source language from C.

Confirmed that cmake correctly identifies '.S' as ASM, and uses CMAKE_ASM_FLAGS

Jan 17 2020, 2:15 PM · Restricted Project
JamesNagurne added a reviewer for D72950: [CMake] compiler-rt: Add COMPILER_RT_BUILTINS_ENABLE_PIC: phosek.
Jan 17 2020, 2:05 PM · Restricted Project, Restricted Project
JamesNagurne added a reviewer for D72951: [CMake] Handle 'Generic' system in HandleLLVMOptions.cmake: phosek.
Jan 17 2020, 2:05 PM · Restricted Project
JamesNagurne added a reviewer for D72947: [CMake] llvm/runtimes: Do not override LLVM_* variables with just-built LLVM configurations: phosek.
Jan 17 2020, 2:05 PM · Restricted Project
JamesNagurne added a reviewer for D72952: [libunwind] Set LIBUNWIND_ASM_SOURCES to the ASM source language from C: phosek.
Jan 17 2020, 2:05 PM · Restricted Project
JamesNagurne added a reviewer for D72947: [CMake] llvm/runtimes: Do not override LLVM_* variables with just-built LLVM configurations: chandlerc.
Jan 17 2020, 1:07 PM · Restricted Project
JamesNagurne added a reviewer for D72952: [libunwind] Set LIBUNWIND_ASM_SOURCES to the ASM source language from C: chandlerc.
Jan 17 2020, 1:07 PM · Restricted Project
JamesNagurne added a reviewer for D72951: [CMake] Handle 'Generic' system in HandleLLVMOptions.cmake: chandlerc.
Jan 17 2020, 1:07 PM · Restricted Project
JamesNagurne added a reviewer for D72950: [CMake] compiler-rt: Add COMPILER_RT_BUILTINS_ENABLE_PIC: chandlerc.
Jan 17 2020, 1:07 PM · Restricted Project, Restricted Project
JamesNagurne created D72952: [libunwind] Set LIBUNWIND_ASM_SOURCES to the ASM source language from C.
Jan 17 2020, 12:56 PM · Restricted Project
JamesNagurne created D72951: [CMake] Handle 'Generic' system in HandleLLVMOptions.cmake.
Jan 17 2020, 12:47 PM · Restricted Project
JamesNagurne created D72950: [CMake] compiler-rt: Add COMPILER_RT_BUILTINS_ENABLE_PIC.
Jan 17 2020, 12:47 PM · Restricted Project, Restricted Project
JamesNagurne created D72947: [CMake] llvm/runtimes: Do not override LLVM_* variables with just-built LLVM configurations.
Jan 17 2020, 12:38 PM · Restricted Project

Jan 13 2020

JamesNagurne added a comment to D71570: [CMake] Prefer multi-target variables over generic target variables in runtimes build.

@phosek or really any other committer, could we get this onto master?

Jan 13 2020, 2:30 PM · Restricted Project

Dec 22 2019

JamesNagurne added a comment to D71570: [CMake] Prefer multi-target variables over generic target variables in runtimes build.

Sadly, I do not have commit access. Could you do the honors @phosek ?

Dec 22 2019, 1:54 PM · Restricted Project

Dec 20 2019

JamesNagurne added a comment to D71570: [CMake] Prefer multi-target variables over generic target variables in runtimes build.

I'm fine with this change in general, but I'm concerned that no matter what order we choose, this might break users who rely on the opposite order. Maybe it'd be better to modify the logic to skip the second loop if the first loop matches, that way we wouldn't rely on any particular order.

Dec 20 2019, 1:25 PM · Restricted Project
JamesNagurne added a comment to D71737: [CMake][runtimes] Skip the generic target variable if named matches.

This foreach loop goes over each variable, yes?
If so, then I'm not sure this change does what is required.

Dec 20 2019, 1:25 PM · Restricted Project

Dec 16 2019

JamesNagurne created D71570: [CMake] Prefer multi-target variables over generic target variables in runtimes build.
Dec 16 2019, 2:16 PM · Restricted Project

Nov 18 2019

JamesNagurne added a comment to rG8f8a9f3437d4: implement printing out raw section data of xcoff objectfile for llvm-objdump.

This commit has broken a few build bots.

Nov 18 2019, 3:04 PM

Oct 11 2019

JamesNagurne added a comment to D68897: [clang][ifs] Avoid assumption of default visibility in InterfaceStubs tests.

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

Oct 11 2019, 6:23 PM · Restricted Project
JamesNagurne created D68897: [clang][ifs] Avoid assumption of default visibility in InterfaceStubs tests.
Oct 11 2019, 4:23 PM · Restricted Project
JamesNagurne added a comment to D63978: Clang Interface Stubs merger plumbing for Driver.

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.

object* tests seem to be based on object.cpp, which had the REQUIRES line, and externstatic.c also had that line prior to the change.
I see that @compnerd suggested the removal, but were you certain that these tests would work on clang toolchains for which x86 is not a registered target?

For a failure example, here the output of lit for our toolchain. If you can make sense of it, I'd appreciate input on how we can fix or work around it:

> <WORKDIR>/arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c | <WORKDIR>/arm-llvm/Release/llvm/bin/FileCheck -check-prefix=CHECK-TAPI <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c
<WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c:5:16: error: CHECK-TAPI: expected string not found in input
// CHECK-TAPI: data: { Type: Object, Size: 4 }
               ^
<stdin>:1:1: note: scanning from here
--- !experimental-ifs-v1
^

And when run without FileCheck, our raw output:

> <WORKDIR>/arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c
--- !experimental-ifs-v1
IfsVersion: 1.0
Triple: thumbv7em-ti-none-eabihf
ObjectFileFormat: ELF
Symbols:
...

I am sorry for this James. I can add back the REQUIRES lines for now and coordinate with you on making sure your downstream bots are not affected again if the REQUIRES are removed again.
By chance are your bots accessible publicly?

Sadly, they are not. It's on our list of things to investigate, but we don't have the resources to do such a thing quite yet.
I'm looking into the 'arm7*' buildbots to see if they are built similar to ours so I am not leaving you entirely without something to look at. However, if it seems to be common knowledge to always include an X86 target, I think I can talk to my team and change up what we do.

These buildbots seem to also do LLVM_TARGETS_TO_BUILD=ARM, and then set the default target triple to a non-x86 triple (the host's)

That could point towards us being in error here. I'll investigate things a little further, and update when I get the chance.
To be clear: this feature should work for any ELF target, correct?

Yes, it is designed to work for all ELF targets but at the moment it is still in an early state. I am on the llvm IRC as zer0_ BTW

Oct 11 2019, 4:23 PM · Restricted Project, Restricted Project
JamesNagurne added a comment to D63978: Clang Interface Stubs merger plumbing for Driver.

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.

object* tests seem to be based on object.cpp, which had the REQUIRES line, and externstatic.c also had that line prior to the change.
I see that @compnerd suggested the removal, but were you certain that these tests would work on clang toolchains for which x86 is not a registered target?

For a failure example, here the output of lit for our toolchain. If you can make sense of it, I'd appreciate input on how we can fix or work around it:

> <WORKDIR>/arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c | <WORKDIR>/arm-llvm/Release/llvm/bin/FileCheck -check-prefix=CHECK-TAPI <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c
<WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c:5:16: error: CHECK-TAPI: expected string not found in input
// CHECK-TAPI: data: { Type: Object, Size: 4 }
               ^
<stdin>:1:1: note: scanning from here
--- !experimental-ifs-v1
^

And when run without FileCheck, our raw output:

> <WORKDIR>/arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c
--- !experimental-ifs-v1
IfsVersion: 1.0
Triple: thumbv7em-ti-none-eabihf
ObjectFileFormat: ELF
Symbols:
...

I am sorry for this James. I can add back the REQUIRES lines for now and coordinate with you on making sure your downstream bots are not affected again if the REQUIRES are removed again.
By chance are your bots accessible publicly?

Oct 11 2019, 1:35 PM · Restricted Project, Restricted Project
JamesNagurne added a comment to D63978: Clang Interface Stubs merger plumbing for Driver.

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.

Oct 11 2019, 1:00 PM · Restricted Project, Restricted Project

Sep 13 2019

JamesNagurne added a comment to D67287: [Diagnostics] Add -Wsizeof-array-div.

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

Sep 13 2019, 2:03 PM · Restricted Project
JamesNagurne added a comment to D67287: [Diagnostics] Add -Wsizeof-array-div.

As mentioned in an inline comment, the test only works if the sizeof(int) != sizeof(int *) and sizeof(unsigned long long) == sizeof(int)

Sep 13 2019, 11:39 AM · Restricted Project

Aug 27 2019

JamesNagurne added a comment to D65907: Introduce FileEntryRef and use it when handling includes to report correct dependencies when the FileManager is reused across invocations.

No the windows test failure was different, there were no Deps at all. I'm currently investigating it on a windows VM.

@JamesNagurne I think there's some issue with the working directory, which is not added in your case. Which platform are you running your build/test on? Which cmake options are you using?

I apologize for not giving such information in the first reply. Unfortunately this isn't an easy remote reproduction, as our ToolChain and some integral changes aren't upstreamed. This is an embedded ARM cross-compiled on Linux. Might be able to reproduce with arm-none-none-eabi.
LLVM is built as an external project. Looking at the build system, it looks like we have the CMAKE_ARGS:

-DLLVM_DEFAULT_TARGET_TRIPLE=arm-ti-none-eabi
-DLLVM_EXTERNAL_CLANG_SOURCE_DIR=${CMAKE_SOURCE_DIR}/llvm-project/clang
-DLLVM_TARGETS_TO_BUILD=ARM
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_CXX_COMPILER=clang++
-DCMAKE_C_COMPILER=clang
-DLLVM_USE_LINKER=gold
-GNinja

Nothing suspicious, except maybe the default triple and ARM target.
Looking at our (not upstream) toolchain file, we do have some RTLibs, LibInternal, libcxx, and System include changes, along with a -nostdsysteminc to avoid pulling host includes into our cross compiler. However, none of this should affect general "#include" behavior, correct?
Another glance at your changes don't seem to affect any target-specific handling either, at least directly.

Yes, I don't see anything in your changes that is an obvious thing to blame.

I might have to just bite the bullet and drop into the test with a debugger.

I fixed the Windows issue, and it was completely unrelated to your issue. It looks like the FileManager isn't constructing absolute paths when accessing the files, which is somewhat unexpected. It would be useful to debug invocations of getFileEntryRef, to see if the InterndFilename in the function is getting changed into an absolute path or not.

Aug 27 2019, 12:21 PM · Restricted Project, Restricted Project

Aug 23 2019

JamesNagurne added a comment to D65907: Introduce FileEntryRef and use it when handling includes to report correct dependencies when the FileManager is reused across invocations.

No the windows test failure was different, there were no Deps at all. I'm currently investigating it on a windows VM.

@JamesNagurne I think there's some issue with the working directory, which is not added in your case. Which platform are you running your build/test on? Which cmake options are you using?

Aug 23 2019, 4:05 PM · Restricted Project, Restricted Project