[Bug fortran/114235] New: Object undefined is specific procedure for generic overload in abstract type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114235 Bug ID: 114235 Summary: Object undefined is specific procedure for generic overload in abstract type Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 57613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57613&action=edit test case for overloaded addition in an abstract type The attached program fails with a segmentation fault. Compilation with gfortran-13 -g -fbacktrace -Wall -Wextra abstract_overload_01_pos.f90 yields and executable the execution of which produces the following stack trace: Backtrace for this error: #0 0x7faaea5408c0 in ??? #1 0x7faaea53fa75 in ??? #2 0x7faae9b8f03f in ??? #3 0x7faaeae012a3 in __mod_r_MOD_add_r at /home/reinhold/a2832ba/Documents/fortran_tests/f03/object_oriented/generic_tbps/abstract_overload_01_pos.f90:38 #4 0x7faaeae01dc3 in p_t at /home/reinhold/a2832ba/Documents/fortran_tests/f03/object_oriented/generic_tbps/abstract_overload_01_pos.f90:57 #5 0x7faaeae021ca in main at /home/reinhold/a2832ba/Documents/fortran_tests/f03/object_oriented/generic_tbps/abstract_overload_01_pos.f90:44 Segmentation fault (core dumped) Uncommenting the debug writeout in line 37 reveals that t2%vec is not allocated contrary to the fact that the actual argument's component is indeed allocated prior to invocation of the generic addition.
[Bug fortran/114188] Overloading assignment does not invalidate intrinsic assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114188 --- Comment #2 from Bader at lrz dot de --- You note that > Unfortunately, the five requirements in 10.2.1.4 for defined assignment > do not say anything about argument association. Hmm, one could see this as "intentionally" instead of "unfortunately": If the requirements in 10.2.1.4 are fulfilled, then a defined assignment exists. The consequences are: (1) the intrinsic assignment becomes unavailable (because the last sentence in 10.2.1.1 establishes a mutual exclusion). (2) Any further details on how the subroutine is set up must be appropriately handled by the programmer (e.g., supplying POINTER objects in my example's LHS) - this is what is meant by "The interpretation of a defined assignment is provided by the subroutine that defines it". The NOTE appearing later to me does not seem germane to the question at hand. While my starting assumption may be wrong, the other compilers' behaviour is consistent with it. Cheers Reinhold
[Bug fortran/114188] New: Overloading assignment does not invalidate intrinsic assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114188 Bug ID: 114188 Summary: Overloading assignment does not invalidate intrinsic assignment Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 57583 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57583&action=edit test case for invalid use of assignment overloading The attached reproducer overloads the assignment operator with a version that requires the left hand side to be a pointer. The overload conforms to the requirements for defining the assignment according to 10.2.1.4 of the Fortran standard. Therefore, the intrinsic assignment should become unavailable (last sentence of 10.2.1.1). However, gfortran accepts invocations that use nonpointer arguments. (NAG Fortran, Intel Fortran and NVidia Fortran issue appropriate error messages).
[Bug fortran/97210] New: Intrinsic function get_team() does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97210 Bug ID: 97210 Summary: Intrinsic function get_team() does not work Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 49273 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49273&action=edit Test case The attached test program fails with the following error message: eams_02_pos.f90:8:9: 8 | init = get_team() | 1 Error: Cannot convert INTEGER(4) to TYPE(team_type) at (1) teams_02_pos.f90:16:19: 16 | if (this_image(init) == me) then | 1 Error: Expected coarray variable as ‘coarray’ argument to the this_image intrinsic at (1) Error: comand: `/opt/gcc/10.2/bin/gfortran -I/opt/gcc/10.2/coarrays_mpich/include/OpenCoarrays-2.9.0_GNU-10.2.0 -fcoarray=lib -Wl,-rpath -Wl,/opt/mpich/3.3.2_gcc10/lib -Wl,--enable-new-dtags teams_02_pos.f90 /opt/gcc/10.2/coarrays_mpich/lib/libcaf_mpi.a /opt/mpich/3.3.2_gcc10/lib/libmpifort.so /opt/mpich/3.3.2_gcc10/lib/libmpi.so` failed to compile. So, apart from missing or incorrectly implemented support for get_team also the TEAM argument for this_image() is not accepted.
[Bug fortran/90093] New: Extended C interop: optional argument incorrectly identified as PRESENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90093 Bug ID: 90093 Summary: Extended C interop: optional argument incorrectly identified as PRESENT Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 46166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46166&action=edit UNIX archive with test case The attached test code can be compiled with gcc -c optional_02_pos.c gfortran optional_02_pos.f90 optional_02_pos.o and produces the output FAIL 2 T T T The cause of this is that the call of the procedure from C with NULL as first argument is incorrectly treated. This appears to be a regression of the most recent fixes for the C descriptor.
[Bug fortran/67744] [OOP] polymorphic associating entity is refused TBP invocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67744 --- Comment #5 from Bader at lrz dot de --- This is still not fixed in current trunk.
[Bug fortran/89846] New: CFI_select_part creates incorrect descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89846 Bug ID: 89846 Summary: CFI_select_part creates incorrect descriptor Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 46033 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46033&action=edit UNIX archive with test case Compiling the source files in the attached archive with gcc -c subobj_01_pos.c gfortran subobj_01_pos.f90 subobj_01_pos.o and executing the result reveals a buggy descriptor created by CFI_select_part: Particularly, the size of the resulting array is incorrect. Within C, the contiguity is incorrectly set.
[Bug fortran/89844] New: CFI_setpointer produces wrong descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89844 Bug ID: 89844 Summary: CFI_setpointer produces wrong descriptor Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 46032 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46032&action=edit UNIX archive with test case The source code in the attached archive can be compiled with gcc -c setpointer_01_pos.c gfortran setpointer_01_pos.f90 setpointer_01_pos.o Running the executable reveals that (1) referencing the assigned pointer does not supply the values for the assigned target (2) the association with the target is not set correctly (3) the supplied lower bound is not set correctly
[Bug fortran/89843] New: CFI_section delivers incorrect result descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89843 Bug ID: 89843 Summary: CFI_section delivers incorrect result descriptor Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 46031 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46031&action=edit UNIX archive with test case The source code in the attached archive can be compiled with gcc -c section_01_pos.c gfortran section_01_pos.f90 section_01_pos.o Running the executable reveals that CFI_section does not produce a correct descriptor. Both queries for contiguity and the size of the resulting array deliver incorrect values.
[Bug fortran/89842] New: CFI_allocate fails to allocate object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89842 Bug ID: 89842 Summary: CFI_allocate fails to allocate object Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 46030 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46030&action=edit UNIX archive with test case Please compile the test code from the attached archive as follows: gcc -g -c allocate_01_pos.c gfortran -g -ftraceback allocate_01_pos.f90 allocate_01_pos.o The resulting executable fails with symptoms of memory corruption that vary between runs. Not uncommonly, the following error message is printed: a.out: malloc.c:2399: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *(sizeof(size_t))) - 1)) & ~((2 *(sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x7f705b2bffdf in ??? #1 0x7f705b2bff67 in ??? #2 0x7f705b2c1339 in ??? #3 0x7f705b30419c in ??? #4 0x7f705b306076 in ??? #5 0x7f705b306a80 in ??? #6 0x7f705b308d93 in ??? #7 0x7f705bfb07dd in CFI_allocate at ../../../libgfortran/runtime/ISO_Fortran_binding.c:257 #8 0x400ed6 in globalp at /home/hpc/pr28fa/a2832ba/fortran_tests/f18/interop/functions/allocate_01_pos.c:14 #9 0x400a39 in alloc_01 at /home/hpc/pr28fa/a2832ba/fortran_tests/f18/interop/functions/allocate_01_pos.f90:21 #10 0x400e8e in main at /home/hpc/pr28fa/a2832ba/fortran_tests/f18/interop/functions/allocate_01_pos.f90:14 Aborted (core dumped)
[Bug fortran/89841] New: improper descriptor information passed to C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89841 Bug ID: 89841 Summary: improper descriptor information passed to C Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 46029 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46029&action=edit UNIX archive with test case The attached archive contains a Fortran main program and a C source file. It can be compiled with gcc -c assumed_shape_01_pos.c gfortran assumed_shape_01_pos.f90 assumed_shape_01_pos.o Running the resulting executable shows a failure to properly pass the descriptor information to C. Since the dummy arguments are declared assumed-shape, that->attribute should have the value CFI_attribute_other even if the actual argument is POINTER or ALLOCATABLE. Furthermore, the lower bounds are also not remapped as is required for a CFI_attribute_other descriptor.
[Bug fortran/89366] Fails to compile BIND(C) interface with assumed-length character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366 --- Comment #5 from Bader at lrz dot de --- No. The dummy argument of the procedure process_string is declared character(kind=c_char,len=*), intent(in) :: this there is no POINTER or ALLOCATABLE attribute there. Regards Reinhold
[Bug fortran/89366] Fails to compile BIND(C) interface with assumed-length character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366 --- Comment #3 from Bader at lrz dot de --- Created attachment 45771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45771&action=edit C code to be called Added the C side function call.
[Bug fortran/89366] Fails to compile BIND(C) interface with assumed-length character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366 --- Comment #2 from Bader at lrz dot de --- Fortran 2018 FDIS section 18.3.6, para 2, item 5, bullet 2: (5) any dummy argument without the VALUE attribute corresponds to a formal parameter of the prototype that is of a pointer type, and either • the dummy argument is interoperable with an entity of the referenced type (ISO/IEC 9899:2011, 6.2.5, 7.19, and 7.20.1) of the formal parameter, • the dummy argument is a nonallocatable nonpointer variable of type CHARACTER with assumed character length and the formal parameter is a pointer to CFI_cdesc_t, Note that as for all Fortran objects that don't have a C analog, interoperability is on the level of the procedure interface (not the object!), and the matching entity on the C side is the descriptor. Regards Reinhold
[Bug fortran/89365] Inquiry functions for assumed rank objects fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365 --- Comment #5 from Bader at lrz dot de --- The corrected test case passes all tests, so the PR can be closed. Sorry for the noise.
[Bug fortran/89365] Inquiry functions for assumed rank objects fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365 --- Comment #3 from Bader at lrz dot de --- I agree with Harald's assessment. The test case as delivered by me is indeed incorrectly written for the POINTER and ALLOCATABLE cases, in both of which I believe the bounds should be taken from the actual argument (versus remapping them). This has historical reasons (ifort has the POINTER and ALLOCATABLE case wrong), and the F2018 drafts did pick up some additional words in the last phase of corrections (see 8.5.8.7 para 1: "The bounds and shape of an assumed-rank entity with the ALLOCATABLE or POINTER attribute are determined as specified in 8.5.8.4." Regards Reinhold
[Bug fortran/89388] Component selection for assumed-size DT array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89388 --- Comment #1 from Bader at lrz dot de --- Actually, C1002 applies for expressions, which is not relevant for this case ... the only (non-constraint) restriction that one could (indirectly) argue to apply is 9.5.2 para2, inasmuch as the shape is needed to create the contiguous element sequence.
[Bug fortran/89388] New: Component selection for assumed-size DT array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89388 Bug ID: 89388 Summary: Component selection for assumed-size DT array Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45750 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45750&action=edit test code The attached test case, which is non-conforming (because it requires copy-in/out of an assumed-size object) compiles and creates an executable that crashes with a SIGSEGV. It would be good if a compile-time error could be created for this case. E.g. ifort says: The upper bound shall not be omitted in the last dimension of a reference to an assumed size array. nagfor says: dt_ass_neg_03.f90, line 10: Invalid appearance of assumed-size array name Y The Fortran 2018 constraint that applies is C1002 (10.1.2.2) Regards
[Bug fortran/89385] Incorrect members of C descriptor for an allocatable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89385 --- Comment #1 from Bader at lrz dot de --- Further comment: Analogous failures also happen for descriptors of assumed-shape or POINTER objects. I suggest that I re-test these when this bug is fixed and submit a separate report if still necessary. Regards Reinhold
[Bug fortran/89385] New: Incorrect members of C descriptor for an allocatable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89385 Bug ID: 89385 Summary: Incorrect members of C descriptor for an allocatable object Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45747&action=edit test code The attached test case provides a C and a Fortran file. If built with gcc -c alloc_01_pos.c gfortran alloc_01_pos.f90 alloc_01_pos.o the resulting executable prints failure messages with respect to many members of the C descriptor (elem_len, type, rank, attribute, dim[]). Regards
[Bug fortran/89384] New: CONTIGUOUS dummy argument in BIND(C) interface incorrect when actual is non-contiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89384 Bug ID: 89384 Summary: CONTIGUOUS dummy argument in BIND(C) interface incorrect when actual is non-contiguous Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45746&action=edit test code Fortran 2018 permits CONTIGUOUS dummy arguments also in BIND(C) interfaces. However, currently the passing of a compactified copy required for non-contiguous actual arguments does not work correctly in this context. A test case is attached. Note that the problem does not arise if BIND(C) is removed from the procedure definition.
[Bug fortran/89364] Assumed rank object with incorrect values for shape and bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89364 --- Comment #2 from Bader at lrz dot de --- (In reply to Dominique d'Humieres from comment #1) > Why do you want the shape to be [4,-1]? The Fortran 2018 standard explicitly prescribes this in 16.9.172, para 5. Regards Reinhold
[Bug fortran/89366] New: Fails to compile BIND(C) interface with assumed-length character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366 Bug ID: 89366 Summary: Fails to compile BIND(C) interface with assumed-length character argument Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45736 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45736&action=edit test code The extensions in C interop imply that an assumed-length character dummy argument can appear in a BIND(C) interface, and is mapped to a C descriptor. However, the attached test code fails to compile with the following error message: assumed_length_01_pos.f90:12:35: 12 | subroutine process_string(this, ierr) BIND(C) | 1 Error: Character argument ?this? at (1) must be length 1 because procedure ?process_string? is BIND(C)
[Bug fortran/89365] New: Inquiry functions for assumed rank objects fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365 Bug ID: 89365 Summary: Inquiry functions for assumed rank objects fail Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45735&action=edit test code The attached test code produces failures for the SHAPE, LBOUND and UBOUND intrinsics when applied to assumed-rank objects with the POINTER or ALLOCATABLE attribute. Note that for these cases the behaviour should be as for deferred-shape objects.
[Bug fortran/89364] New: Assumed rank object with incorrect values for shape and bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89364 Bug ID: 89364 Summary: Assumed rank object with incorrect values for shape and bounds Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45734 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45734&action=edit test code The attached code compiles without complaints with gfortran 9.0 trunk, but produces incorrect values for the SHAPE, LBOUND and UBOUND intrinsics on the last dimension if the actual argument is an assumed-size array.
[Bug fortran/89363] New: RANK incorrect for unallocated allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89363 Bug ID: 89363 Summary: RANK incorrect for unallocated allocatable Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 45732 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45732&action=edit test code The attached program compiles without complaints using gfortran 9.0 trunk build, but delivers an incorrect value for the RANK() intrinsic if the dummy is declared with assumed RANK and the ALLOCATABLE attribute, and the actual argument has the status "not allocated". Instead of "2", values are returned that change from run to run.
[Bug fortran/85507] [6/7/8/9 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85507 Bader at lrz dot de changed: What|Removed |Added CC||Bader at lrz dot de --- Comment #15 from Bader at lrz dot de --- *** Bug 85625 has been marked as a duplicate of this bug. ***
[Bug fortran/85625] Internal Compiler Error for coindexed assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85625 Bader at lrz dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Summary|Intenal Compiler Error for |Internal Compiler Error for |coindexed assignment|coindexed assignment --- Comment #1 from Bader at lrz dot de --- I just noted that 85507 deals with the same issue. Sorry for the duplicate. *** This bug has been marked as a duplicate of bug 85507 ***
[Bug fortran/85625] New: Intenal Compiler Error for coindexed assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85625 Bug ID: 85625 Summary: Intenal Compiler Error for coindexed assignment Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 44054 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44054&action=edit reproducer for described problem The attached Fortran file produces an ICE when built with gfortran -fcoarray=lib dummycoarray_04_pos.f90 The error message that is issued is: dummycoarray_04_pos.f90:11:0: x[i] = x internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2258 0x6f7d66 gfc_dep_resolver(gfc_ref*, gfc_ref*, gfc_reverse*) ../../gcc/fortran/dependency.c:2258 0x748bc5 conv_caf_send ../../gcc/fortran/trans-intrinsic.c:1863 0x74f085 gfc_conv_intrinsic_subroutine(gfc_code*) ../../gcc/fortran/trans-intrinsic.c:10981 0x701e52 trans_code ../../gcc/fortran/trans.c:1887 0x7653d3 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1433 0x76d78a gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1464 0x701db7 trans_code ../../gcc/fortran/trans.c:1916 0x72812b gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6507 0x7056d9 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.c: 0x6b8dab translate_all_program_units ../../gcc/fortran/parse.c:6108 0x6b8dab gfc_parse_file() ../../gcc/fortran/parse.c:6324 0x6ff14f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Replacing the RHS by an auxiliary variable that holds a copy of x does not trigger the error. However, since significant changes to existing codes may be required, I think this is a quite serious regression and should be fixed soon.
[Bug fortran/82550] New: program using submodules fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82550 Bug ID: 82550 Summary: program using submodules fails to link Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 42365 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42365&action=edit reproducer The attached example implements a separate module procedure returning a procedure pointer. gfortran 7,2 compiles the code, but issues the following error message at the linking stage: /gpfs/scratch/pr28fa/a2832ba/a2832ba/ccmqzru6.o: In function `__m_subm_18_pos_MOD_foo': subm_18_pos.f90:(.text+0x20): undefined reference to `p.3503' It seems that host association to the module procedure p() fails, because linking works if an external procedure is used.
[Bug fortran/79434] New: [submodules] separate module procedure breaks encapsulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79434 Bug ID: 79434 Summary: [submodules] separate module procedure breaks encapsulation Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 40698 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40698&action=edit test case The attached code (a much simplified version of a bug report on the Intel software forums) illustrate that the current submodule implementation does not respect type component encapsulation.
[Bug fortran/67744] polymorphic associating entity is refused TBP invocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67744 --- Comment #3 from Bader at lrz dot de --- The question on validity is not unjustified. The 2008 standard appears to be not fully clear on this, but the current 2015 draft has the following amended text in para 2 of section 8.1.3.3: --- The associating entity itself is a variable, but if the selector is not a definable variable, the associating entity is not definable and shall not be defined or become undefined. If the selector is not permitted to appear in a variable definition context (16.6.7), the associate name shall not appear in a variable definition context. --- The first sentence, I think, implies that my code example is valid. Cheers Reinhold
[Bug fortran/67744] polymorphic associating entity is refused TBP invocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67744 --- Comment #2 from Bader at lrz dot de --- The question on validity is not unjustified. The 2008 standard appears to be not fully clear on this, but the current 2015 draft has the following amended text in para 2 of section 8.1.3.3: --- The associating entity itself is a variable, but if the selector is not a definable variable, the associating entity is not definable and shall not be defined or become undefined. If the selector is not permitted to appear in a variable definition context (16.6.7), the associate name shall not appear in a variable definition context. --- The first sentence, I think, implies that my code example is valid. Cheers Reinhold
[Bug fortran/67744] New: polymorphic associating entity is refused TBP invocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67744 Bug ID: 67744 Summary: polymorphic associating entity is refused TBP invocation Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 36408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36408&action=edit Fortran free form source for test case The attached test case produces following spurious compile-time error: assoc_08_pos.f90:41:10: call g%write() 1 Error: VARIABLE attribute of 'g' conflicts with PROCEDURE attribute at (1) The error persists in more recent versions (trunk).
[Bug fortran/67743] New: Associating entity is not auto-typed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67743 Bug ID: 67743 Summary: Associating entity is not auto-typed Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 36407 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36407&action=edit Fortran free form source for test case The attached test case generates the following spurious error messages on compilation: assoc_04_pos.f90:28:10: if (g%geti() == 2) then 1 Error: Symbol 'g' at (1) has no IMPLICIT type assoc_04_pos.f90:30:8: else 1 Error: Unexpected ELSE statement at (1) assoc_04_pos.f90:32:7: end if 1 Error: Expecting END ASSOCIATE statement at (1) The error appears to persist in the trunk.
[Bug libfortran/57174] New: RTE triggered by type component allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57174 Bug #: 57174 Summary: RTE triggered by type component allocation Classification: Unclassified Product: gcc Version: fortran-dev Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ba...@lrz.de The following code, when compiled with the fortran-dev from 20130430, produces the error At line 18 of file PMRgf.f90 Fortran runtime error: Attempting to allocate already allocated variable '__tmp_type_t2' at execution time. module mod_noninter_array_01 implicit none type :: t1 integer, allocatable :: i(:) end type t1 type, extends(t1) :: t2 real, pointer :: p end type end module mod_noninter_array_01 program noninter_array_01 use mod_noninter_array_01 implicit none class(t1), allocatable :: n_t1(:,:) allocate(t2 :: n_t1(2,2)) select type(n_t1) type is (t2) allocate(n_t1(1,2)%i(2), source=[2,3]) end select end program noninter_array_01
[Bug fortran/57117] New: ICE for sourced allocation of a UP entity that uses the transpose intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57117 Bug #: 57117 Summary: ICE for sourced allocation of a UP entity that uses the transpose intrinsic Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ba...@lrz.de Created attachment 29977 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29977 module and main program as standalone source. The attached source code causes a segfault in gfortran at compile time: intrinsics_02_pos.f90:61:0: internal compiler error: Segmentation fault allocate(y(3,3), source=transpose(x)) 0x87e07f crash_signal ../../gcc-4.8.0/gcc/toplev.c:332 0x5ad22b gfc_conv_scalarized_array_ref ../../gcc-4.8.0/gcc/fortran/trans-array.c:3037 0x5adb89 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_symbol*, locus*) ../../gcc-4.8.0/gcc/fortran/trans-array.c:3172 0x5d0cdf gfc_conv_variable ../../gcc-4.8.0/gcc/fortran/trans-expr.c:1809 0x5cddaa gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc-4.8.0/gcc/fortran/trans-expr.c:6266 0x5e158c gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc-4.8.0/gcc/fortran/trans-intrinsic.c:6697 0x5cd832 gfc_conv_function_expr ../../gcc-4.8.0/gcc/fortran/trans-expr.c:5547 0x5cdd1a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc-4.8.0/gcc/fortran/trans-expr.c:6258 0x5d1d05 gfc_conv_expr_reference(gfc_se*, gfc_expr*) ../../gcc-4.8.0/gcc/fortran/trans-expr.c:6387 0x5f30be gfc_trans_allocate(gfc_code*) ../../gcc-4.8.0/gcc/fortran/trans-stmt.c:4911 0x5a7647 trans_code ../../gcc-4.8.0/gcc/fortran/trans.c:1577 0x5c4be2 gfc_generate_function_code(gfc_namespace*) ../../gcc-4.8.0/gcc/fortran/trans-decl.c:5397 0x568880 translate_all_program_units ../../gcc-4.8.0/gcc/fortran/parse.c:4468 0x568880 gfc_parse_file() ../../gcc-4.8.0/gcc/fortran/parse.c:4682 0x5a3c25 gfc_be_parse_file ../../gcc-4.8.0/gcc/fortran/f95-lang.c:189
[Bug fortran/57116] New: ICE for pointer assignment inside SELECT TYPE on UP entity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57116 Bug #: 57116 Summary: ICE for pointer assignment inside SELECT TYPE on UP entity Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ba...@lrz.de Created attachment 29976 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29976 module and main program as standalone source. The attached Fortran source produces the following error message with gfortran 4.8.0: rtti_pointerassign_02_pos.f90: In function `extract': rtti_pointerassign_02_pos.f90:13:0: internal compiler error: Segmentation fault extract => this(ic:) ^ 0x87e07f crash_signal ../../gcc-4.8.0/gcc/toplev.c:332 0x5d2db2 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) ../../gcc-4.8.0/gcc/fortran/trans-expr.c:6555 0x5a7896 trans_code ../../gcc-4.8.0/gcc/fortran/trans.c:1439 0x5f0e28 gfc_trans_block_construct(gfc_code*) ../../gcc-4.8.0/gcc/fortran/trans-stmt.c:1342 0x5a76b7 trans_code ../../gcc-4.8.0/gcc/fortran/trans.c:1527 0x5f25fd gfc_trans_integer_select ../../gcc-4.8.0/gcc/fortran/trans-stmt.c:1990 0x5f25fd gfc_trans_select(gfc_code*) ../../gcc-4.8.0/gcc/fortran/trans-stmt.c:2484 0x5a76c7 trans_code ../../gcc-4.8.0/gcc/fortran/trans.c:1543 0x5f0e28 gfc_trans_block_construct(gfc_code*) ../../gcc-4.8.0/gcc/fortran/trans-stmt.c:1342 0x5a76b7 trans_code ../../gcc-4.8.0/gcc/fortran/trans.c:1527 0x5c4be2 gfc_generate_function_code(gfc_namespace*) ../../gcc-4.8.0/gcc/fortran/trans-decl.c:5397 0x5a8091 gfc_generate_module_code(gfc_namespace*) ../../gcc-4.8.0/gcc/fortran/trans.c:1755 0x56862b translate_all_program_units ../../gcc-4.8.0/gcc/fortran/parse.c:4455 0x56862b gfc_parse_file() ../../gcc-4.8.0/gcc/fortran/parse.c:4682 0x5a3c25 gfc_be_parse_file ../../gcc-4.8.0/gcc/fortran/f95-lang.c:189
