BUG?: Passing flags for .S doesn't seem to work

[HaoZeke]

Consider the following:

{'c_args' : ['-DBUILD_SINGLE=1', '-DBUILD_DOUBLE=1', '-DBUILD_COMPLEX=1',
 '-DBUILD_COMPLEX16=1', '-m64', '-DSMP_SERVER', '-DBUILD_SINGLE=1',
 '-DBUILD_DOUBLE=1', '-DBUILD_COMPLEX=1', '-DBUILD_COMPLEX16=1',
 '-UASMNAME', '-UASMFNAME', '-UNAME', '-UCNAME', '-UCHAR_NAME',
 '-UCHAR_CNAME', '-DNO_AFFINITY', '-DNO_WARMUP', '-DDOUBLE', '-UCOMPLEX',
 '-DSMALL_MATRIX_OPT', '-DF_INTERFACE_GFORT', '-fPIC', 
'-DASMNAME=dgemm_kernel', '-DASMFNAME=dgemm_kernel_', 
'-DNAME=dgemm_kernel_', '-DCNAME=dgemm_kernel', '-DCHAR_NAME="dgemm_kernel_"', 
'-DCHAR_CNAME="dgemm_kernel"'], 'name' : 'dgemm_kernel',
 'src' : 'x86_64/dgemm_kernel_4x8_haswell.S'}

However, when I check the output of the logs I get:

[4361/7202] /home/rgoswami/micromamba/envs/numpy-dev/bin/x86_64-conda-linux-gnu-gfortran 
-Ikernel/libdgemm_kernel.a.p -Ikernel -I../kernel -I. -I..
 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -O0 -g 
-Wno-conversion -march=nocona -mtune=haswell -ftree-vectorize 
 -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem
 /home/rgoswami/micromamba/envs/numpy-dev/include -fPIC 
-Jkernel/libdgemm_kernel.a.p -o 
kernel/libdgemm_kernel.a.p/x86_64_dgemm_kernel_4x8_haswell.S.o -c ../kernel/x86_64/dgemm_kernel_4x8_haswell.S

Which ignores the definition

foreach conf : kernel_confs
    _kern_libs += [static_library(
        conf['name'],
        conf['src'],
        include_directories: _inc,
        c_args: conf['c_args'],
    )]
endforeach

I can update this with a full MWE as well, but was wondering if there's something obvious I'm missing. From #10497 (#10497 (comment)) and #10431 it seems like this should work.

[HaoZeke]

As a workaround for now, I'm generating dependencies when an .S source is used instead:

      _kern_deps += declare_dependency(
          sources: conf['src'],
          include_directories:  _inc,
          compile_args: conf['c_args'],
      )

Which does allow the flags to be passed through:

[1/4] /home/rgoswami/micromamba/envs/numpy-dev/bin/x86_64-conda-linux-gnu-gfortran -Ikernel/libdgemm_kernel.a.p -Ikernel/lib_kern.a.p
 -Ikernel -I../kernel -I. -I.. -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64
 -Wall -O0 -g -march=nocona -mtune=haswell -ftree-vectorize 
-fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections 
-pipe -isystem /home/rgoswami/micromamba/envs/numpy-dev/include
 -fPIC -m64 -DSMP_SERVER -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1
 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -UASMNAME -UASMFNAME
 -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DNO_AFFINITY
 -DNO_WARMUP -DDOUBLE -UCOMPLEX -DSMALL_MATRIX_OPT -DF_INTERFACE_GFORT -DASMNAME=dgemm_kernel -DASMFNAME=dgemm_kernel_
-DNAME=dgemm_kernel_ -DCNAME=dgemm_kernel 
'-DCHAR_NAME="dgemm_kernel_"' '-DCHAR_CNAME="dgemm_kernel"'
 -Jkernel/lib_kern.a.p -o kernel/lib_kern.a.p/x86_64_dgemm_kernel_4x8_haswell.S.o
 -c ../kernel/x86_64/dgemm_kernel_4x8_haswell.S

But this feels very hacky, and the c_args should be passed through for GNU assembly files AFAIK..

[HaoZeke]

FWIW I can't find any tests checking that you can pass c_args with .S (there's test_always_prefer_c_compiler_for_asm and test_option_key_from_string but neither check for this).

[HaoZeke]

Minor update on this, it only shows up if both c and fortran are in languages, and the reason is simple (but still unintuitive), the .S file is compiled by gfortran, not gcc so c_args doesn't get picked up... but fortran_args are picked up.

[HaoZeke]

TL;DR (issue forthcoming) it is odd that if c and fortran are present that gfortran is used for .S files, a fix would be either documenting this, or preferably switching to using gcc and c_args for all .S files..

[rgommers]

Did you end up submitting that issue @HaoZeke? This seems to be fairly annoying once you add a Fortran-specific compile argument with add_project_arguments, since it results in:

[6314/7404] Compiling Fortran object kernel/libdamax_k.a.p/x86_64_amax_sse2.S.o
cc1: warning: command-line option '-Wno-unused-dummy-argument' is valid for Fortran but not for C

[dcbaker]

I really wish that we had treated .s/.S as it's own language instead of making it a C source....

#13940

[rgommers]

Thanks @dcbaker!