"invalid subrange count" compiling [(); 1 << 63] with -g enabled

dae892a
Opened by Oliver Middleton at 2025-01-08 08:34:55

The following produces an LLVM error with -g enabled:

let _a = [(); 1 << 63];

The error is:

invalid subrange count
!16 = !DISubrange(count: -9223372036854775808)
LLVM ERROR: Broken function found, compilation aborted!

  1. cc @michaelwoerister

    Simonas Kazlauskas at 2016-06-07 13:19:12

  2. Thanks for the bug report!

    Michael Woerister at 2016-06-07 15:26:37

  3. I've also hit this (with similar code), but in my case the "invalid subrange count" message showed up, but the code still compiled and passed the tests. Not sure if it's miscompiled or not.

    Edit: Obviously this didn't crash because llvm assertions are disabled in stable. Yeah, still an important question around: is the code at risk of being miscompiled?

    Cristi Cobzarenco at 2017-10-28 20:32:12

  4. Yeah, still an important question around: is the code at risk of being miscompiled?

    The error comes from the debuginfo verifier, so I think at worst you'd see invalid or incorrect DWARF.

    Tom Tromey at 2018-11-20 15:33:02

  5. cc @scottmcm We can't actually produce valid debuginfo for "truly large" arrays, it seems, even if they're ZSTs.

    Jubilee at 2023-03-15 22:08:34

  6. WG-prioritization assigning priority (Zulip discussion).

    @rustbot label -I-prioritize +P-medium

    apiraino at 2023-09-04 08:57:40

  7. Not sure if it matters at all, but [(); usize::MAX] compiles, while [(); usize::MAX - 1] hits the ICE. strange

    Meriel Luna Mittelbach at 2024-05-06 10:37:08

  8. As per the issue I opened, #129548, which I'm closing as duplicate, I found out some more information.

    When ran on Windows via rustup run <toolchain> ..., it reported some more details, including via the reason the process died.

    • rustc-LLVM ERROR: Broken module found, compilation aborted!
rustc-LLVM ERROR: out of memory
Allocation failed
    • exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN

    Kiril Mihaylov at 2024-08-25 18:43:30

  9. I think rustc should reject arrays with more than isize::MAX elements.

    Demi Marie Obenour at 2025-01-07 19:21:38

  10. @DemiMarie it already does for non-ZSTs. TBH I'd like to for ZSTs too, but I don't know any way to do that under the stability guarantees, so it probably can't happen.

    scottmcm at 2025-01-08 04:45:19

  11. @scottmcm What about emitting an error whenever debuginfo is being generated or in a sufficiently new edition? That would turn this bug into “works as intended”, except that it would no longer be an ICE but just a regular error.

    Demi Marie Obenour at 2025-01-08 08:29:43

  12. Editions don't help for type system changes, because I can call another crate on an older edition that returns me an array with over isize::MAX elements. Similarly, array::from_fn::<(), {usize::MAX-1}, _> needs to continue to exist in std.

    scottmcm at 2025-01-08 08:34:55