Thanks, @aprantl for the suggestion. Please review the doc change.

Updated SourceLevelDebugging.rst.

In D123697#3452974, @aprantl wrote:

could you also update SourceLevelDebugging.rst?

Doubled round-trip and moved the test to test/Assembler.

Closed by commit rGc226a5c4d7ea: [DebugInfo] Use DW_ATE_signed encoding when creating a Fortran.

@dblaikie: A quick git blame shows that the original code for getDefaultLowerBound was added to DwarfCompileUnit.cpp in the following commit in 2012:

@aprantl: Thanks for the feedback. I have updated the patch as you suggested. Please review.

IMHO, it's a bit excessive to go through DISubrange for this simple language-specific attribute; plus, doing that would require a DIBuilder API change. DwarfUnit::getDefaultLowerBound probably went through a similar discussion and it's currently using getLanguage. Perhaps these can all be overhauled based on your suggestion when support is needed for some language that allows non-integer array index type, and we go forward with this simple change for now?

For my experiment, I use the two files in the attachment: test-c.cpp is the main program. It calls the Fortran function DegCtoF in test.f90.

Thank you @aprantl and @dblaikie for the feedback. I will do some experiments with LTO and provide an update.

I just added a new field StringLocationExp to DIStringType in this commit: https://reviews.llvm.org/rG28bfa57a7315c3161124c90b4d52f467616dc92e . Please add an optional argument to these createStringType functions so that the caller can specify this new field if it desires.

Added a test for backward compatibility.

Format fixes.

Thanks for the review, Reid.

Thanks for the review, Reid.

Thanks for the feedback, Reid!

FYI: I did check-llvm for both before and after my changes, and the results matched (with the same 9 failed tests).

The Windows build seems to be broken by this commit in mlir:

@springerm: It appears that this commit breaks the Windows build. Could you please take a look at this? Thanks!

Addresses formatting issues and comments from Reid. Thanks, Reid!

Issue fixed as suggested in https://reviews.llvm.org/D108946.

Closed by commit rG1d36988394a5f37: Moved the test to X86 as it's x86 specific. (authored by cchen15).

Thanks for the suggestion, @lebedev.ri. Could you please approve if this looks good to you?

Moved the test to CodeGen/X86.

I can't find documentation on the REQUIRES keyword. A quick grep shows that x86-registered-target seems to be the one to use (I tried x86_64-registered-target but that's reported as UNSUPPORTED). Please suggest a better requirement if there's one.

Hi @aprantl. I just got notified by buildbots that the new test fails on clang-aarch64-quick and clang-armv7-quick (maybe more to come). Could you please suggest a way to disable this test on triples that don't support the 'x86_64-unknown-linux-gnu' target? Thanks!

Updated the test filename to reflect the change made in D93559.

Thanks a lot, Aditya. Again, my apologies for the screw-up. I will make sure I won't make the same mistake next time I add a new file.

In D93462#2463742, @gkm wrote:

@cchen15 @SouraVX @aprantl

This diff breaks git source trees on case-insensitive filesystems, such as on macOS.
I did this on Linux, which is case-sensitive:

$ find . |fgrep -i llvm/test/DebugInfo/X86/DIModule.ll
./llvm/test/DebugInfo/X86/DIModule.ll
./llvm/test/DebugInfo/X86/dimodule.ll

On a case-insensitive filesystem, these names collide and one overwrites the other, yeilding a tree with irreconcilable conflicts.

Please fix ASAP! Thanx!

Thanks for catching this for me. I don't work on Mac. :(

In D93462#2462118, @SouraVX wrote:

LGTM! Thanks for the patch.
One small thing, do you mind adding a one liner to release notes ? It would help in tracking extensions to Debug Metadata(previous extensions of DIModule were part of LLVM11).

Made changes based on the review comments.

Typed the attributes as PointerUnion<DIExpression *, DIVariable *>, and updated the test to exercise the DIVariable case.

In D89817#2353822, @aprantl wrote:

We can do that, but then the debugger would need to work a bit harder in order to get a constant, doesn't it? I don't feel strongly either way. If you do want it done the way you prefer, please let me know and I will make the change.

That's an interesting point. Do we emit different DWARF FORMs for constant vs constant DIExpression? An elegant solution would be to recognize constant DIExpressions in AsmPrinter (DIExpression::isConstant) and emit the same DWARF FORM we would emit for an IR constant if the expression is a constant.

Reverted back to type those attributes as Metadata to allow DIVairbale.

Also, DIBuilder::createConstantValueExpression(uint64_t) is already available for doing constant via DIExpression,, and its usage is demonstrated in the unit test.