<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/59622>59622</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Recent Optional commit(s)  + clang-11 on ubuntu 20.04 cause broken compiler, many test failures
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          dtzSiFive
      </td>
    </tr>
</table>

<pre>
    Hi folks.  Recent changes to LLVM have caused very broken compiler when built with clang 11 from ubuntu 20.04.
This appears specific to clang 11 (details below) and I've yet to reproduce in any other configuration (clang version, build type, distribution) but only tested varying each of those a few times.

This is currently the default clang compiler used by the github runner image (!) for ubuntu 20.04 (LTS), but can also be reproduced using the official ubuntu 20.04 docker image.

The bug occurs in a fresh Docker image built with the following hacked up `Dockerfile` :
```
FROM ubuntu:20.04

RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y clang-11 cmake python ninja-build git

RUN git clone https://github.com/llvm/llvm-project llvm

RUN cd llvm && \
    mkdir build && \
    cd build && \
    cmake -G Ninja ../llvm \
      -DCMAKE_BUILD_TYPE=Release \
      -DCMAKE_C_COMPILER=clang-11 \
 -DCMAKE_CXX_COMPILER=clang++-11 \
      -DLLVM_BUILD_EXAMPLES=OFF \
 -DLLVM_ENABLE_BINDINGS=OFF \
      -DLLVM_ENABLE_OCAMLDOC=OFF \
 -DLLVM_ENABLE_PROJECTS='mlir' \
      -DLLVM_OPTIMIZED_TABLEGEN=ON \
      -DLLVM_ENABLE_TERMINFO=OFF \
 -DLLVM_TARGETS_TO_BUILD="host"

# RUN ninja -C llvm/build check-llvm
```

Ran this using a commit from earlier today (740db97ad1613eb337ab64b482a46d34cb7846bd).

This will cause many many tests to fail and for me, quite a few to race to consume all available memory, which is why that last `RUN` is commented out -- I ran it manually and for inspection purposes, but just a heads-up it might rock your machine if not run safely.

---

I've been debugging a workflow building our project with this toolchain, where the problem manifested in our tools producing warnings like:

```
warning: <unknown>:0:0: stack frame size (1099511627768) exceeds limit (4294967295) in function 'llhd_init'
32/1099511627768 (0.00%) spills, 1099511627736/1099511627768 (100.00%) variables
```

These appear non-deterministically and appear to be variations of the same value being sign-extended to various widths (above is `fffffffff8`, but also `72057594037927928` (`fffffffffffff8`).

The generated assembly accordingly has silly amounts of stack adjustment:
```
Dump of assembler code for function _mlir_llhd_init:
=> 0x00007f93882d2100 <+0>:    push   %r15
 0x00007f93882d2102 <+2>: push   %r14
   0x00007f93882d2104 <+4>:       push %r12
   0x00007f93882d2106 <+6>:       push   %rbx
   0x00007f93882d2107 <+7>:       movabs $0xffffffffd8,%rax
   0x00007f93882d2111 <+17>:      sub %rax,%rsp
   0x00007f93882d2114 <+20>:      mov    (%rdi),%rax
 0x00007f93882d2117 <+23>:        mov    (%rax),%rbx
   0x00007f93882d211a <+26>:      movabs $0x7f9387e370e0,%r15
   0x00007f93882d2124 <+36>:      xor %edi,%edi
   0x00007f93882d2126 <+38>:      callq  *%r15
```

With the amount adjusted by being similarly `0x8` extended to various widths, I guess.  FWIW this shouldn't need to touch `$rsp`, usually looks like this:
```
Dump of assembler code for function _mlir_llhd_init:
=> 0x00007ffff6a03240 <+0>:    push   %r15
   0x00007ffff6a03242 <+2>:       push %r14
   0x00007ffff6a03244 <+4>:       push   %r12
   0x00007ffff6a03246 <+6>:       push   %rbx
   0x00007ffff6a03247 <+7>:       push   %rax
 0x00007ffff6a03248 <+8>: mov    (%rdi),%rax
   0x00007ffff6a0324b <+11>:      mov    (%rax),%rbx
   0x00007ffff6a0324e <+14>:      movabs $0x4268c90,%r15
   0x00007ffff6a03258 <+24>:      xor    %edi,%edi
 0x00007ffff6a0325a <+26>:        call   *%r15
   0x00007ffff6a0325d <+29>:      movabs $0x7ffff6a04000,%r14
```

Anyway, that's what I see when using this toolchain to build LLVM + my project.  Including in case anyone else is running into this (given the many test failures no shortage of leads to follow here).

----

Since we pin our LLVM revision and bump regularly, I found this started happening between a range of commits (53406427cdf4290986d1a48ea0d582ad195bff15..b6772e6e2045ab491b41d3767f788250800f97ea) that I was able to bisect neatly to:

https://github.com/llvm/llvm-project/commit/faa1b57d16009790ed6fd59342b12607c5460b49

Building that revision with this toolchain fails badly, reverting it succeeds.
Reverting that commit on LLVM from a few days ago (modulo trivial unittest merge conflict) is enough to get things working again.

The recent drop of our [`llvm::Optional` for the alias to `std::optional`](https://github.com/llvm/llvm-project/commit/2916b99182752b1aece8cc4479d8d6a20b5e02da) makes it no longer possible (/practical) to test that change in isolation but as mentioned above the compiler built seems very broken, judging by test failures it's mostly in CodeGen, I just tried again and killed it when things got bad but here's a sampling of the failures that made it through:

```
  LLVM :: CodeGen/X86/2006-11-12-CSRetCC.ll
  LLVM :: CodeGen/X86/2007-01-13-StackPtrIndex.ll
  LLVM :: CodeGen/X86/2007-02-16-BranchFold.ll
  LLVM :: CodeGen/X86/2007-08-09-IllegalX86-64Asm.ll
  LLVM :: CodeGen/X86/2007-10-04-AvoidEFLAGSCopy.ll
  LLVM :: CodeGen/X86/2007-11-30-LoadFolding-Bug.ll
  LLVM :: CodeGen/X86/2007-12-18-LoadCSEBug.ll
  LLVM :: CodeGen/X86/2008-03-31-SpillerFoldingBug.ll
  LLVM :: CodeGen/X86/2008-04-16-ReMatBug.ll
  LLVM :: CodeGen/X86/2008-04-17-CoalescerBug.ll
  LLVM :: CodeGen/X86/2008-04-24-MemCpyBug.ll
  LLVM :: CodeGen/X86/2008-05-01-InvalidOrdCompare.ll
  LLVM :: CodeGen/X86/2008-05-12-tailmerge-5.ll
  LLVM :: CodeGen/X86/2008-08-06-CmpStride.ll
  LLVM :: CodeGen/X86/2008-08-31-EH_RETURN64.ll
  LLVM :: CodeGen/X86/2008-09-11-CoalescerBug2.ll
  LLVM :: CodeGen/X86/2008-09-29-VolatileBug.ll
  LLVM :: CodeGen/X86/2008-10-06-x87ld-nan-1.ll
  LLVM :: CodeGen/X86/2008-10-06-x87ld-nan-2.ll
  LLVM :: CodeGen/X86/2008-10-24-FlippedCompare.ll
  LLVM :: CodeGen/X86/2008-11-29-ULT-Sign.ll
  LLVM :: CodeGen/X86/2008-12-23-crazy-address.ll
  LLVM :: CodeGen/X86/2009-01-31-BigShift.ll
  LLVM :: CodeGen/X86/2009-03-16-PHIElimInLPad.ll
  LLVM :: CodeGen/X86/2009-04-14-IllegalRegs.ll
  LLVM :: CodeGen/X86/2009-06-05-VariableIndexInsert.ll
  LLVM :: CodeGen/X86/2009-06-12-x86_64-tail-call-conv-out-of-sync-bug.ll
```

FWIW the ubuntu toolchain is using its gcc-9 headers/libraries, and clang-11/gcc-9 both seem plenty new to be relevant to LLVM.

</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJy8Wd1zoziQ_2vISxcpEBjMQx4Sx571XT6mkszu3L2kBDRGGyF5JeHE-9dftcCO8zW33qu61MxkbPRr9edP3YJbK1YK8SyYXASTyxPeu1abs9r9fS8WYoMnpa63Z78JaLR8sqcAd1ihclC1XK3QgtNwdfX7NbR8g1Dx3mINGzRbKI1-QgWV7tZCooHnFhWUvZAOnoVroZJcrSCOoTG6g77sleuBRadRehpEl0F0_tAKC3y9Rm4s2DVWohEV7bdHBmxao-NCWihR6ueAFcBVDcuA5RuELTpabnBtdN1XCEIBV1vQrkUDlVaNWPWGO6EViRrEbtBYoVXAZl7ZGtx2jfSpFtYZUfbOPy2g7B1oJbfg0DoymputUCtAXrWgG3CttggcGnwGJzq0o1kHxgkLVW8MKkdiWoQaG95LN1q4d513ajksWQnX9iWYXik0IDq-QlI-YDEp1WjzxpX06OrhPmDFYJCDiivg0moo8dUzNfSWdKcNdNOISnD5Vk6tq6fdfu8MQSj7Feiq6o31LobGoG3h8gByGHjapNFS6mfasuXVE-2_hiCLBkgjJAZZBEEy7hFk0fjHf1zc3V6P2gXJudfvUKO7HzfA1y5coYN-XXNHDsoClsHl_GJ5fvO4uLu9eZjfXAbJpdJKKIeGV05scA8TyjouJYTbIRRhHEPV8SeE9da1WoES6k8eDgmyEu799itBMdQKoXVubckQtgjYYgjeaaW7gC2k3Ox-hWuj_8TKgf_unbCq9l_vjAgms-EZAED3VAszJupnz6v6Vw-9ReE3uCFr4PR01ObtKoDwcnZ9_p_zx4sfy6vLx4f_-j4Pkss7lMgtfrV29ji7vf6-vJrfBcnl3oevi_frfv78sDJgFwG7eLt-FE5UM-ox_3l-_f1qfh8kl7eLxRvRftX85vziav54sby5XN58-7jsUOK49nZ2fn11eTv7X0R-v7v9j_nsgUQGLO-kMAHLv5B8-_1heb387_nl4wNhv81vSPjNr_V4mN9dL28Wt1_p8XB-923-cP_4cDv4wivCWm1dwNhh-gQsAUohn64QzmDMuSEnqharp_Ag5d6W2ZiBXIEjshoYghMrdcINrI3cSIEGnK75lrgmT6O6LHJex1mcYJkkOS-ztEynjKdZnaRVmU_TrKwDVnykw2ch5XCEQEc87f8hdvWnTMOF9OxOHNd5Sv6rF25PsRoMr9CfD1rZvkOgCuYbLiQvJUKHnTZbgj23omqJfJ9b4lTuQHLriH_uftwQ8RAv665DRbyuewdhCEswXIFwpFXPpdzudRGKDid_iqx7s9YW7Y5s_-ytAw4t8tqG_drDxap1YHT1BFvdG-h41QqFIBpQ2hGvg-UNyu0b_4RhePhxPOBKRAU1lv1qNcTmWZunRurnoejpO9piRy4j-wpyp5ZVy4Ua3IEGPSuvjS4ldmSiaIZTTSgvggAWhtOCxD5zo4RaWZDiCV95-rM0GpcGyTkEyaxXT0o_qyCZB8l5NP4F63j1BI3hHYIVf_sTLY6KYhLHGcvzbEpnG75UiDVtSfkXsGnKirTIclZM6LFQ0PSqGk_zXMq2fhRKuIDlgyIJC9jijVQSEp1GUcC8BLsWUvrYHaxKss9QcXSA23AjKMXsL8rooUXqBnw3A0qrsEaHphNKWCeqfT6NC5w_nr1csscO_QSCJQdtuOwp9hQH6t1CfHGoaqwJRhjdUy3VrrWkKi_1Bimlgyxqdj9TUm9MUt8NBFmUs2iST4o0SvKC5QWb-jPY_2oOfwbs-_pFWKFCwylpuLXYlWRSVWlDeSi30HILVnhDO90r540aAs9rKhSqt6-O_Mu-W9P6UbJv32r05bcP-iMx8eNr3PeikssgmUP0EkVRlDdFMp2ymsURNRizgF1EQzIGUbHubQsAAZuYeDJS7gcYG2HsU1i6Z_UPwHQEpm-BHsa-hmUjLPtsv_Lla2A-AvM9sNMbXlJSpNHLLpr1NGAzEsW_FkUnsRcVv8qyfQkjbMDb9df4neksOtQFvBFTAtdiaFHfKPJBzM4ilnwhhpTZifmFa2K-E5R96hu_MsckjzAape3z4aM0trMueZX2og15B8mu2fifL_G7CCfTPZ4Y4S8y6_xw80-Z5Y9dTz2U1VhMw8CwI4lOSG7klqo8evF1_TVnEC0sYdWjpWlv8cfyj-HMsK3uZa0CljtQOCCd7qsWPB-klAADqfR2OCCl1k_DCeEl_D_UdtM0GY8Slv6z2oaPwC-q-4va3sO-qG34qrr3wGOrew_8WN0HwA8ltIdNR9j0mEL8ZPtyxwjxvyvFvSDcCUo_LcWUZdOq-EUV7gRNdpax9E0VDh75pBA_CPiEFKgM4UMZfrZ7vQMXXzDKsDKNor0t6S-K-lxtn7lvVqk_DVhOzSp3sASLOFyl7Cb2w3bONw6-t_d3MgG7gG676_9OAZaqkr3vC4WCisY3rrY0pqK0vkcwvVLDY6pukh2w6UpsUHmK2XfkvhvvDVpQmpjBOBrydQOSWl3frvsJH6i3fN8shO-62XuhKoRnhPXYbXrlDW6EpdqnvqgkjjC46j2PDRTV6F7VIzc5bojyWuqfvAElumfqjjm17YNqw-DiLZokaZSlLK_qJmVFVEyzOubpFHlUT6aM13ExKZsmnpyellmeM8yQRemEl2kRl2lcJ3mWN_l0yibRNIqaIkdOfaAbIvTMLfiJg4IhLHXeCrm_4tHvWuXjbgcCthhsCNii4TwuJ3kdZ1FU5EWEddbUkyJJWRmzLMqrSZpFZVoc7naxGwq8onv_fjIW-PBaKHk9ONvgBo3zieHA9pVvxMeY3u2febHjeKjVEEU_Jg4TWs23FvhKUwA6XfdSgzNi46-alHA-rTo0K_RXc1KQwQUlJSrdr1py5wodaUqDB406fuhZcaE-9KJmuKSsjfZHCyVVMLkIssi7NTkPkvPbNZ0sXNJpSGeNP0Kl4D57gyyyrh4W6teFweQyYNN_HzVWxFlZFPGU5RNWxhwrnFZVmuZFPa0zzqJyghGrfTZ1_Akt-VtpkFqt0MBaWysoszzHLtb-2qri0iefHgpzCIK_nKUiF1bL4YbTt_oWqMsWWlGX7gcDMnt_0Tjc0lnEzh5e4lIK_NnXfsgs3xOAGOip05ZSXCiY6Rq_DaDlMAE7I2g_ipSv5ichJc2WbmCyMaIr7SjjvKIDbeQWOM08a-lH2WEG2m_sLe14jSTItYaS5NejKIy06MP6qufi55SGPBZFWRjHYczC2f0dutnsVMp_CMzDKA7jJLyneea7M0tV48tRcBbGWXhhuKrahZb1UdhpGBXhUkpccflzmoVZem67YyTEURil4flGi3q-uDr_dj_T6-1RAuIwicIrzWtSXqhVeNGvjhLAwnjqBczu50dhp2GUhEkc3tP0jmbc_1gRKbn_Dq-5-xfIPJxpLtFWaI5HszS8xm623h4LnVDOLdWGS1HfmnqmuzU3eKSImIWOC-l5N5wcBZ6GURbOuvW9M6I-bt8pBWz-2-Pd_OHH3U2WHgUuKNsOHc6OhLMi_N2zosQjfU51koUv01zWoeIqjP8v4KPUjiNKlIUU6zX-m1DHMZn94-ohvBcrdRSShSwJK8P_3oa8rg3Nhf8YXlCOJnF4IVb3rWjcUciEavL7b8u5FN1SXX3nR7Bi4Qsz3bHiHa6O0zqj4vh9vNjzbL5UFs1xBmTkvJdp9pilvspCmifCSqtNqHsX6ia0W1WF5UESfjoNjEM47l7JvfZp-3t5amxXVRUW_rIZjaUuRJSGGzFcR9O5u3sPQ12LX1tq1_rjHtYSlduCGm7S_btBiRuu3O4F79hindRnSV0kBT_BszjL40mWF3lx0p5hk1VRWtRlkVdpVcZVUWRJyfNJUkZpmecn4oxFjMWMRSxiWVycZmmV51WaJCWP4qjkQRphx4U8pe7pVJvVibC2x7NJkTF2InmJ0vq31IyRmv5hwFgwuTwxZ77jKvuVDdJICuvsqxQnnMSz8bX1ruuDXU82tdQ9-VFp_5pKq7cvP4d3Eu9eaJNTP85DJ72RZ0c3iN4WCpm39X8CAAD__0XLOLk">