I changed the tests to use FileCheck variables whenever possible.

In D63846#1574302, @rjmccall wrote:

I don't know what I think about widespread use of -fno-discard-value-names for now; please continue to use FileCheck variables, and we can make a holistic decision about that flag later.

In D63846#1574102, @rjmccall wrote:

Please don't check IR names in test output. That actually includes anonymous names like %2; these should always be tested with FileCheck variables. I suggest using %.* as the pattern; if you're matching the LHS of an LLVM assignment, that shouldn't have problems with accidentally matching too much.

ping

Adding more reviewers.

ping

OK, this should work while clang_generate_header() is used for plain files.

In D58537#1476570, @tstellar wrote:

Can you test D61054?

ping

I think I got it, finally, after talking with HJ. As defined in https://github.com/hjl-tools/x86-psABI/blob/hjl/master/dl.tex, the pr_data field consists of 4-byte integers for GNU_PROPERTY_X86_FEATURE_1_AND program property type (pr_type). At the same time, the program property array must be a multiple of 8 bytes on x86-64 (as stated in https://github.com/hjl-tools/linux-abi/blob/hjl/master/object-files.tex), thus, the alignment is computed properly.

Please submit your patch with full context according to LLVM's documentation: https://www.llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface

In D56108#1341746, @Hahnfeld wrote:

Can you explain the benefit of this change? I would have expected a target like install-omptarget, but applying this patch locally didn't change anything visible.

The incremenetal fix.

ping

The new EOF handling looks much better to me. I added a couple of negative tests for C-style comments and code blocks crossing the file boundary. I also renamed include files from .td to .inc so that they are not considered as real tablegen tests.

In D53840#1282024, @nhaehnle wrote:

I have to say I'm feeling a bit ambivalent about this. I'd say it would be nicer to have a mechanism that integrates with the rest of the TableGen language, but that's admittedly non-trivial. So I guess this approach is okay.

Thank you for the prompt reply, Nikolai! Yes, I decided to keep the preprocessing aside to minimize changes in the actual lexing.

Updated diff with the context.