Compiling with -fno-automatic still produces a stack overflow error - compilation

I'm calling some Fortran code from Julia and am getting a stack overflow error.
From what I can see in the gfortran man page, when using the -fno-automatic flag, the stack is never used however I'm still getting a stack overflow. Interestingly, if I compile on a Mac (rather than Linux) I don't get this stack overflow.
I've also tried setting ulimit -s in the shell to no avail, any further ideas to debug would be greatly appreciated!
Mac gfortran version
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/12.2.0/bin/../libexec/gcc/aarch64-apple-darwin22/12/lto-wrapper
Target: aarch64-apple-darwin22
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc --libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-12 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 12.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --with-system-zlib --build=aarch64-apple-darwin22 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Homebrew GCC 12.2.0)
Linux gfortran version
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
Compiler commands
gfortran -J./src -fsyntax-only -c -ffree-line-length-300 src/module_1.f90
gfortran -J./src -fsyntax-only -c -ffree-line-length-300 src/module_2.f90
gfortran -J./src -fsyntax-only -c -ffree-line-length-300 src/module_3.f90
gfortran -J./src -fsyntax-only -c -ffree-line-length-300 src/module_4.f90
gfortran -shared -fPIC -ffree-line-length-300 -g -fbounds-check -Wall -Wno-tabs ./src/file1.f90 ./src/file2.f90 ./src/file3.f90 ./src/file4.f90 ./src/file5.f90 ./src/file6.f90 -o shared_object_file.so
Error message (originates from Julia)
┌ Error: ERROR:
│ exception =
│ StackOverflowError:
An update
An update, I'm note sure it's a stack overflow issue after running the code via gdb. I can see that when a subroutine (passed to subroutine1 as argument f) is called it instantly segfaults:
Thread 1 "julia" hit Breakpoint 1, module1::subroutine1 (m1=0, m2=11, n1=1, n2=66, n=66, id=...,
f=0x1554b2c4de9c, j=0x1554b2c4de80, max_iter=100, x=..., y=..., tol=1e-08, iflag=.TRUE.) at ./src/solve_model.f90:261
261 do k=1, max_iter
(gdb) step
262 call F()
(gdb) step
Thread 1 "julia" received signal SIGSEGV, Segmentation fault.
0x00001554b2c4de9c in ?? ()
It appears that subroutine f isn't entered, just the call to it causes the segfault.
Below is an example of subroutine1:
subroutine subroutine1(arg1, arg2, arg3, arg4, arg5, arg6, F, J, arg9, arg10)
implicit none
interface
subroutine F(arg1, arg2, arg3, arg4, arg5, arg6)
use ISO_FORTRAN_ENV, only: int64
integer(int64), intent(in) :: arg1, arg2, arg3, arg4, arg5, arg6(arg5)
double precision, intent(inout)::arg9(arg1:arg2, arg3:arg4)
double precision, intent(out):: arg10(arg1:arg2, arg5), y(arg1:arg2, arg3:arg4)
end subroutine

Related

"-m32" option of gcc is not working in gitpod environment. (Bad system call)

I am trying to execute "hello world" program in gitpod environment in 32bit by using "-m32" option. However, I cannot get a good result "hello world". I can only get "Bad system call".
Here is my test.c (hello world program)
#include<stdio.h>
int main() {
printf("hello world!\n");
return 0;
}
I only installed "gcc-multilib" to use "-m32" option
sudo apt-get install gcc-multilib
The below command is compile command.
gcc -m32 test.c
Then, I can get the result. (The process create core.* file e.g. core.2893)
gitpod /workspace/csapp-labs/test (main) $ gcc -m32 test.c
gitpod /workspace/csapp-labs/test (main) $ ./a.out
Bad system call (core dumped)
Here is my gcc environment.
gitpod /workspace/csapp-labs/test (main) $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.4.0-1ubuntu1~20.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
Some people said it can be caused by seccomp. However, I can't find something wrong on my system.conf file (/etc/systemd/system.conf)
...
#CapabilityBoundingSet=
#NoNewPrivileges=no
#SystemCallArchitectures=
#TimerSlackNSec=
#StatusUnitFormat=description
#DefaultTimerAccuracySec=1min
...
please see https://github.com/gitpod-io/gitpod/issues/7358
32bit is not supported as of now. You could utilize a qemu microvm for accomplishing what you want inside a Gitpod workspace.

warnings while trying to compile old linux kernel with gcc 12.1.0

I am currently hunting a bug using git bisect in linux staging-testing tree.
Some commits are giving following errors after I try to build them:
subcmd-util.h:58:31: error: pointer may be used after ‘realloc’ [-Werror=use-after-free]
58 | ret = realloc(ptr, 1);
check.c:2867:58: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 9 [-Werror=format-truncation=]
2867 | snprintf(pvname, sizeof(pvname), "pv_ops[%d]", idx);
I tried adding -Wno-error=use-after-free to KBUILD_FLAGS in main Makefile, tried adding
KBUILD_CFLAGS += $(call cc-disable-warning, use-after-free)
I even tried removing -Werror from CFLAGS in Makefile in folder where problematic files are located, but nothing worked.
More information:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.artixlinux.org/ --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)
Linux staging tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git.
One of the commits that gives following warnings: 2ab9c9675fe892e7fe9fa8c0a6125e2b40d2889d.
To compile older version of kernel I needed older compiler ("Linux kernel sources are in general not forward-compatible with new compilers"). In my case the kernel version was 5.16.0 and I could compile it with gcc 11. If you have gcc 11 specific warnings then try gcc 10 and so on.
Except CC flags, I also needed set to HOSTCC flags to use gcc-11 compiler:
make HOSTCC=gcc-11 CC=gcc-11

GCC built out ELF64 binary but cannot execute binary file: Exec format error

I met strange issues about ELF32/ELF64 format in my building machine.
Both applications and kernle module don't work.
For applications (such as helloworld program), it can be built out to ELF64 but run failed.
For kernel modules it will always be built out to ELF32 format even if append -march=x86-64 to CFLGAS, which leads to Module has invalid ELF structures issue when insmoding.
If append -m64 and it will lead to cc1: error: CPU you selected does not support x86-64 instruction set
I guess when the first question fixed, the next will also be fixed, so I only post the first one here.
Ubunt 18.04, gcc 7.5.0 , x86_64 PC
GCC built out helloworld program to ELF64 binary but cannot run
gcc -o hello -v -c hello.c
...
chmod +x hello
./hello
-bash: ./hello: cannot execute binary file: Exec format error
uname -a
Linux AELAB146 5.4.0-74-generic #83~18.04.1-Ubuntu SMP Tue May 11 16:01:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
Kernel Module's Makefile
EXTRA_CFLAGS += -Wall (and others blablabla) -m64
KERNEL_BUILD ?= /lib/modules/$(shell uname -r)/build
pcie_objs := common/init.o common/pcie.o common/net.o platform.o
obj-m := pcie.o
pcie.o: $(pcie_objs)
ld -r $^ -o $#
all:
make -C $(KERNEL_BUILD) M=$(PWD) V=1 modules
I'v no idea about why it's so long for the gcc Configured options in my system.
You're not supposed to pass -c to GCC when building an executable. It means to compile and not link, but programs need to be linked to be ran. The fact that you had to do chmod +x hello should have been a clue that you were doing something very wrong. Run gcc -o hello -v hello.c and then ./hello.
I assume your issue with kernel modules is similarly caused by an incorrect command line, but since you didn't post the command line you used for it, I can't see where you went wrong with it.

How to add '-march=' as default option to gcc?

I can not compile a simple c program without specifying '-march=native', I need to run it as: 'gcc -march=native -o hello hello.c'.
I did:
export CFLAGS='-march=native'
export CXXFLAGS='-march=native'
but didn't help.
user#server:~$ gcc -march=native -Q --help=target
...
-march=corei7-avx
...
Output of gcc -v:
user#server:~$ gcc -v
Using built-in specs.
gcc: error: missing argument to ‘-march=’
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
Where and how can I add this option to be default?
Two options:
Hard way. You may dump your specs file with gcc -dumpspecs > specs
command. Now put this file to /usr/lib/gcc/x86_64-linux-gnu/4.7/
folder and edit it to add option as described in documentation.
In your case I suggest to start from removing all
march=<something> lines, this might trivially help. But general case is troubles and creativity at this point.
Easy way: rename gcc binary to, say gcc-4.7 and make alias with
alias gcc='gcc-4.7 -march=native'

gcc not finding cc1 for mingw on cygwin under Emacs

Ok, so long title... I have switched out my Mingw Emacs for the Cygwin emacs-w32 but have run into some challenging path(?) issue.
I compile using i686-w64-mingw32-gcc (previously known as -mno-cygwin).
In a normal terminal I get:
$ i686-w64-mingw32-gcc exp.c -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-w64-mingw32/4.8.2/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: /cygdrive/i/szsz/tmpp/32gcc/mingw64-i686-gcc-4.8.2-1/src/gcc-4.8.2/configure --srcdir=/cygdrive/i/szsz/tmpp/32gcc/mingw64-i686-gcc-4.8.2-1/src/gcc-4.8.2 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share --docdir=/usr/share/doc/mingw64-i686-gcc --htmldir=/usr/share/doc/mingw64-i686-gcc/html -C --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-w64-mingw32 --without-libiconv-prefix --without-libintl-prefix --with-sysroot=/usr/i686-w64-mingw32/sys-root --with-build-sysroot=/usr/i686-w64-mingw32/sys-root --disable-multilib --disable-win32-registry --enable-languages=c,ada,c++,fortran,objc,obj-c++ --enable-fully-dynamic-string --enable-libgomp --enable-sjlj-exceptions --enable-version-specific-runtime-libs --with-dwarf2 --enable-decimal-float=bid --enable-lto
Thread model: win32
gcc version 4.8.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=pentiumpro'
/usr/libexec/gcc/i686-w64-mingw32/4.8.2/cc1.exe -quiet -v -U_REENTRANT exp.c -quiet -dumpbase exp.c -mtune=generic -march=pentiumpro -auxbase exp -version -o /tmp/cc6glCby.s
So that works. Note the path prepended to the cc1.exe. Which seems a reasonable place for it to be.
I have tried to set up emacs-w32 to have the same paths. Echoing the $PATH in the terminal and the output from M-x shell-command "echo $PATH" in emacs gives the same result. As far as I can tell it has a working path, all commands that I try, including 'ls', 'make' as well as some local ones, work as expected, even inside a Makefile. Except for the i686-w64-mingw-gcc, which does this:
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
Target: i686-w64-mingw32
Configured with: /cygdrive/i/szsz/tmpp/32gcc/mingw64-i686-gcc-4.8.2-1/src/gcc-4.8.2/configure --srcdir=/cygdrive/i/szsz/tmpp/32gcc/mingw64-i686-gcc-4.8.2-1/src/gcc-4.8.2 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share --docdir=/usr/share/doc/mingw64-i686-gcc --htmldir=/usr/share/doc/mingw64-i686-gcc/html -C --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-w64-mingw32 --without-libiconv-prefix --without-libintl-prefix --with-sysroot=/usr/i686-w64-mingw32/sys-root --with-build-sysroot=/usr/i686-w64-mingw32/sys-root --disable-multilib --disable-win32-registry --enable-languages=c,ada,c++,fortran,objc,obj-c++ --enable-fully-dynamic-string --enable-libgomp --enable-sjlj-exceptions --enable-version-specific-runtime-libs --with-dwarf2 --enable-decimal-float=bid --enable-lto
Thread model: win32
gcc version 4.8.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=pentiumpro'
cc1 -quiet -v -iprefix /bin/../lib/gcc/i686-w64-mingw32/4.8.2/ -U_REENTRANT exp.c -quiet -dumpbase exp.c -mtune=generic -march=pentiumpro -auxbase exp -version -o /cygdrive/c/Users/Thomas/AppData/Local/Temp/ccC472Qu.s
i686-w64-mingw32-gcc: error: spawn: No such file or directory
So the only difference is that this time the gcc-wrapper doesn't put a path before the cc1, presumably because it fails to find it in some path that it expects it to be.
But it also doesn't print any COLLECT_LTO_WRAPPER, whatever that means...
This happens inside a makefile and in a M-x shell-command. It does not happen in an interactive shell like M-x shell. So it smells like a interactive/non-interactive issue.
But since the paths are identical, I am at a loss. Anyone with any ideas?
Primary suspect at this point: COLLECT_LTO_WRAPPER, why doesn't the non-interactive version print that?

Resources