• Reformat.

FYI, I was working for introducing clang-resources in D141755. Could we unify clang-resources in the clang?

At the moment, this can be built for targeting linux, or will raise error before building begins.

• Will invoke error unless the platform is linux

Merge conflict in Options.td (D157150, D157151, D158037). Could you follow?

A merge conflict to D151283. Could you catch up?

Merge conflicts to origin/main;

Thanks for the fix.

I am using ubuntu-20.04 (amd64) and stage2-clang uses libstdc++ for bootstrapping.

FYI, similar miscompilation in llvm-rc; https://lab.llvm.org/buildbot/#/builders/124/builds/8260

Seems this still miscompiles llvm-rc/ResourceFileWriter.cpp for targeting x86-64. Investigating.

Would this cause many warnings in Clang/LLVM tree?
https://lab.llvm.org/buildbot/#/builders/36/builds/36560

@jroelofs Sorry for the delay and thanks for the report.

Done in rG59afd298996c

Thanks. I assume you have tested in both configurations.

I confirmed all tests passing (with applying three diffs and generated blobs). Thanks.

• Add *.cpp to srcs
• Remove copts

I don't have any environments for targeting Win32 at the moment.
Do we think I should make this Win32-compatible?

Thanks for feedbacks.

@AlexM @dblaikie Could you take care of c-index-test.c?

Thank you for the working and excuse my nitpicks.

Thank you for working. Could you reformat a few lines?

Excuse me, I have reverted this due to circular deps.
clangAnalysis should not depend on clangSema.

Sorry for the delay. I am investigating RegionStack if PopRegions() would destroy branches.

Seems this causes clang crash in stage2.

This causes the crash in stage2 x86 clang. Could you investigate or revert?

I've found the case of assertion failure (in CoverageMapping.cpp:507, llvm-cov)

@alanphipps Thanks for the update.

@alanphipps Thanks for the update.
Could you please apply https://github.com/chapuni/llvm-project/commit/c8b8e86ed5755ff471b003e483237551b49c15ba as clang-format?

@alanphipps Could you apply clang-format please?

@alanphipps Could you apply clang-format please?

@alanphipps Haven't you forgot updating this?
Excuse me if you are working for other ongoing issues.

@goldstein.w.n I found the issue was due to D141712 and fixed (not by me) in rG282324aa4a6c29d5ce31c66f8def15d9bd8e84e4
Sorry for the noise.

@nikic Thanks for fixing!

@goldstein.w.n
I am sorry. As far as I have been investigating, this is not the cause but 1st commit to trigger. The failure was hidden when I added debug codes, heisenbug.
The failure can be seen in my internal builders.

FYI, I met different behavior between amd64-ubuntu and aarch64-ubuntu. Not sure if this triggers.

I am still investigating, though, is this intended as NFC?

@GuillaumeGomez Thanks for catching this. Seems reasonable to me.

Sorry, I did a wrong fix. Does anyone fix it?

In D147942#4352063, @arsenm wrote:

73925ef8b0eacc6792f0e3ea21a3e6d51f5ee8b0

@ldionne Thanks. It is what I would like to ask you.

Since D74106, target_link_libraries(PRIVATE) brings dependencies on generated headers.
I would like to suggest specifying Core to require usage of intrinsics_gen, unless linking to Core wants to be avoided.

Please come in; https://discourse.llvm.org/t/rfc-let-mvt-generated-and-restore-mvt-into-llvm-codegen/69547/3

I am not certain about this change. Ok if this resolves your matter.

In D148767#4312692, @barannikov88 wrote:

Sorry, I don't follow. They may theoretically depend on anything. Why CodeGen/CodeGenTypes, specifically?
If they don't require it, why add it?

But I wonder why this didn't have LINK_COMPONENTS before. I guess this would rely on transitive deps.
(LLT impl was provided by LLVMSupport before)

Fixed temporarily in rGd091a19e58a2.

I have found the case aarch64svcount is incompatible. Will fix.