[Bug fortran/112828] Abort with malloc(): corrupted top size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828 --- Comment #5 from Rich Townsend --- One more data point: I tried with gfortran 13.2.0 on Linux/Intel and get the same result as for 13.1.0.
[Bug fortran/112828] Abort with malloc(): corrupted top size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828 --- Comment #4 from Rich Townsend --- Another data point for MacOS/Intel (10.13.6, High Sierra) -- with the character vars set to length 64, the crash is as follows: test(3287,0x7fff8fc11380) malloc: *** error for object 0x7fe44cc03b58: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x105c19a5e #1 0x105c18c1d #2 0x7fff57818f59 Abort trap: 6 Again, commenting out the allocate(..., STAT=stat) line makes the problem go away. Reducing the length to <=24 also resolves the problem.
[Bug fortran/112828] Abort with malloc(): corrupted top size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828 --- Comment #3 from Rich Townsend --- I can get the MWE to barf on MacOS/Arm (Sonoma 14.1.1), gfortran 13.1.0, by changing the length of the character vars in the main program from 64 to 16. The error is now: In file 'test.f90', around line 49: Error allocating 211106259502048 bytes: Cannot allocate memory Error termination. Backtrace: #0 0x102d77617 #1 0x102d781b7 #2 0x102d78457 #3 0x10275f5bb #4 0x10275fc37 #5 0x10275f84f #6 0x10275fc87 Once again, commenting out the allocate w/ STAT line makes the problem go away. It seems as though having two allocate invocations (one with stat, one without) is causing some kind of memory corruption.
[Bug fortran/112828] Abort with malloc(): corrupted top size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828 --- Comment #2 from Rich Townsend --- The problem manifests with gfortran 13.1.0 on Linux/x86_64. I've run into similar looking problems on MacOS/Arm, but the MWE I provided seems to work OK on Arm.
[Bug fortran/112828] New: Abort with malloc(): corrupted top size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828 Bug ID: 112828 Summary: Abort with malloc(): corrupted top size Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- Created attachment 56768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56768=edit MWE demonstrating problem When I compile the attached MWE with gfortran -o test test.f90 ...I get the following runtime error: malloc(): corrupted top size Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x7f13a2e7760f in ??? #1 0x7f13a2ec500c in ??? #2 0x7f13a2e77571 in raise #3 0x7f13a2e614b1 in abort #4 0x7f13a2e623b4 in ??? #5 0x7f13a2ece874 in ??? #6 0x7f13a2ed1fdf in ??? #7 0x7f13a2ed2b59 in __libc_malloc #8 0x40191a in MAIN__ #9 0x401c8c in main Aborted If I comment out the first allocate statement (the one with the STAT argument), then the program runs without problem (even though this statement isn't actually executed). There are a number of other things that make the bug go away; e.g., shrinking the length of the character variables in the main program to 20 or smaller. Setting the length to 21 still runs without error, but the second element of c_r ends up with some junk in it, viz: foo fooA cheers, Rich
[Bug fortran/110877] New: Incorrect copy of allocatable component in polymorphic assignment from array dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110877 Bug ID: 110877 Summary: Incorrect copy of allocatable component in polymorphic assignment from array dummy argument Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- I've run into a problem that's demonstrated by the following code: -- module avs_m type :: foo_t end type foo_t type, extends(foo_t) :: bar_t real, allocatable :: a end type bar_t end module avs_m program assign_vs_source use avs_m implicit none class(foo_t), allocatable :: foo(:) allocate(bar_t::foo(1)) select type(foo) class is (bar_t) allocate(foo(1)%a) end select call check_assign(foo) contains subroutine check_assign(f) class(foo_t), intent(in) :: f(:) class(foo_t), allocatable :: g(:) g = f select type(g) class is (bar_t) print *,'is allocated?', allocated(g(1)%a) end select deallocate(g) allocate(g, SOURCE=f) select type(g) class is (bar_t) print *,'is allocated?', allocated(g(1)%a) end select end subroutine check_assign end program assign_vs_source -- Expected output is is allocated? T is allocated? T but instead I get (gfortran 13.1.0, MacOS 13.4 x86_64): is allocated? F is allocated? T It seems that the polymorphic assignment g=f is not correctly allocating the %a component -- but the sourced allocation is. The problem seems to go away if (1) I use scalars for foo, f and g, or (2) if I move the code from the check_assign subroutine to the main program. cheers, Rich
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #9 from Rich Townsend --- OK, I managed to get things working by setting export LDFLAGS='-Wl,--no-eh-frame-hdr' prior to configuring. I'm hoping this won't affect the functionality of the built compiler.
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #7 from Rich Townsend --- (In reply to Andrew Pinski from comment #6) > GCC 13 won't build with anything older than GCC 4.8.x as documented at > https://gcc.gnu.org/install/prerequisites.html (which is right now for the > trunk but that requirement has not changed yet). The plot thickens -- I misidentified the compiler, here's the correct id: [user@0ec987449fdf gcc-build]$ x86_64-pc-linux-gnu-g++ -v Using built-in specs. COLLECT_GCC=x86_64-pc-linux-gnu-g++ COLLECT_LTO_WRAPPER=/opt/bootstrap/mesasdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/user/sdk2-tmp/build/gcc/configure CC= CXX= --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/home/user/sdk2-tmp/mesasdk --with-gmp=/home/user/sdk2-tmp/mesasdk --with-mpfr=/home/user/sdk2-tmp/mesasdk --with-mpc=/home/user/sdk2-tmp/mesasdk --enable-languages=c,c++,fortran --disable-multilib --disable-nls --disable-libsanitizer --enable-clocale=generic Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.1.0 (GCC) So, 12.1.0 should be perfectly capable of building 13.1, right?
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #5 from Rich Townsend --- (In reply to Andrew Pinski from comment #2) > What compiler did you start with? > That is what is the output of `x86_64-pc-linux-gnu-g++ -v` ? [user@60947d0cbd04 ~]$ x86_64-pc-linux-gnu-g++ -v bash: x86_64-pc-linux-gnu-g++: command not found [user@60947d0cbd04 ~]$ g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #4 from Rich Townsend --- Someone else seems to have the same problem: https://stackoverflow.com/questions/76375244/how-can-i-resolve-a-ld-eh-frame-hdr-refers-to-overlapping-fdes-error-during ...although there is no fix suggested.
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #1 from Rich Townsend --- I should add that this is on CentOS 5.11, running inside a Docker container. This ships with a very old binutils, so before trying to compile gcc I installed binutils 2.40 (built from source with --disable-gprofng).
[Bug bootstrap/110659] New: Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 Bug ID: 110659 Summary: Error from linker: .eh_frame_hdr refers to overlapping FDEs Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- I'm running into the following problem during a build of the 13.1.0 release: x86_64-pc-linux-gnu-g++ -std=c++11 -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o build/genenums \ build/genenums.o build/read-md.o build/errors.o ../build-x86_64-pc-linux-gnu/libiberty/libiberty.a /home/user/sdk2-tmp/mesasdk/bin/ld: .eh_frame_hdr refers to overlapping FDEs /home/user/sdk2-tmp/mesasdk/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status This is on Linux with binutils-2.40. Configure as follows: /home/user/sdk2-tmp/build/gcc/configure CC= CXX= --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/home/user/sdk2-tmp/mesasdk --with-gmp=/home/user/sdk2-tmp/mesasdk --with-mpfr=/home/user/sdk2-tmp/mesasdk --with-mpc=/home/user/sdk2-tmp/mesasdk --enable-languages=c,c++,fortran --disable-multilib --disable-nls --disable-libsanitizer --enable-clocale=generic Wondering whether any of these config flags are what's causing the problem...
[Bug bootstrap/110650] collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110650 --- Comment #3 from Rich Townsend --- Sure thing: GNU ld version 2.17.50.0.6-26.el5 20061020 I'm deliberately working with an old toolchain, inside a Docker container, to make sure that when I distribute the gcc executables they will work OK on older systems.
[Bug bootstrap/110650] collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110650 --- Comment #1 from Rich Townsend --- Oops, posted without any bug description! I'm trying to build gcc 13.1.0 on Linux x86_64, and I get the following segfault: libtool: compile: /home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc -shared-libgcc -B/home/user/sdk2-tmp/build/gcc-build/./gcc -nostdinc++ -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-checking -I/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/user/sdk2-tmp/build/gcc/libstdc++-v3/libsupc++ -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=compatibility-thread-c++0x.lo -g -O2 -D_GNU_SOURCE -std=gnu++11 -c /home/user/sdk2-tmp/build/gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc -o compatibility-thread-c++0x.o >/dev/null 2>&1 /bin/sh ../libtool --tag CXX --mode=link /home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc -shared-libgcc -B/home/user/sdk2-tmp/build/gcc-build/./gcc -nostdinc++ -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-checking -Wl,-O1 -Wl,-z,relro -Wl,--gc-sections -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:31:0 -Wl,--version-script=libstdc++-symbols.ver -lm -rpath /home/user/sdk2-tmp/mesasdk/lib/../lib64 compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo compatibility-atomic-c++0x.lo compatibility-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo compatibility-thread-c++0x.lo ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la ../src/c++17/libc++17convenience.la ../src/c++20/libc++20convenience.la libtool: link: /home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc -shared-libgcc -B/home/user/sdk2-tmp/build/gcc-build/./gcc -nostdinc++ -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-checking -fPIC -DPIC -D_GLIBCXX_SHARED -shared -nostdlib /usr/lib/../lib64/crti.o /home/user/sdk2-tmp/build/gcc-build/./gcc/crtbeginS.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o .libs/compatibility-thread-c++0x.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a ../src/c++17/.libs/libc++17convenience.a ../src/c++20/.libs/libc++20convenience.a -Wl,--no-whole-archive -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -lm -L/home/user/sdk2-tmp/build/gcc-build/./gcc -L/lib/../lib64 -L/usr/lib/../lib64 -lc -lgcc_s /home/user/sdk2-tmp/build/gcc-build/./gcc/crtendS.o /usr/lib/../lib64/crtn.o -Wl,-O1 -Wl,-z -Wl,relro -Wl,--gc-sections -Wl,--version-script=libstdc++-symbols.ver -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.31 collect2: fatal error: ld terminated with signal 11 [Segmentation fault] compilation terminated. make[6]: *** [libstdc++.la] Error 1 make[6]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3' make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[2]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build' make: *** [all] Error 2 FAILED in make for gcc Action install failed for package gcc/gcc-13.1.0
[Bug bootstrap/110650] New: collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110650 Bug ID: 110650 Summary: collect2: fatal error: ld terminated with signal 11 [Segmentation fault] Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: ---
[Bug fortran/110629] Bug in assignment of derived type with deferred length character component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110629 --- Comment #3 from Rich Townsend --- Thanks for the quick responses, folks. The problem persists in 12.3.0 release, but is fixed in 13.1.0 release.
[Bug fortran/110629] New: Bug in assignment of derived type with deferred length character component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110629 Bug ID: 110629 Summary: Bug in assignment of derived type with deferred length character component Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- I've run into a problem with intrinsic assignment of derived types with allocatable character components. This seems to be a resurgence of PR105205, in that only the first element of the character array is copied correctly; the rest is filled with garbage. Here's a demo: -- module m type :: bar_t character(:), allocatable :: c(:) end type bar_t end module m program p use m implicit none type(bar_t) :: bar type(bar_t) :: biz integer :: i allocate(character(10)::bar%c(3)) bar%c(1) = 'big' bar%c(2) = 'red' bar%c(3) = 'dog' biz = bar do i = 1, 3 print *, i, '|'//biz%c(i)//'|' end do end program p -- Output compiling with gfortran 12.2.0 on MacOS 13.4: 1 |big | 2 |>| 3 || Unfortunately, this may be a heisenbug -- some code where I do this kind of assignment is affected, other code is not.
[Bug fortran/105205] New: Incorrect assignment of derived type with allocatable, deferred-length character component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105205 Bug ID: 105205 Summary: Incorrect assignment of derived type with allocatable, deferred-length character component Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- I've run into problems with assignment of derived types containing an allocatable array of deferred-length strings. Example program: --- program alloc_char_type implicit none type mytype character(:), allocatable :: c(:) end type mytype type(mytype) :: a type(mytype) :: b integer :: i a%c = ['foo','bar','biz','buz'] b = a do i = 1, size(b%c) print *,b%c(i) end do end --- Running with gfortran 10.2.0 or 11.2.0, I get the output: >> foo << If I hard-code the length of the c component (to, say, 3), I get the expected output: >> foo bar biz buz << It seems as if only the first element of c is being copied correctly. cheers, Rich
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 Rich Townsend changed: What|Removed |Added CC||townsend at astro dot wisc.edu --- Comment #11 from Rich Townsend --- I can confirm this issue on macOS 12.0.1 and gcc/gfortran 10.2.
[Bug fortran/99477] New: CONTIGUOUS assumed-shape dummy not working with associate construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99477 Bug ID: 99477 Summary: CONTIGUOUS assumed-shape dummy not working with associate construct Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- Created attachment 50335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50335=edit Example program I think I've stumbled on a bug with gfortran's handling of the CONTIGUOUS attribute in assumed-shape dummy arguments, when the actual argument is an array slice set up using an ASSOCIATE construct. The example program demonstrates the issue. When compiled with gfortran 10.2.0, I get the following output: 1 3 5 7 9 1 3 5 7 9 1 2 3 4 5 1 3 5 7 9 (note the third line, which has only stride 1). Whereas, I believe the output should be 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 The issue goes away if I remove the CONTIGUOUS attribute from the function argument. cheers, Rich
[Bug fortran/99169] New: Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169 Bug ID: 99169 Summary: Segfault when passing allocatable scalar into intent(out) dummy argument Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- Created attachment 50222 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50222=edit Minimal working example I've encountered a problem when passing an allocatable (and alread allocated) scalar as an actual argument to a procedure with an intent(out) (but not allocatable) dummy argument. The attached code illustrates the problem. Compiling with gfortran 10.2.0 at optimization level -O1 or -O2 leads to a segmentation fault at runtime. The segfault arises when the dummy is assigned within set_i(). This problem does not arise at optimization level -O0, and the program performs as expected (outputting '5' to the terminal). The problem also seems to disappear when set_i() is a CONTAINed procedure in the main program, rather than a module procedure. cheers, Rich
[Bug fortran/98445] Bogus error: derived type used as an actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445 --- Comment #3 from Rich Townsend --- OK, my code isn't valid -- it's not permitted to pass a generic procedure name as an actual argument. As such, gfortran is correct in its behavior. Happy for this one to be closed -- sorry for the false alarm!
[Bug fortran/98445] Bogus error: derived type used as an actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445 --- Comment #2 from Rich Townsend --- I know it's acceptable to overload a type name with one or more functions -- from 12.4.3.4.1 of the F2008 standard, "A generic name may be the same as a derived-type name, in which case all of the procedures in the interface block shall be functions." In reading the rules for actual and dummy arguments (12.5.2), I don't see anything prohibiting a function-overloaded type name being passed in. However, I'm going to hit up comp.lang.fortran to see if I can get advice from one of the Fortran congnescenti.
[Bug fortran/98445] New: Bogus error: derived type used as an actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445 Bug ID: 98445 Summary: Bogus error: derived type used as an actual argument Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- Created attachment 49844 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49844=edit Minimal working example I'm running into what I believe to be a bogus error, when passing a function that (via interface overloading) has the same name as a derived type. Attached is a MWE. When compiled, I get the error passed_procedure_bug.f90:30:11: 30 | call s(t) | 1 Error: Derived type 't' is used as an actual argument at (1) cheers, Rich
