User Details
- User Since
- Mar 1 2016, 1:38 AM (266 w, 5 d)
Tue, Mar 30
Fri, Mar 19
Hi Tom,
This was reviewed in https://reviews.llvm.org/D98493 and https://reviews.llvm.org/D98862.
NFC: Make clang-format happy
This is now squashed into https://reviews.llvm.org/D98935
Hi @amyk , thanks for testing -- I've updated two more places, which I missed on the first go. Would you please test the new version?
Added more fixes to OpenMP/linking.c and Driver/msvc-link.c .
The only upstream bot that was broken by this change was clang-ppc64le-rhel, and I have notified the bot owner of the problem and said that I'm working on this within 15 minutes of the breakage. I posted a tentative fix for the testsuite several hours later.
Thu, Mar 18
This is merged to release/12.x branch.
@SureYeaah , does this fix your internal buildbot?
This patch broke clang-ppc64le-rhel builder. The patch makes MSVC-compatible driver honour CLANG_DEFAULT_LINKER setting, which this builder sets to “lld”. Therefore there’s an expected change in the output now that CLANG_DEFAULT_LINKER can override link.exe.
The patch was wrong. We use "const Arg *A" at the end of GetLinkerPath, so can't remove it. I thought I tested this, but, apparently, not.
@tstellar , OK to backport to release/12.x if buildbots are happy with this?
I've filed https://bugs.llvm.org/show_bug.cgi?id=49624 with background info.
Wed, Mar 17
Fri, Mar 12
Fixed thinko: GetLastArg -> GetLastArgValue
Added missing header to pull in definition of CLANG_DEFAULT_LINKER.
Mar 12 2021
Mar 11 2021
Feb 17 2021
I've merged this on Stevan's behalf. Thanks, Stevan!
I've merged this on Stevan's behalf. Thanks, Stevan!
Feb 12 2021
@tstellar
OK to cherry-pick to release/12.x after a couple of days?
Feb 11 2021
Thanks for the reviews
Updated patch to use canonical MSVC syntax
...
Can you file a bug for this?
Hi Tom,
Feb 9 2021
Feb 8 2021
Looks good to me. It might be prudent to switch comment string from ";" to "//" for 32-bit ARM COFF as well, but that should be a separate change anyway.
@compnerd , fyi, since you requested GNU specialization in https://reviews.llvm.org/D36366 .
...
Yes, for the aarch64-windows-msvc target, currently semicolon is set as both comment and separator, making no actual char available as separator symbol. I'd suggest changing the comment char to '//' for aarch64-windows-msvc, like it is for aarch64-windows-gnu and ELF targets. I initially tried to do this, but was suggested to only change the -gnu target in the review I linked before. At the time I shrugged and just went with the suggestion, but at the current state I'd suggest revisiting this decision, as there's a clear benefit for making it match the other platforms, and there is no reference for what GAS assembly for aarch64 msvc targets should look like anyway.
And, looking at AArch64MCAsmInfoMicrosoftCOFF, I think we need to do the same for MSVC COFF as for GNU COFF in https://reviews.llvm.org/D36366 -- use "//" for comment, which should return ";" to being statement separator.
...
So with that in mind, my preference would be to just make the aarch64-windows-msvc targets behave just like the -gnu ones in this aspect. That was my initial intent when I fixed the comment char for aarch64 windows targets in D36366 (to make semicolon work as separator), but in review it was requested to only make that change for -gnu triples, see https://reviews.llvm.org/D36366#833185. Maybe we should try to revisit that discussion?
Yes. We should backport this to 12.0 before release if possible.
I opened bug 49075 to track this as a release blocker. Would you be willing to take it?
Feb 5 2021
...
The issue turned out to not be parser bug, but rather the incorrect statement separator being used by compiler-rt on certain platforms.
This workaround was incorrect. While it made the error go away, some of the assembly would stay as comments due to the wrong separator and the code would not work or compile under certain conditions.Could you provide the full compile command that throws an error during your build?
I should have time to investigate during the weekend.
@tambre
Hi Raul,
Feb 2 2021
Hi Galina,
Jan 25 2021
Jan 18 2021
Any comments?
Jan 13 2021
Oct 9 2020
I've updated buildbot.tac. Thanks, Galina.
@gkistanova
Hi Galina,
Sep 18 2020
Sep 10 2020
Galina, Diana, any other feedback? Or shall I commit the patch?
Sep 5 2020
For reference, here are testing builds:
LGTM.
Jul 2 2020
Hi @mkazantsev ,
Linaro benchmarking CI flagged this patch as increases code-size of SPEC2k6's 401.bzip2 by 3% on ARM (Thumb2 mode) and by 5% on AArch64. This happens at -Os -flto.
Hi Sam,
Linaro benchmarking CI flagged this patch as it regresses SPEC2k6's 462.libquantum by 10% at -O2, -O3 and "-O3 -flto" for aarch64-linux-gnu. Impact on other benchmarks is below 2%, which is within noise.
May 28 2020
May 27 2020
May 26 2020
Apr 30 2020
Mar 15 2020
Quite surprisingly, this patch increases code size by 3-4% on several SPEC CPU2006 benchmarks for arm-linux-gnueabihf at -Oz optimization level:
- 473.astar,astar_base.default regressed by 103
- 450.soplex,soplex_base.default regressed by 103
- 483.xalancbmk,Xalan_base.default regressed by 104
Mar 6 2020
It's runtime failure and occurs on "ref" input. Compilation flags are
-O3 -marm --target=armv7a-linux-gnueabihf --sysroot=/path/to/build/sysroots/arm-linux-gnueabihf
and linking flags are (note that I'm linking with LLD).
-Wl,--build-id -Wl,-dynamic-linker=/path/to/run/sysroot/lib/ld-2.31.9000.so -Wl,-rpath=/path/to/run/sysroot/lib -Wl,-rpath=/path/to/run/sysroot/usr/lib -O3 -marm --target=armv7a-linux-gnueabihf --sysroot=/path/to/build/sysroots/arm-linux-gnueabihf -fuse-ld=lld
Mar 5 2020
@MaskRay , hi. This patch miscompiles 471.omnetpp and 453.povray on arm-linux-gnueabihf. Would you please investigate?
This commit 4698bf145d583e26ed438026ef7fde031ef322b1
Author: Kazu Hirata <kazu@google.com>
Date: Wed Feb 5 08:24:01 2020 -0800
Feb 17 2020
Hi Nikita,
Feb 14 2020
Hi @kazu ,
This patch increases code-size of 444.namd by 1% on arm-linux-gnueabihf:
- when compiling with -Os: from 171653 to 173645
- when compiling with -Os -flto: from 137772 to 139708
Could you take a look if these regressions can be easily avoided?
Let me know if you need help reproducing the regressions. I have pre-processed source and generated assembly handy.
Thanks!
Nov 19 2018
Hi John,
Looks good.