ci: Re-enable GDC workflow

[Geod24]

No description provided.

[github-actions]

✅ PR OK, no changes in deprecations or warnings

Total deprecations: 0

Total warnings: 0

Build statistics:

 statistics (-before, +after)
 executable size=5109296 bin/dub
-rough build time=62s
+rough build time=61s

Full build output

DUB version 1.39.0, built on Mar 20 2025
LDC - the LLVM D compiler (1.40.1):
  based on DMD v2.110.0 and LLVM 19.1.7
  built with LDC - the LLVM D compiler (1.40.1)
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver3
  http://dlang.org - http://wiki.dlang.org/LDC


  Registered Targets:
    aarch64     - AArch64 (little endian)
    aarch64_32  - AArch64 (little endian ILP32)
    aarch64_be  - AArch64 (big endian)
    amdgcn      - AMD GCN GPUs
    arm         - ARM
    arm64       - ARM64 (little endian)
    arm64_32    - ARM64 (little endian ILP32)
    armeb       - ARM (big endian)
    avr         - Atmel AVR Microcontroller
    bpf         - BPF (host endian)
    bpfeb       - BPF (big endian)
    bpfel       - BPF (little endian)
    hexagon     - Hexagon
    lanai       - Lanai
    loongarch32 - 32-bit LoongArch
    loongarch64 - 64-bit LoongArch
    mips        - MIPS (32-bit big endian)
    mips64      - MIPS (64-bit big endian)
    mips64el    - MIPS (64-bit little endian)
    mipsel      - MIPS (32-bit little endian)
    msp430      - MSP430 [experimental]
    nvptx       - NVIDIA PTX 32-bit
    nvptx64     - NVIDIA PTX 64-bit
    ppc32       - PowerPC 32
    ppc32le     - PowerPC 32 LE
    ppc64       - PowerPC 64
    ppc64le     - PowerPC 64 LE
    r600        - AMD GPUs HD2XXX-HD6XXX
    riscv32     - 32-bit RISC-V
    riscv64     - 64-bit RISC-V
    sparc       - Sparc
    sparcel     - Sparc LE
    sparcv9     - Sparc V9
    spirv       - SPIR-V Logical
    spirv32     - SPIR-V 32-bit
    spirv64     - SPIR-V 64-bit
    systemz     - SystemZ
    thumb       - Thumb
    thumbeb     - Thumb (big endian)
    ve          - VE
    wasm32      - WebAssembly 32-bit
    wasm64      - WebAssembly 64-bit
    x86         - 32-bit X86: Pentium-Pro and above
    x86-64      - 64-bit X86: EM64T and AMD64
    xcore       - XCore
    xtensa      - Xtensa 32
   Upgrading project in /home/runner/work/dub/dub/
    Starting Performing "release" build using /opt/hostedtoolcache/dc/ldc2-1.40.1/x64/ldc2-1.40.1-linux-x86_64/bin/ldc2 for x86_64.
    Building dub 1.39.0-rc.1+commit.56.gf4982884: building configuration [application]
     Linking dub
STAT:statistics (-before, +after)
STAT:executable size=5109296 bin/dub
STAT:rough build time=61s

[Geod24]

#10 63.31 source/dub/internal/dyaml/node.d: In function '__unittest_L2579_C7':
#10 63.31 source/dub/internal/dyaml/node.d:2582:12: internal compiler error: in dwarf2out_imported_module_or_decl, at dwarf2out.cc:27552

Wonderful

[ibuclaw]

#10 63.31 source/dub/internal/dyaml/node.d: In function '__unittest_L2579_C7':
#10 63.31 source/dub/internal/dyaml/node.d:2582:12: internal compiler error: in dwarf2out_imported_module_or_decl, at dwarf2out.cc:27552

Wonderful

Raise bug reports. ;-)

https://gcc.gnu.org/bugzilla

[Geod24]

@ibuclaw : I don't have an account. You can easily reproduce with:

$ podman run --rm -it alpine:edge
$ apk add --no-cache bash build-base curl curl-dev dtools dub git grep rsync gcc-gdc
$ git clone https://github.com/dlang-community/D-YAML.git
$ cd D-YAML
$ dub test --compiler=gdc

ICE is:

source/dyaml/node.d: In function '__unittest_L2579_C7':
source/dyaml/node.d:2582:12: internal compiler error: in dwarf2out_imported_module_or_decl, at dwarf2out.cc:27552
 2582 |     import std : split, to;
      |            ^
0x210ff69 internal_error(char const*, ...)
        ???:0
0x8272ff fancy_abort(char const*, int, char const*)
        ???:0
0xaaca1b DeclVisitor::visit(Import*)
        ???:0
0xaa769a build_decl_tree(Dsymbol*)
        ???:0
0xabb321 IRVisitor::visit(ImportStatement*)
        ???:0
0xabb39f IRVisitor::visit(CompoundStatement*)
        ???:0
0xabb39f IRVisitor::visit(CompoundStatement*)
        ???:0
0xabaa8c build_function_body(FuncDeclaration*)
        ???:0
0xaad92f DeclVisitor::visit(FuncDeclaration*)
        ???:0
0xaaba28 DeclVisitor::visit(AttribDeclaration*)
        ???:0
0xaa769a build_decl_tree(Dsymbol*)
        ???:0
0xab8c90 build_module_tree(Module*)
        ???:0
0xaaa5db DeclVisitor::visit(Module*)
        ???:0
0xaa769a build_decl_tree(Dsymbol*)
        ???:0

And relevant packages:

(12/71) Installing binutils (2.44-r0)
(51/71) Installing dtools (2.111.0-r0)
(56/71) Installing ldc-runtime (1.40.1-r0)
(57/71) Installing dub (1.40.0-r0)
(58/71) Installing libucontext (1.3.2-r0)
(59/71) Installing libucontext-dev (1.3.2-r0)
(60/71) Installing libgphobos (14.2.0-r5)
(61/71) Installing gcc-gdc (14.2.0-r5)

[ibuclaw]

@Geod24 given the location of the ICE, I guess you can compile with -g0 to disable debugging as a workaround.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119817

In within hours of gcc-15.1 being branched for release.

gcc-mirror/gcc@f5ed7d1

[Geod24]

Good catch (and timing)!

[the-horo]

Somewhat hidden but this fixes dub-as-a-library-cwd for me:

diff --git i/test/dub-as-a-library-cwd/subproject/dub.sdl w/test/dub-as-a-library-cwd/subproject/dub.sdl
index cb896c94..d1c5119c 100644
--- i/test/dub-as-a-library-cwd/subproject/dub.sdl
+++ w/test/dub-as-a-library-cwd/subproject/dub.sdl
@@ -1 +1,2 @@
 name "subproject"
+buildRequirements "allowWarnings"

[the-horo]

For issue2698-cimportpaths-broken-with-dmd-ldc doing .no_build_gdc should be enough

[Geod24]

@the-horo : Thanks! I might hop on an Alpine later and try to reproduce locally. Although in that instance I would like to know what the warning is before disabling it. Likewise, for cimportpath, is it genuinely broken or it's just testing a functionality that GDC doesn't have ?

[Geod24]

I also would like to look into #2938

[Geod24]

Regarding warnings, I had the start of a fix in #2324

[the-horo]

Although in that instance I would like to know what the warning is before disabling it

dub/test/dub-as-a-library-cwd/subproject/source/app.d

Line 3 in c7c020b

deprecated("FIND_THIS_STRING")

And, like you said in the other issue, since dub adds -Werror by default and gdc treats deprecations as warnings this leads to the compiler invocation failing.

Likewise, for cimportpath, is it genuinely broken or it's just testing a functionality that GDC doesn't have ?

gdc doesn't support #include in importC:

happy@happylaptop /tmp/x $ cat a.d
import b;
happy@happylaptop /tmp/x $ cat b.c
#include <stdio.h>
happy@happylaptop /tmp/x $ gdc-15 -c a.d
b.c:1:1: error: C preprocessor directive ‘#include’ is not supported
    1 | #include <stdio.h>
      | ^
b.c:1:1: error: no type for declarator before ‘#’
    1 | #include <stdio.h>
      | ^

So skipping the test is appropriate.

Regarding warnings, I had the start of a fix in #2324

Fighting against the unittest runner myself and slowly going through flaky-tests vs genuinely unsupported gdc stuff. My main issue are the warnings (esp with gdc-15). I thought that DFLAGS=-Wno-error would work but I found out that passing DFLAGS with dub test makes dub no longer pass -funittest. I've looked a bit over the code and the most sane thing I could think off is removing the $DFLAGS configuration and simply having the DFLAGS environment variable be appended to the flags of the current configuration. This way DFLAGS=... dub test would still pass -unittest and respect the user flags. You also have dub -b plain if you actually wanted to ignore the default flags passed by dub. I didn't look into this a lot but what do you think?

[rikkimax]

gdc doesn't support #include in importC:

happy@happylaptop /tmp/x $ cat a.d
import b;
happy@happylaptop /tmp/x $ cat b.c
#include <stdio.h>
happy@happylaptop /tmp/x $ gdc-15 -c a.d
b.c:1:1: error: C preprocessor directive ‘#include’ is not supported
    1 | #include <stdio.h>
      | ^
b.c:1:1: error: no type for declarator before ‘#’
    1 | #include <stdio.h>
      | ^

Something majorly funky appears to be going on here. @ibuclaw any ideas?

[the-horo]

Something majorly funky appears to be going on here. @ibuclaw any ideas?

From https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gdc/ImportC.html:

ImportC does not have a preprocessor. It is designed to compile C files after they have been first run through the C preprocessor. If the C file has a ‘.i’ extension, the file is presumed to be already preprocessed. Preprocessing can be run manually:

  gcc -E file.c > file.i