User Details
- User Since
- Mar 1 2016, 1:38 AM (369 w, 16 h)
Feb 9 2022
Hi Roman,
Jan 13 2022
Looks good to me. Thanks!
Sep 16 2021
Could you elaborate in the commit log about the false positives?
Sep 8 2021
Aug 4 2021
Jun 16 2021
Jun 15 2021
Jun 14 2021
Jun 9 2021
Update commit log message
Add 2-stage bot as well. These are running as expected at
http://ex40-01.tcwglab.linaro.org:8013/#/workers .
Jun 1 2021
Please ignore this. I squashed 3 separate commits into 1.
Apr 15 2021
@mstorsjo
Hi Martin,
Mar 30 2021
Mar 19 2021
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.
Mar 18 2021
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.
Mar 17 2021
Mar 12 2021
Fixed thinko: GetLastArg -> GetLastArgValue
Added missing header to pull in definition of CLANG_DEFAULT_LINKER.
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,