The CommonMark module cannot be built using gcc 15 and perl 5.40.1

[eseyman]

This is perl-5.40.1-515.fc42 as packaged in Fedora rawhide (the dev branch of Fedora)

Module: XS

Description
Since upgrading from gcc 14 to 15, the perl-CommonMark package cannot be rebuild. This does not look like an error in the CommonMark module but one in the XS module from core.

gcc -c   -D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   -DVERSION=\"0.310100\" -DXS_VERSION=\"0.310100\" -fPIC "-I/usr/lib64/perl5/CORE"   CommonMark.c
CommonMark.c: In function ‘XS_CommonMark__Node_interface_get_node’:
CommonMark.c:675:18: error: too many arguments to function ‘XSFUNCTION’; expected 0, have 1
  675 |         RETVAL = XSFUNCTION(node);
      |                  ^~~~~~~~~~ ~~~~
CommonMark.c: In function ‘XS_CommonMark__Node_interface_get_int’:
CommonMark.c:701:18: error: too many arguments to function ‘XSFUNCTION’; expected 0, have 1
  701 |         RETVAL = XSFUNCTION(node);
      |                  ^~~~~~~~~~ ~~~~
[...]

Steps to Reproduce
Build the CommonMark module using gcc 15 and Perl 5.40.1

Expected behavior
The module should build successfully

Perl configuration

+ /usr/bin/perl -V
Summary of my perl5 (revision 5 version 40 subversion 1) configuration:
   
  Platform:
    osname=linux
    osvers=6.11.0
    archname=x86_64-linux-thread-multi
    uname='linux localhost 6.11.0 #1 smp preempt_dynamic 6.11.0 x86_64 gnulinux '
    config_args='-des -Doptimize=none -Dccflags=-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Dldflags=-Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1   -Dccdlflags=-Wl,--enable-new-dtags -Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1   -Dlddlflags=-shared -Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1   -Dshrpdir=/usr/lib64 -DDEBUGGING=-g -Dversion=5.40.1 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5/5.40 -Dsitearch=/usr/local/lib64/perl5/5.40 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize -Duse64bitint'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
  Compiler:
    cc='gcc'
    ccflags ='-D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    optimize='  -g'
    cppflags='-D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fwrapv -fno-strict-aliasing -I/usr/local/include'
    ccversion=''
    gccversion='15.0.1 20250114 (Red Hat 15.0.1-0)'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='gcc'
    ldflags ='-Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1  -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib64 /lib64 /usr/lib64 /usr/local/lib /usr/lib
    libs=-lpthread -lresolv -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lpthread -lresolv -ldl -lm -lcrypt -lutil -lc
    libc=/lib/../lib64/libc.so.6
    so=so
    useshrplib=true
    libperl=libperl.so
    gnulibc_version='2.40.9000'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,--enable-new-dtags -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 '
    cccdlflags='-fPIC'
    lddlflags='-lpthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1  -L/usr/local/lib -fstack-protector-strong'


Characteristics of this binary (from libperl): 
  Compile-time options:
    HAS_LONG_DOUBLE
    HAS_STRTOLD
    HAS_TIMES
    MULTIPLICITY
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_HASH_FUNC_SIPHASH13
    PERL_HASH_USE_SBOX32
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    PERL_USE_SAFE_PUTENV
    USE_64_BIT_ALL
    USE_64_BIT_INT
    USE_ITHREADS
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
    USE_REENTRANT_API
    USE_SITECUSTOMIZE
    USE_THREAD_SAFE_LOCALE
  Locally applied patches:
    Fedora Patch1: Removes date check, Fedora/RHEL specific
    Fedora Patch2: support for libdir64
    Fedora Patch3: use libresolv instead of libbind
    Fedora Patch4: USE_MM_LD_RUN_PATH
    Fedora Patch5: Provide MM::maybe_command independently (bug #1129443)
    Fedora Patch6: Dont run one io test due to random builder failures
    Fedora Patch8: Define SONAME for libperl.so
    Fedora Patch9: Install libperl.so to -Dshrpdir value
    Fedora Patch10: Make *DBM_File desctructors thread-safe (RT#61912)
    Fedora Patch11: Replace EU::MakeMaker dependency with EU::MM::Utils in IPC::Cmd (bug #1129443)
    Fedora Patch12: Link XS modules to pthread library to fix linking with -z defs
    Fedora Patch13: Pass the correct CFLAGS to dtrace
    Fedora Patch200: Link XS modules to libperl.so with EU::CBuilder on Linux
    Fedora Patch201: Link XS modules to libperl.so with EU::MM on Linux
    Fedora Patch202: Add definition of OPTIMIZE to .ph files
  Built under linux
  Compiled at Jan 20 2025 00:00:00
  @INC:
    /usr/local/lib64/perl5/5.40
    /usr/local/share/perl5/5.40
    /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib64/perl5
    /usr/share/perl5

[mauke]

This looks like it's caused by a combination of gcc-15 and the INTERFACE: XS feature.

[jkeenan]

Can someone who has access to gcc-15 or later on Linux build a threaded perl-5.40.1 and attempt to install Common Mark. (I can only get gcc-14.)

[xenu]

GCC 15 hasn't been released yet. But anyway, this issue is because GCC 15 bumped the default C standard version to C23, and in C23 the meaning of an empty prototype has changed.

[iabyn]

In the presence of the INTERFACE keyword (which allows the same XSUB to wrap multiple C functions by storing a pointer to the C function in every CV associated with that XSUB), the C code generated by the XS parser relies on the XSINTERFACE_CVT macro to declare a function pointer variable. In XSUB.h, this macro is defined as: #ifdef __cplusplus # define XSINTERFACE_CVT(ret,name) ret (*name)(...) #else # define XSINTERFACE_CVT(ret,name) ret (*name)() #endif Presumably gcc-15 is complaining about a pointer to a function which has non-zero number of args begin declared as some_type (*my_function_ptr_var)() Is there a portable way in C to tell the compiler not to complain about this, or so we need to make the generated C code in some way include the function arg types?

…

-- "I used to be with it, but then they changed what ‘it’ was, and now what I’m with isn’t it. And what’s ‘it’ seems weird and scary to me." -- Grandpa Simpson (It will happen to you too.)

[iabyn]

(Moving this discussion back onto problem ticket, rather than PR #23194) Leon wrote:

I'm not sure this fix is right (I have to dig deeper for that), but I am very sure that the implementation of the `INTERFACE` feature is rather broken and should probably be fixed. xsubpp knows the types of the arguments of the function, it should be able to cast to the right type without needing this silly macro.

It's complicated by the fact that there is also the INTERFACE_MACRO: XS keyword, which allows code to specify their own macros to replace the default XSINTERFACE_FUNC and XSINTERFACE_FUNC_SET macros. I'm not sure it would be possible to change things in a back-compat way for code which defines its own macros. On the other hand, the INTERFACE_MACRO appears to be almost completely unused on CPAN: just two distros, MIME-Fast and Wx. Compared with 16(*) CPAN distros which use the INTERFACE: keyword. So perhaps breaking the former is acceptable? In any event, I currently have a WIP branch which has over 100 commits and which almost completely rewrites the XS parser, and which I planned to merge post-5.42.0 release. It would be (I imagine) a royal pain to fix INTERFACE in blead and *then* rebase my branch over that. On the other hand, it would be nice to get some sort of basic fix into the 5.42.0 release. Presumably over the next 2 years, gcc-15 is going to become mainstream, and then 5.42.0 will start breaking on XS modules with INTERFACE. Could the proposed '...' fix or similar to XSUB.h be used now as a stop-gap measure, then I'd fix INTERFACE properly post 5.42.0???

…

-- But Pity stayed his hand. "It's a pity I've run out of bullets", he thought. -- "Bored of the Rings"

[Leont]

Could the proposed '...' fix or similar to XSUB.h be used now as a
stop-gap measure, then I'd fix INTERFACE properly post 5.42.0???

That's not a good fix either, becaus vararg argument passing is not guaranteed to be the same as non-vararg argument passing. Most notably it isn't on Apple on ARM.

[xenu]

On the other hand, the INTERFACE_MACRO appears to be almost completely
unused on CPAN: just two distros, MIME-Fast and Wx

Just MIME::Fast, it's commented out (with #if 0) in Wx.

[Leont]

MIME::Fast looks to me like it needs to use PREFIX instead.

But also, it hasn't been updated in 20+ years (and gnome certainly hasn't been standing still in that period), and no passing entries are known on CPAN Testers. I think we can assume it's dead.

[Leont]

It's complicated by the fact that there is also the INTERFACE_MACRO:

Yeah I don't think it was possible to write a sensible INTERFACE_MACRO before vararg macros, but we can actually make something better now.

Though I'm still not quite sure when someone would ever need this feature.

[iabyn]

On Mon, Apr 14, 2025 at 05:12:09AM -0700, Leon Timmermans wrote: Leont left a comment (Perl/perl5#23192) > Could the proposed '...' fix or similar to XSUB.h be used now as a stop-gap measure, then I'd fix INTERFACE properly post 5.42.0??? That's not a good fix either, becaus vararg argument passing is not guaranteed to be the same as non-vararg argument passing. Most notably it isn't on Apple on ARM.

Thinking some more: C_ARGS is going to be a problem. For example, with: foo(int a, char *b) INTERFACE: ...... C_ARGS: munge(b), a, FOO_SOME_FLAG C_ARGS is just an uninterpreted string which is used as-is to generate the call to the real C function. We have no idea what munge returns, or whether FOO_SOME_FLAG is a int or pointer or whatever. We can't even know the number of args: for example, munge() might be a macro which expands to "b, strlen(b)". So in general, the XS parser can't know the signature of the C function. Unless there is some new C feature I don't know about which provides that info? A sort of __FUNCTION_SIGNATURE__(some_function_name)?? We leads me to wonder: is there a viable fallback position for an INTERFACE XSUB which also contains C_ARGS? Such as a pragma which turns off arg checking? But if so, couldn't we just use that always? Just out of curiosity, does any C expert one know how detailed the function pointer declaration has to be? For example, could we just declare all args as 'void *' or something like that? (Note: my C knowledge is basically K&R, albeit updated with the newfangled ANSI way of declaring a function's parameters. I don't understand all this fancy C99 and later stuff.)

…

-- This email is confidential, and now that you have read it you are legally obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have received this email in error, place it in its original wrapping and return for a full refund. By opening this email, you accept that Elvis lives.

[Leont]

Thinking some more: C_ARGS is going to be a problem.

That is a good point. Yeah that will be hairy.

Unless there is some new C feature I don't know about which provides that
info? A sort of FUNCTION_SIGNATURE(some_function_name)??

C23 actually has a typeof operator, but we can't exactly require C23.

Just out of curiosity, does any C expert one know how detailed the
function pointer declaration has to be? For example, could we just declare
all args as 'void *' or something like that?

Absolutely not. In the original version of C all arguments were word sized so none of this mattered, but that has long stopped being the case.