Can someone commit this for me? Thanks!

In D69824#1752102, @mehdi_amini wrote:

In general we don't install tablegen tools because they are tightly tied to the library-based extensibility. For LLVM we do because we support building LLVM targets against installed copies of LLVM. I'm not familiar enough with MLIR, what is the use case for an installed mlir-tblgen tool?

I think the use case for mlir-tblgen is very similar to the external backend case of LLVM. Someone who would develop an out-of-tree dialect for MLIR and would like to build/link against a prebuilt MLIR would need to use the mlir-tblgen that comes with the installed MLIR (or build it themselves)

Hi Mehdi,

Thanks for catching the brain cramp.

@probinson Thank you for the reminder.

In D54327#1455171, @schweitz wrote:

I just tried the test without the -v option, and it passed. It appears to not be required.

A couple small changes to correct the issues.

Right, those failures make sense to me.

Thanks for accepting the changes, Adrian.

Removes the target triple from the test.

Thanks, Paul. I can certainly file a bug after this lands for tracking purposes.

Just wondering if there are any more to-dos with this one. Thanks in advance.

Thank you for your patience regarding the protracted schedule here. We're presently reworking some of the support for Fortran debug with respect to type information.

Updated the diff ahead in time.

In D54327#1425054, @aprantl wrote:

You can simulate the relevant effect of LTO by producing two .ll files and running llvm-link on them. Alternatively you can also run llvm-lto/llvm-lto2 on them for a more complete simulation.

added documentation blurb to SourceLevelDebugging.rst

In D54043#1426875, @aprantl wrote:

If you update the patch with the documentation, I'd be happy to commit it for you!

Thank you.

Split tests back into 2 files

Merged test files into one. Also deploy CHECK-DAG.

In D54327#1310565, @probinson wrote:

I am curious how debug info for common blocks plays with LTO. I think we would not want different common-block descriptions to be de-duplicated just because the global name was the same.

A little more cleanup of our code to minimize the exact change.

Remove note from code.

Rework of D54043 to use the DISPFlag* enum added afterward.

Noting that porting also required https://reviews.llvm.org/D54755

I believe all the comments have been addressed. Is there anything else required on our end with this one?

Or this could go in first and supply additional tests for your new bit format. :)

I believe all the comments have been addressed. Is there anything else required on our end?

Remove alignment (not needed for DW_TAG_common_block).
Remove default dtor. (not needed)
Add both an llc test and a llvm-as | llvm-dis loop test.

minor fix to a comment in the new test

In D54043#1296240, @dblaikie wrote:

Looks like this could use an LLVM CodeGen test too (similar to, or extending/renaming test/DebugInfo/Generic/mainsubprogram.ll)

Added an assembler test.

In D54327#1293281, @JohnReagan wrote:

I don't understand the need for the "common alpha" global variable.

In D54043#1288590, @johanengelen wrote:

Please note that D also has the pure attribute on functions, so I would like the pure flag to not be Fortran-specific such that we can use it for D too. Thanks!

Use bit 15 as the "extends" bit and free up bit 30.

In D54114#1287783, @JohnReagan wrote:

As I commented in the dev email list, these "Fortran" features are actually useful for other languages. We use similar DWARF for Pascal "schema types", BASIC string types, etc. on OpenVMS Itanium and we'll want to leverage all of these for our x86 target. I suggested that the names be make more neutral or folded into the matching metadata tag. I'll give inline comments next.

In D54114#1287650, @greened wrote:

I'm not a Fortran expert. The last Fortran I used was 77 and didn't have all these newfangled features. :) Some questions come up on our end so I'll relay them.

Does this support handle non-contiguous arrays? Arrays can have "holes" in them. I believe the dope vectors ("array descriptors") hold that information but the description makes it sound like only upper and lower bounds are supported.

Add the new flags to the C API.

The argument that the DWARF presentation to existing Fortran debug vendors must be changed doesn't seem too compelling.

Some notes:
Section 5.10 of the DWARF standard specifies the correct, vendor-neutral handling of Fortran's CHARACTER string type.
Section 4.4.3 of the Fortran standard explains the semantics of the CHARACTER type.
For what it's worth, the DW_AT_encoding, while not listed in Appendix A of DWARF (Ver. 4), might actually be quite desirable for Fortran compilers and debuggers for encoding the KIND of the CHARACTER type (in particular when supporting unicode).

In D36480#836923, @aprantl wrote:

I made quick experiment using this representation:

!21 = !DIDerivedType(tag: DW_TAG_string_type, name: "character(3)", size: 24, baseType: !DIBasicType(size: 8, align: 8, encoding: DW_ATE_signed))

which comes out as

0x00000056:   DW_TAG_string_type
                DW_AT_type	(cu + 0x0060 => {0x00000060})
                DW_AT_name	( .debug_str[0x00000026] = "character(3)")
                DW_AT_byte_size	(0x03)

0x00000060:   DW_TAG_base_type
                DW_AT_encoding	(DW_ATE_signed)
                DW_AT_byte_size	(0x00)

This still has the superfluous base type, but it appears to conform to the DWARF specification. Would something like this work for you?

It is understood that LLVM will add a superfluous DW_AT_encoding attribute as well. This has not been a real issue when testing existing debuggers with our Fortran compilers. It is generally expected that debuggers will ignore attributes that they don't understand in context. This patch enables the display of CHARACTER type variables under gdb when using flang, for example.

In D36480#836780, @aprantl wrote:

With this patch's encoding I'm a little worried by the discrepancy between the size and tag.
What about representing strings as !DIDerivedType(tag: DW_TAG_string_type, baseType: !DIBasicType(name: "character", size: 8, align: 8, encoding: DW_ATE_signed) instead?
The patch would be just as simple (allowing the string type tag in DIDerivedType instead), but the representation would be closer to what will be emitted in the end.

In D36480#836117, @aprantl wrote:

Hmm.. when I'm running your test I get:

0x00000056:   DW_TAG_string_type [4]  
                DW_AT_name [DW_FORM_strp]	( .debug_str[0x00000026] = "character")
                DW_AT_encoding [DW_FORM_data1]	(DW_ATE_signed)
                DW_AT_byte_size [DW_FORM_data1]	(0x01)

0x0000005d:   NULL

But the standard says in 5.11:

A string type entry may have a DW_AT_type attribute describing how each
character is encoded and is to be interpreted. The value of this attribute is a
reference to a DW_TAG_base_type base type entry. If the attribute is absent, then
the character is encoded using the system default.

It looks like the proper protocol is to note here that I don't have commit privileges and need someone to do that for me. Thanks in advance.

Fixes for Adrian's comments and cut-n-paste errors. (I'm learning Phabricator.)

Attach both change and test.

Adding a test case.

Generally, we have test cases in flang that would exercise this, so it's a little chicken and egg in that regard. I'll try to whittle something down.