[all-commits] [llvm/llvm-project] 2a36ef: [DebugInfo] Allow DISubrange/DIGenericSubrange wit...

[Abid Qadeer via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2a36ef580e560698581984d3e309e474c91ed111
      https://github.com/llvm/llvm-project/commit/2a36ef580e560698581984d3e309e474c91ed111
  Author: Abid Qadeer <haqadeer at amd.com>
  Date:   2024-07-09 (Tue, 09 Jul 2024)

  Changed paths:
    M llvm/lib/IR/Verifier.cpp
    R llvm/test/Assembler/invalid-disubrange-count-missing.ll
    A llvm/test/DebugInfo/subrange-missing-upperBound.ll
    R llvm/test/Verifier/digenericsubrange-missing-upperBound.ll
    R llvm/test/Verifier/disubrange-missing-upperBound.ll

  Log Message:
  -----------
  [DebugInfo] Allow DISubrange/DIGenericSubrange without count/upperBound. (#96474)

Due to the current order of metadata in DISubprgram, `Type` is processed
before `Unit` by the Verifier. This can cause a race and
 use of garbage data. Consider the following code:

```
int test(int a[][5])
{
    return a[0][2];
}
```

when compiled with clang, the control reaches
`Verifier::visitDISubrange` first with `CurrentSourceLang` still equal
to dwarf::DW_LANG_lo_user (32768). The `Verifier::visitDICompileUnit`
which sets the value of `CurrentSourceLang` is reached later. So
`Verifier::visitDISubrange` ends up using a wrong value of
`CurrentSourceLang`.

This behavior does not effect C like language much but is a problem for
Fortran. There is special processing in `Verifier::visitDISubrange` when
`CurrentSourceLang` is Fortran. With this problem, that special handling
is missed and verifier fails for any code that has Fortran's assumed
size array in a global subroutine.

Various solutions were tried to solve this problem before it was decided that
best course of action is to remove these checks from Verifier.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications