[DebugInfo] Corrected debuginfo for modules

[SouraVX]

Summary: Flang was creating DIModule metadata without file and line number information, as a result GDB is not able to find and print debug info fortran modules.

This patch extends the flang to emit DIModule with file and line number information. This patch is dependent on LLVM 11.0 DIModule metadata, since older versions of DIModule do not support file and line information.

Sample GDB output after this: (gdb) info modules

**File module2.f90: 18: mod2

File module.f90: 16: mod1**

LLVM metadata support: https://reviews.llvm.org/D79484 https://reviews.llvm.org/D80614

[SouraVX]

Gentle Ping!

[SouraVX]

Gentle Ping!

[SouraVX]

Gentle Ping!

[kiranchandramohan]

@SouraVX Is there a requirement for LLVM 11/10?

[SouraVX]

@SouraVX Is there a requirement for LLVM 11/10?

Yes, Those LLVM support patches in went in LLVM 11. I've one more small commit/patch for handling imports of modules from different translation unit and test cases for them. Planning to do it by EOD.

[SouraVX]

This should build, since Driver version patch got merged.

[SouraVX]

It may fail(test case), on release_100 branch. Since it's dependent on LLVM11.

[SouraVX]

@michalpasztamobica , can we see which commit was used in pre-built LLVM ? I need to check whether https://github.com/flang-compiler/classic-flang-llvm-project/pull/45 this was part of LLVM build or not. Looking at the testcase failure, it seems to me that Driver doesn't pass the correct version. https://github.com/flang-compiler/flang/pull/898/checks?check_run_id=2686210341

[michalpasztamobica]

Hi @SouraVX ! Surely, these builds did not yet have the necessary commit available. The pre-compilation of your patch is still running: https://github.com/flang-compiler/classic-flang-llvm-project/actions/runs/882590963

I suggest to re-run this job when all jobs in https://github.com/flang-compiler/classic-flang-llvm-project/actions go green :) They normally finish in less than 3 hours (github just gives us dual-core machines).

[SouraVX]

Okay! Here's the summary observed: 1 Bot https://github.com/flang-compiler/flang/pull/898/checks?check_run_id=2691272061 building flang with release_11x passed & 1 Bot, https://github.com/flang-compiler/flang/pull/898/checks?check_run_id=2691272050 building flang with release_100 failed. (This is expected, since this PR explicitly states its dependence on LLVM11) However, what was surprises me was rest of these CI Bots cancelling the build :( I mean I know this but didn't have any didn't have anything against it. Now is the good time to discuss on this :)

1. We need to understand the rationale behind Cancellation of builds. I meant if you look carefully, even in this case it could've happened that Bot building release_100 finished first and declare failure and rest of the Bots will cancel their build :( and we will end up scratching our heads :(

2. Other Bots, LLVM Builder & Bots, runs every commit independently because it's common to see some check failing for instance in some Windows bot but passing on the rest. One can see where it failed & passed. Considering this as a good example our approach is contradictory to it. i.e One failure, can cancel the rest of Bots progress :(

[michalpasztamobica]

Hi @SouraVX , Github Actions by default cancel all other runs when one job fails. In general, this makes sense to me and I would personally leave it as is as a default. but we can discuss this matter on Wednesday call or in this PR, to gather everyone's feedback. If you need to see the other job results you can temporarily add the continue-on-error flag to the failing jobs, like so:

jobs:         
  build_flang:    
    runs-on: ubuntu-20.04
+   continue-on-error: true
    env:      install_prefix: /usr/local

I admit I haven't tried it, so I am not sure if it work, but it should ;)

EDIT: Please, don't forget to remove that extra flag before PR gets merged :)

EDIT2: @SouraVX , this fail-fast option looks even better:

strategy:
+ fail-fast: false
  matrix:

[SouraVX]

Thanks @michalpasztamobica for your insights :) I agree that we should bring this in our meetings. Its important to discuss because this issue will be seen in version dependent PR's and looking at the reviewers model, I think reviewer may first look at CI thing of the PR whether they are GREEN or RED and if it happens to be RED people might lower their priority ? One possible solution could be: We could have a clause in review processes that, For a PR if some builds are not GREEN due to some version specific dependences and author clarify this first hand the review should continue :)

[kiranchandramohan]

@SouraVX what is needed here for the CI to pass?

[kiranchandramohan]

OK. i guess this is the release_10 issue.

[bryanpkc]

Can we cherry-pick https://reviews.llvm.org/D79484 into release_100 of classic-flang-llvm-project?

[bryanpkc]

Closing stale PRs. Please submit a new one if the problem persists in the latest master branch.