[Bug fortran/115997] Findloc does not find the result of a function with a deferred-length character return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115997 --- Comment #2 from martin --- Thanks for checking and looking up. I have not been able to use gfortran-14 due to bug 114874 (a regression which has been resolved after release). Strangely, the search box of bugzilla does not show relevant findloc issues, so I missed bug 110288.
[Bug fortran/115997] New: Findloc does not find the result of a function with a deferred-length character return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115997 Bug ID: 115997 Summary: Findloc does not find the result of a function with a deferred-length character return value Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 58705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58705&action=edit testcase Invoking findloc with an array of character values and a search value obtained by a function call (which returns a deferred-length character value) always yields 0, even if the value is present in the array.
[Bug fortran/113797] Deferred length character concatenation in openmp region has wrong length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
--- Comment #3 from martin ---
Thanks for the patch, it does the job. But if I compile with
"gfortran-14 -fopenmp -Wuninitialized"
then I obtain
20 | out = concat_f('0123456 ', some()) // ' abc'
| ^
note: ‘slen.1’ declared here
So there still seems to be something amiss.
Here is the tree dump of the initial part of check(), where slen.1 is declared.
The problem might be the declaration of pstr.2?
__attribute__((fn spec (". r ")))
void check (integer(kind=4) & restrict i)
{
character(kind=1) out[1:15];
{
struct string D.4330;
struct string * D.4331;
integer(kind=8) slen.1;
character(kind=1)[1:slen.1] * pstr.2;
character(kind=1)[1:] * pstr.3;
void * restrict D.4336;
integer(kind=8) D.4337;
integer(kind=8) D.4338;
void * D.4339;
void * D.4340;
D.4330 = some ();
D.4331 = &D.4330;
typedef character(kind=1) struct character(kind=1)[1:slen.1][1:slen.1];
pstr.2 = 0B;
slen.1 = 0;
concat_f (&pstr.2, &slen.1, &"0123456 "[1]{lb: 1 sz: 1}, D.4331, 8);
if (D.4331->chars != 0B)
{
__builtin_free ((void *) D.4331->chars);
D.4331->chars = 0B;
}
D.4336 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
(slen.1 + 4), 1>);
pstr.3 = (character(kind=1)[1:] *) D.4336;
_gfortran_concat_string (slen.1 + 4, pstr.3, slen.1, pstr.2, 4, &"
abc"[1]{lb: 1 sz: 1});
__builtin_free ((void *) pstr.2);
D.4337 = slen.1 + 4;
D.4338 = slen.1 + 4;
D.4339 = (void *) &out;
D.4340 = (void *) pstr.3;
if (NON_LVALUE_EXPR <= 14)
{
__builtin_memmove (D.4339, D.4340, (unsigned long) NON_LVALUE_EXPR
);
__builtin_memset (D.4339 + (sizetype) NON_LVALUE_EXPR , 32,
(unsigned long) (15 - NON_LVALUE_EXPR ));
}
else
{
__builtin_memmove (D.4339, D.4340, 15);
}
__builtin_free ((void *) pstr.3);
}
...
[Bug fortran/113797] New: Deferred length character concatenation in openmp region has wrong length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797 Bug ID: 113797 Summary: Deferred length character concatenation in openmp region has wrong length Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 57349 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57349&action=edit concat.f90 The code compiled with -fopenmp and run with at least 2 threads fails. Usually "out" contains the expected string, but occasionally "out" is just "abc ", the leading concat_f(..) part is missing. I have added the "// 'abc'" part to make this more visible. Without this additional concatenation "out" would be empty. Looks like the length of the concat_f result is wrong sometimes. I do not see any errors with valgrind/helgrind or sanitizers. The problem is already present in gfortran-13. There are some related bugs, like bug 97977. But here all the involved variables are local variables in subroutines or functions and thus on thread private stack. So this feels different.
[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112764 --- Comment #10 from martin --- Thanks for the speedy fix! I just thought about a variation, which should now with the fix work as well (was not yet able to compile current dev branch, so cannot check myself): program assoc_ptr_in implicit none integer, dimension(:,:), pointer :: x integer, pointer :: j allocate(x(1:100,1:2), source=123) associate(i1 => x(:,1)) call sub(i1) end associate deallocate(x) contains subroutine sub(j) integer, dimension(:), pointer, intent(in) :: j print *,j(1) end subroutine sub end program assoc_ptr_in
[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112764 --- Comment #4 from martin --- (In reply to anlauf from comment #1) > Confirmed. > > F2018:11.1.3.3 has: > > "The associating entity does not have the ALLOCATABLE or POINTER attributes; > it has the TARGET attribute if and only if the selector is a variable and has > either the TARGET or POINTER attribute." I was not sure, whether this formulation also covers array sections. Anyway, thanks for the fast reply!
[Bug fortran/112764] New: Associating entity does not have target attribute if selector has pointer attribute in associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112764 Bug ID: 112764 Summary: Associating entity does not have target attribute if selector has pointer attribute in associate block Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- The selector has the pointer attribute but association is with an array section. The associating entity should have the target attribute even in this case, right? gfortran complains with "Pointer assignment target is neither TARGET nor POINTER", ifort and ifx accept it. Looks like a bug in gfortran, or has i1 indeed no target attribute? program assoc_target implicit none integer, dimension(:,:), pointer :: x integer, pointer :: j allocate(x(1:100,1:2), source=0) associate(i1 => x(:,1)) j => i1(1) print *, j end associate deallocate(x) end program assoc_target
[Bug fortran/110623] New: Segfault if type-bound procedure function provided for an assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110623 Bug ID: 110623 Summary: Segfault if type-bound procedure function provided for an assumed rank class(*) argument Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 55519 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55519&action=edit testcase The attached code aborts with a segfault (or some undefined behaviour) in the line "call p(y%get())". For "call p(x%get())" with x declared as type(t) instead of class(t), everything seems fine. This is a variation to bug 100961. I have checked with 13.1 and 14.0 (current master). valgrind shows "conditional jump depends on uninitialised value" and "invalid read" before it aborts.
[Bug fortran/105800] Segfault deallocating a class, dimension(:) array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105800 --- Comment #1 from martin --- Created attachment 54856 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54856&action=edit fixed testcase class_dealloc.f90 As I just see, the first attachment does not show the bug as return value "a" of function create is declared as "class(t), dimension(:), pointer". And as described in the initial report, with class instead of type, there is no error. The fixed attachment declares "a" as "type(t), dimension(:), pointer". This shows the described error. It is still present in the current 13 development branch.
[Bug fortran/106557] New: nesting intrinsics ibset and transfer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106557 Bug ID: 106557 Summary: nesting intrinsics ibset and transfer gives wrong result Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 53425 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53425&action=edit ibset_transfer.f90 Nesting ibset and transfer gives a wrong result. In the attached program the value in variable k is wrong. With an additional int(..,8), which should do nothing as it is already integer(8), the correct value will be computed. (Note that the code assumes that 0.0_8 is represented by the same bit pattern as 0_8.)
[Bug fortran/105800] New: Segfault deallocating a class, dimension(:) array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105800 Bug ID: 105800 Summary: Segfault deallocating a class, dimension(:) array Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 53062 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53062&action=edit test class_dealloc.f90 Creating an array in a function with return value "type(t), dimension(:)", and assigning it to a "class(t), dimension(:)" variable eventually leads to a segfault when deallocating the array. See attached test. valgrind shows invalid read due to uninitialised value (presumably the type-descriptor of the "class(t), dimension(:)" variable is not completely initialised). If the "type(t)" is changed to "class(t)" in the create function, then it works fine, without any complains from valgrind.
[Bug fortran/105543] New: Function returning a class array with contiguous attribute rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105543 Bug ID: 105543 Summary: Function returning a class array with contiguous attribute rejected Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 52947 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52947&action=edit func_contiguous.f90 The attached code, compiled with "gfortran func_contiguous.f90 -c", fails with the error message func_contiguous.f90:8:0: 8 | function create() result(x) | Error: ‘create’ at (1) has the CONTIGUOUS attribute but is not an array pointer or an assumed-shape or assumed-rank array.
[Bug fortran/105503] vptr and data are uninitialised error for intent(out) argument of abstract type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105503 --- Comment #1 from martin --- Created attachment 52934 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52934&action=edit reduced uninit_vptr Testcase further reduced.
[Bug fortran/105503] New: vptr and data are uninitialised error for intent(out) argument of abstract type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105503 Bug ID: 105503 Summary: vptr and data are uninitialised error for intent(out) argument of abstract type Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 52932 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52932&action=edit uninit_vptr The attached module, compiled with gfortran-12 -Wall uninit_vptr.f90 -c gives uninit_vptr.f90:34:19: 34 | call f%sub(x) | ^ Warning: ‘x._data’ is used uninitialized [-Wuninitialized] uninit_vptr.f90:33:42: 33 | class(a), dimension(:), pointer :: x | ^ note: ‘x’ declared here uninit_vptr.f90:34:19: 34 | call f%sub(x) | ^ Warning: ‘x._vptr’ is used uninitialized [-Wuninitialized] uninit_vptr.f90:33:42: 33 | class(a), dimension(:), pointer :: x | ^ note: ‘x’ declared here But argument x has the intent(out) attribute and the warning seems bogus. (The original code, where this occured, is an implementation of the abstract factory design pattern.)
[Bug fortran/105054] Using one kind of pointer functions causes the compiler to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105054 martin changed: What|Removed |Added CC||mscfd at gmx dot net --- Comment #1 from martin --- Confirmed with the current development branch for gfortran-12. Moreover, if I comment out the program beginning from line pointer_to_string(2) = '12345678901234567890' to the end, (hence "pointer_to_string(1) = '1234567890'" is the last uncommented line), then I get an ICE: during RTL pass: expand pointer_to_string.f90:20:26: 20 | program chk_string_pointer | ^ internal compiler error: in expand_expr_real_1, at expr.cc:10585 0x68336a expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.cc:10585 0x908991 expand_normal ../../gcc/expr.h:307 0x908991 do_compare_and_jump ../../gcc/dojump.cc:1253 0x90999a do_jump_1 ../../gcc/dojump.cc:253 0x89f6c1 expand_gimple_cond ../../gcc/cfgexpand.cc:2645 0x89f6c1 expand_gimple_basic_block ../../gcc/cfgexpand.cc:5933 0x8a0536 execute ../../gcc/cfgexpand.cc:6806
[Bug fortran/103039] [12 Regression] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 --- Comment #12 from martin --- Thanks for fixing! I just checked with the real code and there it also looks good.
[Bug fortran/100961] Intrinsic function as value to a class(*) assumed rank argument fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100961 --- Comment #4 from martin --- In contrast to gfortran-11, with current master I do not see any errors or segfaults (not even with valgrind) anymore. Seems to have been fixed.
[Bug fortran/87448] ICE at trans-expr:3417 in allocate statement with type signature using an associated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448 --- Comment #3 from martin --- With gfortran-12, the ICE is gone, but the produced error message does not look right. mod.f90:12:25: 12 |associate(l => len(cs)) | 1 Error: Symbol ‘l’ at (1) has no IMPLICIT type
[Bug fortran/103039] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 --- Comment #4 from martin --- Is there any chance of fixing this regression (in particular the associate block variant) till gfortran-12 release? Having an openmp block within an associate block should not be that uncommon in modern code, right?
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 --- Comment #8 from martin --- Seems to work fine with current master. Not even valgrind complains.
[Bug fortran/103039] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 --- Comment #3 from martin --- Created attachment 51722 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51722&action=edit seemingly same problem but with associate instead of select type A similar problem with associate shows the same problem and probably has the seem root cause. It is slightly more complicated than the variant with select type, as it requires a class(..) component provided in the target of the associate statement. Otherwise warnings and subsequent segfault are similar.
[Bug fortran/103039] Segfault with openmp block within a select type block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 --- Comment #1 from martin --- The warning which is shown during compilation is: seltype.f90:16:59: 16 | !$omp parallel do default(shared) private(k) reduction(+:s) | ^ Warning: ‘__tmp_class_a’ is used uninitialized [-Wuninitialized] seltype.f90:15:12: 15 | class is (a) |^ note: ‘__tmp_class_a’ declared here
[Bug fortran/103039] New: Segfault with openmp block within a select type block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 Bug ID: 103039 Summary: Segfault with openmp block within a select type block Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 51720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51720&action=edit seltype.f90 The attached code compiles and executes fine with gfortran-11.1, but it first shows warnings during compilation and then fails with a segfault with the current master branch. Compilation is done with: gfortran-12 -fopenmp -Wall seltype.f90 Output should be just the number 110. In our code I have also seen lots of similar warnings with openmp blocks within associate(.. => ...) blocks and related segfaults, but I could not come up with a simple testcase.
[Bug fortran/100961] Intrinsic function as value to a class(*) assumed rank argument fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100961 --- Comment #3 from martin --- Created attachment 50968 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50968&action=edit second test case which segfaults Playing around with some variants in select_rank_expression2.f90, I can see that I sometimes get correct results, sometimes the rank is correctly recognised, but not the type, and (as is the case for attachment select_rank_expression2.f90) it even can segfault with an invalid memory access. I get all these behaviours by selecting different sets of the four "call p(..)" lines and varying the order in which they are executed.
[Bug fortran/100961] Intrinsic function as value to a class(*) assumed rank argument fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100961 --- Comment #2 from martin --- It is releases/gcc-11.1.0: Using built-in specs. COLLECT_GCC=gfortran-11 COLLECT_LTO_WRAPPER=.../gcc/lib/gcc/x86_64-linux-gnu/11.1.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../gcc-repo/configure --program-suffix=-11 --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-arch=westmere --prefix=.../gcc --enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap --enable-checking=release Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.1.0 (GCC) The code is compiled with "-g select_rank_expression.f90 -o select_rank_expression.x".
[Bug fortran/100961] New: Intrinsic function as value to a class(*) assumed rank argument fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100961 Bug ID: 100961 Summary: Intrinsic function as value to a class(*) assumed rank argument fails Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 50961 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50961&action=edit test case Providing the value of an intrinsic function to a subroutine with an class(*) assumed rank argument fails. The correct rank is not recognised. Encapsulating the intrinsic function invocation in parenthesis avoids the bug.
[Bug fortran/99529] libgfortran I/O: Data races related to new unit / new unit calls for I/O to strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529 --- Comment #4 from martin --- Ok, here is another suspicious data race in unit.c (backtrace from helgrind): ==7831== Possible data race during read of size 4 at 0x5DE4620 by thread #296 ==7831== Locks held: 1, at address 0x2EE5D00 ==7831==at 0x10067CB: get_gfc_unit (unit.c:336) ==7831==by 0x10071DB: _gfortrani_get_unit (unit.c:556) ==7831==by 0x10050DC: data_transfer_init (transfer.c:2851) ... ==7831== ==7831== This conflicts with a previous write of size 4 by thread #3 ==7831== Locks held: 1, at address 0x5DE4700 ==7831==at 0x10069F4: _gfortrani_set_internal_unit (unit.c:459) ==7831==by 0x10071EC: _gfortrani_get_unit (unit.c:557) ==7831==by 0x10050DC: data_transfer_init (transfer.c:2851) There seems to be a conflicting access to "unit_cache[c]->unit_number", set_internal_unit does not hold UNIT_LOCK. I cannot observe this in the simple testcase, but in the real code at the right place where I suspect the write-caused memory corruption. (Just in case line numbers have changed: unit.c:336: if (unit_cache[c] != NULL && unit_cache[c]->unit_number == n) unit.c:556: iunit->unit_number = dtp->common.unit; )
[Bug fortran/99529] libgfortran I/O: Data races related to new unit / new unit calls for I/O to strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529 --- Comment #3 from martin --- Thanks for looking at the report and providing a patch to test. For completeness sake, here is the simple test code, which does not fail, but which shows the data race in helgrind (compile with -fopenmp -g2): program omp_write_str use OMP_LIB implicit none integer :: i character(len=16) :: out !$omp parallel do schedule(static,10) default(shared) private(i, out) do i=1,10 write(out,'(i8)') omp_get_thread_num() end do !$omp end parallel do end program omp_write_str The provided patch indeed removes the data races (there are still data races at startup and exit, which are false positives, as those occur in a single threaded region.) However, with the my real code, it does not help. I will further check with helgrind (the amount of false positives is staggering, though...)
[Bug fortran/88735] Nested assignment triggers call of final method for right hand side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735 --- Comment #5 from martin --- Hi Ev, the testcase is actually derived from a smart pointer implementation (where i is the reference count, shared between all smart pointers [hence allocatable will not do], and incremented upon sharing). It would be nice to have the bug fixed, though I have seen too many (subtle) bugs with assignments by different compilers that I try not to use them. But thanks for providing a better and more thorough testcase.
[Bug fortran/93924] [OOP] segfault with function returning a CLASS(*) pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #7 from martin --- With a recent gfortran version I get (how did you compile that you can run the code): fun_select.f90:37:15: 37 | f => selector() | 1 internal compiler error: Segmentation fault 0xc1f3af crash_signal ../../gcc-repo/gcc/toplev.c:327 0x7842f2 gfc_class_vptr_get(tree_node*) ../../gcc-repo/gcc/fortran/trans-expr.c:205 0x797d7c trans_class_vptr_len_assignment ../../gcc-repo/gcc/fortran/trans-expr.c:9202 0x799afa trans_class_assignment ../../gcc-repo/gcc/fortran/trans-expr.c:10893 0x799afa gfc_trans_assignment_1 ../../gcc-repo/gcc/fortran/trans-expr.c:11326 0x757d77 trans_code ../../gcc-repo/gcc/fortran/trans.c:1919 0x781a99 gfc_generate_function_code(gfc_namespace*) ../../gcc-repo/gcc/fortran/trans-decl.c:6880 0x6fd80e translate_all_program_units ../../gcc-repo/gcc/fortran/parse.c:6351 0x6fd80e gfc_parse_file() ../../gcc-repo/gcc/fortran/parse.c:6620 0x75504f gfc_be_parse_file ../../gcc-repo/gcc/fortran/f95-lang.c:212 Please submit a full bug report,
[Bug fortran/93924] ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #4 from martin --- Created attachment 50053 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50053&action=edit reduced testcase
[Bug fortran/93918] Segfault with -Ofast when calling a routine with an array argument array(:)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918 --- Comment #6 from martin --- Sorry, wrong issue...
[Bug fortran/93918] Segfault with -Ofast when calling a routine with an array argument array(:)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918 --- Comment #5 from martin --- Created attachment 50052 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50052&action=edit reduced testcase
[Bug fortran/93924] ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #3 from martin --- The submitted testcase is invalid fortran, see bug 93925. However, with the same small fix it becomes valid and still fails. Sorry for the mistake. Instead of a fix, I have attached a much reduced testcase showing the same failure.
[Bug fortran/93925] Invalid memory reference upon call of a routine taking a procedure pointer as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 --- Comment #5 from martin --- Sorry for this invalid test case, obviously I did reduce too much. The three attached variations should hopefully all be conforming to the standard and still produce the same error. Please reopen if the testcases are ok now. The attached classStar_map2 is a slight variation on the original code, and just uses an "integer, pointer" variable for x (as is roughly the context where I originally encountered the bug). classStar_map3 has no target attribute but uses "class(*), pointer" for variable as well as argument x. classStar_map4 is a bit further reduced. It has no target nor pointer attribute for x, but does not use the value of x, just returns y=>null() and y=987456.
[Bug fortran/93925] Invalid memory reference upon call of a routine taking a procedure pointer as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 --- Comment #4 from martin --- Created attachment 50050 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50050&action=edit classStar_map4 without target nor pointer attributes for variable x
[Bug fortran/93925] Invalid memory reference upon call of a routine taking a procedure pointer as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 --- Comment #3 from martin --- Created attachment 50049 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50049&action=edit classStar_map3 with class(*), pointer for variable x
[Bug fortran/93925] Invalid memory reference upon call of a routine taking a procedure pointer as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 --- Comment #2 from martin --- Created attachment 50048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50048&action=edit classStar_map2 with pointer attribute for variable x
[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #3 from martin ---
Sorry for the noise, but as this gives big reductions in compilation time it is
quite important to me (and probably other big module based projects).
I just realised that I mixed up gfc_symtree->name and gfc_symtree->n.sym->name.
The reason why find_symbol traverses the whole tree in the worst case is that
it is ordered by gfc_symtree->name but it looks for gfc_symtree->n.sym->name.
So far I got the impression that either gfc_symtree->name is a unique name
("@xxx") or equal to gfc_symtree->n.sym->name (if n.sym!=NULL). In this case,
the following patch should do the trick and traverse only log(N) of the tree:
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 4c6ff22d5c1..8dc59e25d46 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -4659,10 +4659,20 @@ find_symbol (gfc_symtree *st, const char *name,
return st;
}
+ c = strcmp (name, st->name);
+ if (c < 0)
+retval = find_symbol (st->left, name, module, generic);
+ else if (c > 0)
+retval = find_symbol (st->right, name, module, generic);
+ else
+retval = NULL;
+
+/* original traverse
retval = find_symbol (st->left, name, module, generic);
if (retval == NULL)
retval = find_symbol (st->right, name, module, generic);
+*/
return retval;
}
[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 --- Comment #2 from martin --- I further tried to find out what the call to find_symbol (this is the call which consumed the compilation time) is achieving in read_modules(). Even with the accidentially wrong patch everything just seems to work (and I have lots of generic interfaces and submodules etc., for which there are checks in read_modules following the call to find_symbol). With some printf's I at least checked the the corrected patch definitely finds the symbols it is looking for. But I cannot come up with some testcase showing that find_symbol returns the expected result in read_modules().
[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 --- Comment #1 from martin --- Created attachment 49846 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49846&action=edit corrected patch Comparison with c was wrong.
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 martin changed: What|Removed |Added CC||mscfd at gmx dot net --- Comment #9 from martin --- Problems with default initialisation of function result were fixed with PR45489. The relevant testcase added by this PR is initialization_27.f90 which looks very similar to the reported problem (minus the non-initialised components). After playing around a little bit I think the reason why initialization_27.f90 does not fail in contrast to the reported case (with only unit=-1 as component so as to get valid fortran) is that it has a pointer component. Change t_test to something like type :: t_test integer :: unit = -1 integer, pointer :: p => null() end type and unit gets properly initialised. Without the pointer component I get bogus results.
[Bug fortran/98426] New: find_symbol in module.c traverses O(N) part of a search tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 Bug ID: 98426 Summary: find_symbol in module.c traverses O(N) part of a search tree Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 49837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49837&action=edit patch Compilation times of top level modules in a large project I am working on are abysmal (up to 30 seconds for modules even with little code in it). Those modules are using other modules whose mod files are up to 500kB. As far as I can see the mod files contain all [including private] symbols from any module in their use-chain. I used -pg compiler option to compile gcc itself and ran f951 and gprof with some modules. gprof showed that about 80% or more of the compilation time is spent in routine "find_symbol" in module.c. >From the documentation I can see that argument "gfc_symtree *st" of "find_symbol" should be a balanced binary search tree, ordered by gfc_symtree->name. It looks like the tree can have different nodes with the same name, so traversing the tree to check all nodes of the given name might require to descend both the left and right subtree. However, "find_symbol" traverses far more nodes than necessary. (Assuming that all symbol names are unique, it traverses about half of the tree on average, making the lookup operation O(N) instead of O(log N).) The attached patch descends only if it can expect a match in the subtree (and no match was found so far). This brings down the execution time of find_symbol to almost nothing, speeding up the compilation time by a factor of about 5-10 for my top level modules (makes a difference if a module compiles in 3 instead of 30 seconds)! The patch regtests, and also compiles the large project with its big symbol trees flawlessly and much faster. Are there any testcases which check that find_symbol works as expected? If I change find_symbol to always return NULL, then make -k check-fortran gives # of expected passes55911 # of unexpected failures1 # of expected failures 232 # of unsupported tests 81 with just one unexpected failure I could not locate. In particular if I compile check use_only_1.f90 by hand (added by PR33541, which added find_symbol), everything seems to work without a proper return value from find_symbol.
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 --- Comment #4 from martin --- Just checked the patch and it works great, except that I can now easily produce an ICE by changing (in sel_rank) type(tuple), dimension(..), intent(in) :: x to class(*), dimension(..), intent(in) :: x The ICE is fc_get_descriptor_field, at fortran/trans-array.c:140 0x613e94 gfc_get_descriptor_field ../../gcc-repo/gcc/fortran/trans-array.c:140 0x75cd35 gfc_conv_descriptor_data_get(tree_node*) ../../gcc-repo/gcc/fortran/trans-array.c:159 0x76b769 gfc_conv_array_data(tree_node*) ../../gcc-repo/gcc/fortran/trans-array.c:2985 0x76b769 structure_alloc_comps ../../gcc-repo/gcc/fortran/trans-array.c:8559 0x76d9ca gfc_deallocate_alloc_comp(gfc_symbol*, tree_node*, int, int) ../../gcc-repo/gcc/fortran/trans-array.c:9681 0x797535 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc-repo/gcc/fortran/trans-expr.c:6457 0x79088b gfc_trans_assignment_1 ../../gcc-repo/gcc/fortran/trans-expr.c:10930 0x757f33 trans_code ../../gcc-repo/gcc/fortran/trans.c:1888 0x781504 gfc_generate_function_code(gfc_namespace*) ../../gcc-repo/gcc/fortran/trans-decl.c:6880 0x6fd5ce translate_all_program_units ../../gcc-repo/gcc/fortran/parse.c:6351 0x6fd5ce gfc_parse_file() ../../gcc-repo/gcc/fortran/parse.c:6620 0x75503f gfc_be_parse_file ../../gcc-repo/gcc/fortran/f95-lang.c:212 Not sure whether this is an entirely new problem or related to the patch. At least trans-expr.c6457 is just about 20 lines below the place where the patch add the lines.
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 --- Comment #1 from martin --- This does not the require the recent patch proposed for bug 97694 and bug 97723. It also fails with gfortran 10.1.0.
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 --- Comment #6 from martin --- There is still a somewhat related problem if a variable of a derived type with allocatable component is provided to cssel. See bug 98342 with a simplified example code (without class(*)).
[Bug fortran/98342] New: Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 Bug ID: 98342 Summary: Allocatable component in call to assumed-rank routine causes invalid pointer Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 49784 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49784&action=edit Fortran source code The attached code aborts with *** Error in `./alloc_rank.x': munmap_chunk(): invalid pointer after finishing the function call to "sel_rank". Necessary ingredients are a derived type with an allocatable component and that the argument tuple of "sel_rank" has assumed rank.
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 --- Comment #5 from martin --- Thanks a lot. The patch seems to work great. Tried it with the more complex code from which the two failed tests were boiled down.
[Bug fortran/97612] Structure constructor of type with nested allocatable array components fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97612 --- Comment #2 from martin --- I do not see why it should not be valid. t() is a structure constructor acting much like a function with (in this case) one optional argument. And as an allocatable component has default initialisation, no value needs to be provided, to be valid constructor. Just to be sure I checked Metcalf (2011). Section 15.3 "Structure constructors" and 20.1.4 "Structure constructors" contain an interesting piece of information I did not know about: F03 forgot to allow that for allocatable components a value can be omitted. This was permitted in F08. So it looks like the provided code example is not valid F03 but valid F08. In fact, null() can be provided as default value. Then the code compiles: type(t) :: a = t(null())
[Bug fortran/87142] Aliasing issue with overloaded assignment and allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142 --- Comment #4 from martin --- With yesterdays master branch, I still see an invalid read with valgrind and an "AddressSanitizer: heap-use-after-free"-error with -fsanitize=address. So looks like this has not been fixed by the patch for PR 92178.
[Bug fortran/97723] New: type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 Bug ID: 97723 Summary: type bound ASSIGNMENT(=) within select rank block wrongly rejected Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 49504 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49504&action=edit Fortran source code Using an assignment for a derived-type within a select-rank block is rejected wrongly: rank_assign.f90:41:16: 41 | s = '0' |1 Error: ‘assign’ at (1) is not a function rank_assign.f90:43:16: 43 | s = '1' |1 Error: ‘assign’ at (1) is not a function rank_assign.f90:45:16: 45 | s = '?' |1 Error: ‘assign’ at (1) is not a function Using the assignment outside of such a select-rank works fine. Writing "s%c = ..." instead of "s = ..." also works well.
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 martin changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91926 --- Comment #1 from martin --- There are two resolved bug reports which are very similar, bug 61881 and bug 91926. At least bug 91926 is working fine. The other is pretty old and lacks the optional attribute.
[Bug fortran/97694] New: ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 Bug ID: 97694 Summary: ICE with optional assumed rank class(*) argument Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 49494 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49494&action=edit Fortran source code The attached code crashs with an ICE. It requires that the argument has type class(*) and is optional. classstar_rank.f90:14:0: 14 | s = '0' | internal compiler error: Segmentation fault 0xbe205f crash_signal ../../gcc-repo/gcc/toplev.c:328 0x793007 trans_associate_var ../../gcc-repo/gcc/fortran/trans-stmt.c:1765 0x798fe1 gfc_trans_block_construct(gfc_code*) ../../gcc-repo/gcc/fortran/trans-stmt.c:2283 0x724950 trans_code ../../gcc-repo/gcc/fortran/trans.c:1960 0x79a89f gfc_trans_select_rank_cases ../../gcc-repo/gcc/fortran/trans-stmt.c:3703 0x79a89f gfc_trans_select_rank(gfc_code*) ../../gcc-repo/gcc/fortran/trans-stmt.c:3758 0x724aa3 trans_code ../../gcc-repo/gcc/fortran/trans.c:1984 0x798f70 gfc_trans_block_construct(gfc_code*) ../../gcc-repo/gcc/fortran/trans-stmt.c:2276 0x724950 trans_code ../../gcc-repo/gcc/fortran/trans.c:1960 0x791065 gfc_trans_if_1 ../../gcc-repo/gcc/fortran/trans-stmt.c:1448 0x798a8b gfc_trans_if(gfc_code*) ../../gcc-repo/gcc/fortran/trans-stmt.c:1480 0x724b23 trans_code ../../gcc-repo/gcc/fortran/trans.c:1952 0x74dd44 gfc_generate_function_code(gfc_namespace*) ../../gcc-repo/gcc/fortran/trans-decl.c:6835 0x728571 gfc_generate_module_code(gfc_namespace*) ../../gcc-repo/gcc/fortran/trans.c:2264 0x6ca905 translate_all_program_units ../../gcc-repo/gcc/fortran/parse.c:6293 0x6ca905 gfc_parse_file() ../../gcc-repo/gcc/fortran/parse.c:6545 0x721c4f gfc_be_parse_file ../../gcc-repo/gcc/fortran/f95-lang.c:210
[Bug fortran/97612] New: Structure constructor of type with nested allocatable array components fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97612 Bug ID: 97612 Summary: Structure constructor of type with nested allocatable array components fails to compile Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- The program below does not compile with error message: constructor_allocatable.F90:4:9: 4 | type :: s | 1 Error: The rank of the element in the structure constructor at (1) does not match that of the component (0/1) It is essential that x is an array, and that component u of type s has the allocatable attribute as well. However, component u does not need to be an array to trigger the error. program constructor_allocatable implicit none type :: s integer, dimension(:), allocatable :: u end type s type :: t type(s), dimension(:), allocatable :: x end type t type(t) :: a = t() end program constructor_allocatable
