[Bug fortran/86463] New: Slow compile with -ggdb and optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86463 Bug ID: 86463 Summary: Slow compile with -ggdb and optimizations Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: robert.j.farmer37 at gmail dot com Target Milestone: --- Created attachment 44377 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44377&action=edit Gzipped test case So the problem i have is that i have a large file with many variable assignments that takes a long time. Perhaps not unexpected as the file is large (~5000 variable assignments) but if the file is split into smaller chunks, then the performance shows a non-linear scaling with file size. Attached is a tarball that contains: largeFile.f90 the file to test, it includes one of the following files: all_vars.inc which does variable assignments for all 5000 variables top_vars.inc and bottom_vars.inc comment out half the variables from all_vars.inc (to test scaling behavior) and finally definitions.inc provides the variable types When compiling largeFile.f90 with both -ggdb and either -O1, -O2, -O3 and including all_vars.inc i get the following timings: time gfortran -ggdb -O0 -c largeFile.f90 0m0.376s time gfortran -ggdb -O1 -c largeFile.f90 >8m (Gave up) time gfortran -ggdb -O2 -c largeFile.f90 2m13.525s time gfortran -ggdb -O3 -c largeFile.f90 2m31.139s So -O1 shows very bad performance while -O2 and -O3 show ~2m to compile the file time gfortran -O0 -c largeFile.f90 0m0.326s time gfortran -O1 -c largeFile.f90 0m2.618s time gfortran -O2 -c largeFile.f90 0m4.276s time gfortran -O3 -c largeFile.f90 0m22.745s Shows its related to using the -ggdb flag If i include only the top_vars.inc (in largeFile.f90) i get 35s and just including bottom_vars.inc i get 11s (with -ggdb -O2) so that is a total of 46s for the combination of the split files while the whole file takes 2m13s (using all_vars.inc). So splitting the file into two chunks halves the total runtime. This is tested with gfortran 8.1.1 but 7.2.0 also shows the problem. While looking at other bugs, 59868 suggested -fno-var-tracking which does work here and brings the time down to ~1s with: gfortran -fno-var-tracking -ggdb -O2 -c largeFile.f90 gfortran -v -save-temps -ggdb -O2 -c largeFile.f90 Using built-in specs. COLLECT_GCC=/usr/bin/gfortran OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 8.1.1 20180502 (Red Hat 8.1.1-1) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-ggdb' '-O2' '-c' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/8/f951 largeFile.f90 -quiet -dumpbase largeFile.f90 -mtune=generic -march=x86-64 -auxbase largeFile -ggdb -O2 -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-redhat-linux/8/finclude -o largeFile.s GNU Fortran (GCC) version 8.1.1 20180502 (Red Hat 8.1.1-1) (x86_64-redhat-linux) compiled by GNU C version 8.1.1 20180502 (Red Hat 8.1.1-1), GMP version 6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 8.1.1 20180502 (Red Hat 8.1.1-1) (x86_64-redhat-linux) compiled by GNU C version 8.1.1 20180502 (Red Hat 8.1.1-1), GMP version 6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-ggdb' '-O2' '-c' '-mtune=generic' '-march=x86-64' as -v --64 -o largeFile.o largeFile.s GNU assembler version 2.29.1 (x86_64-redhat-linux) using BFD version version 2.29.1-23.fc28 COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/8/:/usr/libexec/gcc/x86_64-redhat-linux/8/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/8/:/usr/lib/gcc/x86_64-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/8/:/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib
[Bug debug/86463] Slow compile with -ggdb and optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86463 --- Comment #2 from Rob Farmer --- gfortran -ggdb -fno-var-tracking -c largeFile.f90 0m0.358s
[Bug debug/86463] Slow compile with -ggdb and optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86463 --- Comment #4 from Rob Farmer --- gfortran -ggdb -O1 -fno-var-tracking -c largeFile.f90 0m2.628s gfortran -ggdb -O2 -fno-var-tracking -c largeFile.f90 0m4.262s gfortran -ggdb -O3 -fno-var-tracking -c largeFile.f90 0m21.706s
[Bug libfortran/104939] New: Reading a file with / in leads to corrupt data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104939 Bug ID: 104939 Summary: Reading a file with / in leads to corrupt data Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: robert.j.farmer37 at gmail dot com Target Milestone: --- program test character(len=256) :: tmp,tmp2 integer :: iounit open(newunit=iounit,file='./test.txt') read(iounit,*) tmp,tmp2 write(*,*) len_trim(tmp),len_trim(tmp2) write(*,*) trim(tmp),trim(tmp2) end program Compiled with: gfortran -o test testRead.f90 With the contents on test.txt being: / a I get outputted: 256 256 p �:Qu`�1 ��5R�5R�1 ��5R� ��5R�0hQuf5Qu0hQu flipping the file to be a / leads to: 1 256 a1���ߗߗ��0��-6��-0��--y��- This was found as the file had a [fe/h] as a column name, but reducing down it seems its the / that is breaking the read. This lead to a somewhat puzzling error as in my full code tmp2 ended up with the contents of a entirely different file that gfortran decided to start reading in, mid-read statement. I found this on linux with 11.2.1 but also have a confirmed failure on a mac with 10.2 valgrind ./test ==145356== Memcheck, a memory error detector ==145356== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==145356== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==145356== Command: ./test ==145356== ==145356== Conditional jump or move depends on uninitialised value(s) ==145356==at 0x4AD05D9: string_len_trim (string_intrinsics_inc.c:231) ==145356==by 0x4AD05D9: _gfortran_string_len_trim (string_intrinsics_inc.c:186) ==145356==by 0x401359: MAIN__ (in /home/rob/src/test/test) ==145356==by 0x4014CA: main (in /home/rob/src/test/test) ==145356== ==145356== Conditional jump or move depends on uninitialised value(s) ==145356==at 0x4AD05F7: string_len_trim (string_intrinsics_inc.c:240) ==145356==by 0x4AD05F7: _gfortran_string_len_trim (string_intrinsics_inc.c:186) ==145356==by 0x401359: MAIN__ (in /home/rob/src/test/test) ==145356==by 0x4014CA: main (in /home/rob/src/test/test) ==145356== 1 256 ==145356== Conditional jump or move depends on uninitialised value(s) ==145356==at 0x4AD05D9: string_len_trim (string_intrinsics_inc.c:231) ==145356==by 0x4AD05D9: _gfortran_string_len_trim (string_intrinsics_inc.c:186) ==145356==by 0x4AD062B: _gfortran_string_trim (string_intrinsics_inc.c:168) ==145356==by 0x401449: MAIN__ (in /home/rob/src/test/test) ==145356==by 0x4014CA: main (in /home/rob/src/test/test) ==145356== ==145356== Conditional jump or move depends on uninitialised value(s) ==145356==at 0x4AD05F7: string_len_trim (string_intrinsics_inc.c:240) ==145356==by 0x4AD05F7: _gfortran_string_len_trim (string_intrinsics_inc.c:186) ==145356==by 0x4AD062B: _gfortran_string_trim (string_intrinsics_inc.c:168) ==145356==by 0x401449: MAIN__ (in /home/rob/src/test/test) ==145356==by 0x4014CA: main (in /home/rob/src/test/test) ==145356== ==145356== Syscall param write(buf) points to uninitialised byte(s) ==145356==at 0x4D61817: write (write.c:26) ==145356==by 0x4AC2386: raw_write (unix.c:368) ==145356==by 0x4ACA5C1: UnknownInlinedFun (unix.h:59) ==145356==by 0x4ACA5C1: _gfortrani_fbuf_flush (fbuf.c:150) ==145356==by 0x4ABD404: _gfortrani_next_record (transfer.c:4087) ==145356==by 0x4AC03F9: finalize_transfer (transfer.c:4228) ==145356==by 0x4AC08B1: _gfortrani_st_write_done_worker (transfer.c:4419) ==145356==by 0x401493: MAIN__ (in /home/rob/src/test/test) ==145356==by 0x4014CA: main (in /home/rob/src/test/test) ==145356== Address 0x4e71c62 is 2 bytes inside a block of size 512 alloc'd ==145356==at 0x484486F: malloc (vg_replace_malloc.c:381) ==145356==by 0x4894C58: _gfortrani_xmalloc (memory.c:38) ==145356==by 0x4ACA475: _gfortrani_fbuf_init (fbuf.c:42) ==145356==by 0x4AC17EB: _gfortrani_init_units (unit.c:674) ==145356==by 0x4893371: init (main.c:70) ==145356==by 0x400527D: call_init (dl-init.c:70) ==145356==by 0x400527D: call_init (dl-init.c:26) ==145356==by 0x400536B: _dl_init (dl-init.c:117) ==145356==by 0x401C6D9: ??? (in /usr/lib64/ld-linux-x86-64.so.2) ==145356==
[Bug libfortran/104939] Reading a file with / in leads to corrupt data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104939 Rob Farmer changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Rob Farmer --- I'm an idiot and this turns out to be a issue with the unformatted reads and /
