- User Since
- Apr 18 2013, 6:48 AM (405 w, 1 d)
Thanks, I think having this is super useful!
Wed, Jan 20
This caused asserts in Chromium. See https://bugs.chromium.org/p/chromium/issues/detail?id=1168629#c2 for a reproducer.
Tue, Jan 19
I found the file that's getting miscompiled, and uploaded preprocessed source and some notes here: https://bugs.chromium.org/p/chromium/issues/detail?id=1167890#c6
Mon, Jan 18
We're seeing crashes after this commit (5238e7b302ffc40707677960da9d64e872745dac) in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1167890
Fri, Jan 15
So I'm wondering, if I remove the above setAssemblerDialect line and revert this commit, we should have inline asm (both module-level and GNU function-leve) respect the target-selected asm dialect variant both for ThinLTO and non-ThinLTO, so they should match again. Would that also solve the problem you were originally tracking?
Thu, Jan 14
Based on @hans 's feedback, I added a new enumeration kind called RelOffsetArrayKind, and remove IsRelative flag.
This separates the lookup table and relative lookup table IR generation.
Do you think this helps for the abstraction?
I feel like if it might be better if we can generate the relative lookup table in the first place instead of generating it in a separate pass.
Tue, Jan 12
Great stuff, thanks for working on this!
Mon, Jan 11
Dec 18 2020
Looks great, thanks!
Dec 9 2020
Dec 8 2020
Dec 7 2020
Dec 3 2020
Dec 2 2020
Dec 1 2020
Moving the "Append the module inline asm string" code down, and simplifying it in the process.
Adding test case where the symver doesn't get imported.
I just realized this makes Linker/ depend on Object/
I'm not sure whether that's a problem or not, but we could avoid that by storing the symvers in a metadata node again.
Pulling in the symver directives in IRLinker::run() instead. (I didn't do a separate function since it's just a few lines, but happy to do that if you think it would be better.)
Seems like a good idea to me.
Nov 30 2020
Nov 27 2020
Seems reasonable to me, but someone who actually knows clang-scan-deps should take a look too.
Nov 24 2020
Nov 23 2020
Thanks for the pointers!
(I added a naming comment, but feel free to resolve that as you feel is best.)
lgtm, probably check with maskray that he's happy first though.
Nov 17 2020
Nov 16 2020
For Chromium, the latest patch seems to fix the issues we saw. Thanks!
Making the tarballs more reproducible sounds great.
Nov 13 2020
Nov 12 2020
I don't think it makes sense to try to emit the closure until we have the ctor definition. I'll update the patch to handle this.
Ok. That's a bit different than what MSVC is doing. It generates a closure constructor even if there is only a declaration. But I guess we are not aligning specifically with MSVC!
Nov 11 2020
Nov 10 2020
Handling the decl only case.
clang.exe -c test.cpp
Assertion failed: !hasUninstantiatedDefaultArg() && "Default argument is not yet instantiated!", file D:\IUSERS\zahiraam\llorg_ws\ws1\llvm\clang\lib\AST\Decl.cpp, line 2719
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Nov 9 2020
I was looking into this today, and sent out what I think is a better approach: https://reviews.llvm.org/D91089
Please take a look.
Nov 5 2020
Nov 4 2020
I'm not sure ignoring these is the right thing to do. Maybe they should be "Unsupported but parsed options" instead?
Nov 3 2020
Sorry for the late follow-up, but this caused big problems in Chromium.