[Bug fortran/113797] Deferred length character concatenation in openmp region has wrong length

[mscfd at gmx dot net via Gcc-bugs]

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 = 
typedef character(kind=1) struct character(kind=1)[1:slen.1][1:slen.1];
pstr.2 = 0B;
slen.1 = 0;
concat_f (, , &"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 *) 
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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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=edit
reduced uninit_vptr

Testcase further reduced.

[Bug fortran/105503] New: vptr and data are uninitialised error for intent(out) argument of abstract type

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=edit
reduced testcase

[Bug fortran/93918] Segfault with -Ofast when calling a routine with an array argument array(:)%component

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=edit
reduced testcase

[Bug fortran/93924] ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=edit
corrected patch

Comparison with c was wrong.

[Bug fortran/98454] Apparent wrong initialization in function result

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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

[mscfd at gmx dot net via Gcc-bugs]

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=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

[mscfd at gmx dot net via Gcc-bugs]

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

[Bug fortran/96131] New: ICE in fold_convert_loc, at fold-const.c:2435

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96131

Bug ID: 96131
   Summary: ICE in fold_convert_loc, at fold-const.c:2435
   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 code below fails with an ICE in fold_convert_loc, at fold-const.c:2435.
There is another recent bug 94730 with an ICE at this location, but triggered
with C code. Is this maybe related?

Also fails with ICE with gfortran 8.2.1 and 9.1.1.

> gfortran-10 procptr.f90

module mod

implicit none
public

type :: t
   procedure(get_ifc), pointer, nopass :: get => null()
end type t

abstract interface
   function get_ifc() result(x)
  import t
  type(t), pointer :: x
   end function get_ifc
end interface

contains

   function foo() result(x)
  type(t), pointer :: x
  x => null()
   end function foo

end module mod


program procptr

use mod
implicit none

type(t) :: x
type(t), pointer :: y

x%get => foo
y => x%get()

end program procptr

[Bug fortran/93691] Type bound assignment causes too many finalization of derived type when part of other type

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93691

martin  changed:

   What|Removed |Added

 CC||mscfd at gmx dot net

--- Comment #2 from martin  ---
This might be related to bug 88735, at least the ingredients are very similar
and final routine is called wrongly.

[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956

--- Comment #3 from martin  ---
Sorry, indeed the line 'n=1' is missing. Not sure how that single line got
lost.

There are a few possibilities as a work around for this simple case, but the
context where I came upon this bug is (as often) more involved. There the get
routine has an additional argument selecting the component of the type and the
aim was to put this selection process into a separate subroutine or function.

[Bug fortran/93956] New: Wrong array creation with p => array_dt(1:n)%component

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956

Bug ID: 93956
   Summary: Wrong array creation with p => array_dt(1:n)%component
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

The following code (compiled without any options) prints "15000, 1" for the
second call to foo, instead of the expected "2, 1". The first call to
foo gives the expected result. This is also reproducible with gfortran-10
branch.

This code is a variation of the one reported in bug 93918 to further understand
temporary array creation.

program array_temps
implicit none

type :: tt
   integer :: u = 1
   integer :: v = 2
end type tt

type(tt), dimension(:), pointer :: r
integer :: n
integer, dimension(:), pointer :: p

allocate(r(1:n))
call foo(r(:)%v, n)
p => get(r(:))
call foo(p, n)
deallocate(r)

contains

   subroutine foo(a, n)
  integer, dimension(:), intent(in) :: a
  integer, intent(in) :: n
  print *, sum(a(1:n)), n
   end subroutine foo

   function get(x) result(q)
  type(tt), dimension(:), target, intent(in) :: x
  integer, dimension(:), pointer :: q
  q => x(:)%v
   end function get

end program array_temps

[Bug fortran/93918] Segfault with -Ofast when calling a routine with an array argument array(:)%component

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918

--- Comment #4 from martin  ---
After playing around a bit I am really confused about why and when array
temporaries are created.

The variant ppp_1 with a non-contiguous array pointer p works fine (with
-Ofast), but the variation ppp_2 (this time even with a contiguous array
pointer) fails. To make it even more puzzling, variation ppp_3, where the
pointer association is done in a function, works.
To me it seems obscure to understand and thus avoid creation of temporary
arrays.


program ppp_1
use mod
implicit none

integer :: n
integer, dimension(:,:), pointer :: a
integer, dimension(:), pointer :: p
n = 1

allocate(a(1:2,1:n), source=1)
p => a(1,1:n)
call foo(p, n)
deallocate(a)

end program ppp_1



program ppp_2
use mod
implicit none

type :: tt
   integer :: u = 1
end type tt

type(tt), dimension(:), pointer :: r
integer :: n
integer, dimension(:), pointer :: p
n = 1

allocate(r(1:n))
p => r(:)%u
call foo(p, n)
deallocate(r)

end program ppp_2



program ppp_3
use mod
implicit none

type :: tt
   integer :: u = 1
end type tt

type(tt), dimension(:), pointer :: r
integer :: n
integer, dimension(:), pointer :: p
n = 1

allocate(r(1:n))
p => get(r(1:n))
call foo(p, n)
deallocate(r)

contains

   function get(x) result(q)
  type(tt), dimension(:), target, intent(in) :: x
  integer, dimension(:), pointer :: q
  q => x(:)%u
   end function get

end program ppp_3

[Bug fortran/93918] Segfault with -Ofast when calling a routine with an array argument array(:)%component

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918

--- Comment #3 from martin  ---
But there should not be an temporary array in the first place, which is causing
the problem?

[Bug fortran/93925] New: Invalid memory reference upon call of a routine taking a procedure pointer as argument

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925

Bug ID: 93925
   Summary: Invalid memory reference upon call of a routine taking
a procedure pointer as argument
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

The following code aborts with a segfault (invalid memory reference) upon call
of the apply function. This happens with gfortran 9.1.1 as well as a recent
gfortran-10.

module cs

implicit none
private

public classStar_map_ifc
public fun, apply

abstract interface
   function classStar_map_ifc(x) result(y)
  class(*), pointer:: y
  class(*), target, intent(in) :: x
   end function classStar_map_ifc
end interface

contains

   function fun(x) result(y)
  class(*), pointer:: y
  class(*), target, intent(in) :: x
  select type (x)
  type is (integer)
 y => x
  class default
 y => null()
  end select
   end function fun

   function apply(f, x) result(y)
  procedure(classStar_map_ifc) :: f
  integer, intent(in) :: x
  integer :: y
  class(*), pointer :: p
  p => f(x)
  select type (p)
  type is (integer)
 y = p
  end select
   end function apply

end module cs


program classStar_map2

use cs
implicit none

integer :: x, y
procedure(classStar_map_ifc), pointer :: f

x = 123654
y = apply(fun, x)
print *, x, y

end program classStar_map2

[Bug fortran/93924] New: ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924

Bug ID: 93924
   Summary: ICE in gfc_class_len_get at trans_expr.c:231 with
function returning a procedure pointer
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

The code below aborts with an ICE. This happens with 9.1.1 as well as a recent
gfortran-10 compiled version. The ICE is due to the function selector.

module cs

implicit none
private

public classStar_map_ifc
public apply, selector

abstract interface
   function classStar_map_ifc(x) result(y)
  class(*), pointer:: y
  class(*), target, intent(in) :: x
   end function classStar_map_ifc
end interface

contains

   function fun(x) result(y)
  class(*), pointer:: y
  class(*), target, intent(in) :: x
  select type (x)
  type is (integer)
 y => x
  class default
 y => null()
  end select
   end function fun

   function apply(f, x) result(y)
  procedure(classStar_map_ifc) :: f
  integer, intent(in) :: x
  integer :: y
  class(*), pointer :: p
  p => f(x)
  select type (p)
  type is (integer)
 y = p
  end select
   end function apply

   function selector() result(f)
  procedure(classStar_map_ifc), pointer :: f
  f => fun
   end function selector

end module cs


program classStar_map

use cs
implicit none

integer :: x, y
procedure(classStar_map_ifc), pointer :: f

x = 123654
f => selector()
y = apply(f, x)
print *, x, y

end program classStar_map

[Bug fortran/93918] New: Segfault with -Ofast when calling a routine with an array argument array(:)%component

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918

Bug ID: 93918
   Summary: Segfault with -Ofast when calling a routine with an
array argument array(:)%component
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

The code below results in a SEGFAULT when compiled with -Ofast in gfortran
9.1.1 as well as some recent compiled gfortran-10 commit. With -O2 the program
finishes without errors (also no reports from valgrind).

The segfault only occurs, if the array size is sufficiently large (reducing n
by a factor of 10 avoids the problem). valgrind reports a stack problem:

==28808== Warning: client switching stacks?  SP change: 0x1ffeffea70 -->
0x1ffc9d9070
==28808==  to suppress, use: --max-stackframe=4000 or greater
==28808== Invalid write of size 8
==28808==at 0x400818: ppp (ppp.f90:31)
==28808==by 0x400818: main (ppp.f90:19)
==28808==  Address 0x1ffc9d9068 is on thread 1's stack
==28808== 
==28808== Can't extend stack to 0x1ffc9d8118 during signal delivery for thread
1:
==28808==   no stack segment
==28808== 
==28808== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==28808==  Access not within mapped region at address 0x1FFC9D8118
==28808==at 0x400818: ppp (ppp.f90:31)
==28808==by 0x400818: main (ppp.f90:19)
==28808==  If you believe this happened as a result of a stack
==28808==  overflow in your program's main thread (unlikely but
==28808==  possible), you can try to increase the size of the
==28808==  main thread stack using the --main-stacksize= flag.
==28808==  The main thread stack size used in this run was 8388608.
==28808== Invalid write of size 8
==28808==at 0x4A2861A: _vgnU_freeres (vg_preloaded.c:59)
==28808==  Address 0x1ffc9d8fe0 is on thread 1's stack

Also increasing stacksize as suggested by valgrind also avoids the invalid
write. Does gfortran generate a temporary array here (but only with -Ofast)?


module mod

implicit none
private
public foo

contains

subroutine foo(a, n)
   integer, dimension(:), intent(in) :: a
   integer, intent(in) :: n
   print *, sum(a(1:n)), n
end subroutine foo

end module mod


program ppp
use mod
implicit none

type :: tt
   integer :: u = 1
end type tt

type(tt), dimension(:), allocatable :: r
integer :: n

n = 1000
allocate(r(1:n))
call foo(r(:)%u, n)
deallocate(r)

end program ppp

[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178

martin  changed:

   What|Removed |Added

 CC||mscfd at gmx dot net

--- Comment #9 from martin  ---
Is this possibly related to bug 87142?

[Bug fortran/90421] New: Invalid memory write in allocate on assignment to a class(*) variable

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90421

Bug ID: 90421
   Summary: Invalid memory write in allocate on assignment to a
class(*) variable
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

The following code (classstar_alloc3 from PR86328, but much reduced; the
original bug case from this PR has been fixed, the one below was intended as a
work around) shows an invalid write of size 2 with valgrind. Compiling with

gfortran-9 -fsanitize=address -g classstar_alloc3.f90 -o classstar_alloc3

and executing classstar_alloc3 gives

==27530==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x602000b1 at pc 0x7f43577d3e9e bp 0x7fff7c4b5ce0 sp 0x7fff7c4b5490
WRITE of size 2 at 0x602000b1 thread T0
#0 0x7f43577d3e9d in __interceptor_memmove
(/usr/lib64/libasan.so.5+0x39e9d)
#1 0x400ddc in __copy_character_1 /home/xxx/classstar_alloc3.f90:1
#2 0x4022d3 in rrr /home/xxx/classstar_alloc3.f90:28
#3 0x401dc0 in classstar_alloc3 /home/xxx/classstar_alloc3.f90:19
#4 0x402625 in main /home/xxx/classstar_alloc3.f90:19
#5 0x7f4356803f89 in __libc_start_main (/lib64/libc.so.6+0x20f89)
#6 0x400c99 in _start (/home/xxx/classstar_alloc3+0x400c99)

0x602000b1 is located 0 bytes to the right of 1-byte region
[0x602000b0,0x602000b1)
allocated by thread T0 here:
#0 0x7f4357885600 in malloc (/usr/lib64/libasan.so.5+0xeb600)
#1 0x4020ba in rrr /home/xxx/classstar_alloc3.f90:28
#2 0x401dc0 in classstar_alloc3 /home/xxx/classstar_alloc3.f90:19
#3 0x402625 in main /home/xxx/classstar_alloc3.f90:19
#4 0x7f4356803f89 in __libc_start_main (/lib64/libc.so.6+0x20f89)
...


program classstar_alloc
   class(*), allocatable :: a, b

   allocate(a, source='01')
   b = a
end program classstar_alloc

[Bug fortran/88669] Contiguous attribute wrongly rejected

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669

--- Comment #6 from martin  ---
Thanks for fixing.

[Bug fortran/89033] New: gfortran accepts invalid code in select type construct with pointer assignment

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89033

Bug ID: 89033
   Summary: gfortran accepts invalid code in select type construct
with pointer assignment
   Product: gcc
   Version: 9.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 code below should be invalid, as the selector x has attribute "target" but
not "pointer" inside the select type block (2008 draft, 8.1.3.3). The code
compiles, but it gives a suprising output, namely x is still associated,
despite the accepted "x => null()" line.

program select_type_ptr

implicit none

type t
   integer :: i = 1
end type t

class(*), pointer :: x
type(t), pointer :: y

allocate(x, source = t(3))

select type (x)
type is (t)
   y => x
   x => null()
end select

print *, associated(x), associated(y)
print *, y%i

end program select_type_ptr

[Bug fortran/88768] Derived type io in conjunction with allocatable component and recursion fails

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88768

--- Comment #3 from martin  ---
I have opened a separate PR 88899 for the openmp related invalid memory read,
but I guess it might have the same cause.

[Bug fortran/88899] Derived type IO in conjunction with openmp fails with invalid memory read

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88899

martin  changed:

   What|Removed |Added

  Known to fail||8.2.1

--- Comment #2 from martin  ---
Related to PR 88768.

[Bug fortran/88899] Derived type IO in conjunction with openmp fails with invalid memory read

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88899

--- Comment #1 from martin  ---
With sufficiently many threads (at least 5 or 6 for me) the address santizer
gives (for gfortran-9, compiled a few weeks ago):

==3485==ERROR: AddressSanitizer: attempting double-free on 0x6020001956d0 in
thread T4:
#0 0x7f72705a7280 in __interceptor_free (/usr/lib64/libasan.so.5+0xeb280)
#1 0x401935 in __mod_MOD___final_mod_T
/home/mstein/code/forcomp_bugs/dt_io_2.f90:43
#2 0x402fb1 in __mod_MOD_work /home/mstein/code/forcomp_bugs/dt_io_2.f90:21
#3 0x40362a in MAIN__._omp_fn.0
/home/mstein/code/forcomp_bugs/dt_io_2.f90:56
#4 0x7f726faeb83d  (/usr/lib64/libgomp.so.1+0x1783d)
#5 0x7f726f465558 in start_thread (/lib64/libpthread.so.0+0x7558)
#6 0x7f726f19c81e in __GI___clone (/lib64/libc.so.6+0xf881e)

0x6020001956d0 is located 0 bytes inside of 8-byte region
[0x6020001956d0,0x6020001956d8)
freed by thread T2 here:
#0 0x7f72705a7280 in __interceptor_free (/usr/lib64/libasan.so.5+0xeb280)
#1 0x401935 in __mod_MOD___final_mod_T
/home/mstein/code/forcomp_bugs/dt_io_2.f90:43
#2 0x402fb1 in __mod_MOD_work /home/mstein/code/forcomp_bugs/dt_io_2.f90:21
#3 0x40362a in MAIN__._omp_fn.0
/home/mstein/code/forcomp_bugs/dt_io_2.f90:56
#4 0x7f726faeb83d  (/usr/lib64/libgomp.so.1+0x1783d)

previously allocated by thread T2 here:
#0 0x7f72705a7600 in malloc (/usr/lib64/libasan.so.5+0xeb600)
#1 0x402a17 in __mod_MOD_set /home/mstein/code/forcomp_bugs/dt_io_2.f90:29
#2 0x4032a0 in __mod_MOD_work /home/mstein/code/forcomp_bugs/dt_io_2.f90:23
#3 0x40362a in MAIN__._omp_fn.0
/home/mstein/code/forcomp_bugs/dt_io_2.f90:56
#4 0x7f726faeb83d  (/usr/lib64/libgomp.so.1+0x1783d)

Thread T4 created by T0 here:
#0 0x7f7270508620 in pthread_create (/usr/lib64/libasan.so.5+0x4c620)
#1 0x7f726faebe39  (/usr/lib64/libgomp.so.1+0x17e39)
#2 0x7f726fae2d59 in GOMP_parallel (/usr/lib64/libgomp.so.1+0xed59)

Thread T2 created by T0 here:
#0 0x7f7270508620 in pthread_create (/usr/lib64/libasan.so.5+0x4c620)
#1 0x7f726faebe39  (/usr/lib64/libgomp.so.1+0x17e39)
#2 0x7f726fae2d59 in GOMP_parallel (/usr/lib64/libgomp.so.1+0xed59)

SUMMARY: AddressSanitizer: double-free (/usr/lib64/libasan.so.5+0xeb280) in
__interceptor_free
==3485==ABORTING

[Bug fortran/88899] New: Derived type IO in conjunction with openmp fails with invalid memory read

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88899

Bug ID: 88899
   Summary: Derived type IO in conjunction with openmp fails with
invalid memory read
   Product: gcc
   Version: 9.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 code below fails with an invalid memory read. The derivated type IO
write(formatted) is declared but not used. Without this line the code runs
fine. Without the openmp loop it also runs fine.
Unfortunately, this bug makes derived type IO in parallelised code unusable.

module mod

implicit none
private

public work

type, public :: t
   real, dimension(:), allocatable :: r
contains
   procedure :: set
   generic :: assignment(=) => set

   ! comment out this write(formatted) declaration, and it runs fine
   generic :: write(formatted) => write_formatted
   procedure :: write_formatted
end type t

contains

subroutine work(a)
   class(t), intent(out) :: a
   a = [0.1, -0.3]
end subroutine work

subroutine set(self, r)
   class(t), intent(out) :: self
   real, dimension(:), intent(in) :: r
   self%r = r
end subroutine set

subroutine write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
   class(t),  intent(in):: dtv
   integer,   intent(in):: unit
   character(len=*),  intent(in):: iotype
   integer, dimension(:), intent(in):: v_list
   integer,   intent(out)   :: iostat
   character(len=*),  intent(inout) :: iomsg
   write(unit, '(a)', iostat=iostat, iomsg=iomsg) 'formatted'
end subroutine write_formatted

end module mod


program dt_io

use mod
implicit none

type(t) :: x
integer :: i

!$omp parallel do default(shared) private(i, x)
do i = 1,100
   call work(x)
end do
!$omp end parallel do

end program dt_io

[Bug fortran/88768] Derived type io in conjunction with allocatable component and recursion fails

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88768

--- Comment #2 from martin  ---
If I add the "generic :: write(unformatted) => write_unformatted" part in my
code (but do not use it), I see other failures somehow triggered by openmp
parallelisation (no recursion involved). Using the address sanitizer I can see
that one thread tries to access some memory already freed by another thread.
However, the concerned variables (of what is type(t) in the example code above)
are thread private and in fact several subroutine calls and modules away from
the openmp parallelisation block.

Unfortunately so far I was not able to produce a simple test case. However, it
looks like that the DT IO part uses some kind of global addresses, which does
not work well with recursion or threading?

[Bug fortran/88768] New: Derived type io in conjunction with allocatable component and recursion fails

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88768

Bug ID: 88768
   Summary: Derived type io in conjunction with allocatable
component and recursion fails
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

This is a strange bug, which requires a some kind of dt IO (defined as "
generic :: write(unformatted) => write_unformatted", but not used!), an
allocatable component with dimension(:) (a "character(len=:), allocatable"
triggers the bug as well), and a recursive function.

If the "write(unformatted)"-part is commented out, the bug does not occur.
Without recursing, the return value is fine (variable y). Also, if the
dimension(:) is omitted in the declaration of r, then the bug disappears as
well.

The code either show funny values for z or segfaults. Valgrind shows an illegal
memory read.


module mod

implicit none
private

type, public :: t
   real, dimension(:), allocatable :: r
contains
   procedure :: set
   generic :: assignment(=) => set
   procedure :: recurse
   generic :: write(unformatted) => write_unformatted
   procedure :: write_unformatted
end type t

contains

subroutine set(self, x)
   class(t), intent(out) :: self
   class(t), intent(in) :: x
   real, dimension(:), allocatable :: tmp
   if (allocated(x%r)) then
  ! make a local copy to avoid any aliasing issues
  tmp = x%r
  self%r = tmp
   end if
end subroutine set

recursive function recurse(self, i) result(x)
   type(t) :: x
   class(t), intent(in) :: self
   integer,  intent(in) :: i
   if (i > 0) then
  x = self%recurse(i-1)
   else
  x = self
   end if
end function recurse

subroutine write_unformatted(dtv, unit, iostat, iomsg)
   class(t), intent(in):: dtv
   integer,  intent(in):: unit
   integer,  intent(out)   :: iostat
   character(len=*), intent(inout) :: iomsg
   write(unit, iostat=iostat, iomsg=iomsg) 'unformatted'
end subroutine write_unformatted

end module mod


program dt_io

use mod
implicit none

type(t) :: x, y, z

x%r = [1.23, 2.21]
y = x%recurse(0)  ! fine
z = x%recurse(1)  ! fails

print *, x%r
print *, y%r
print *, z%r

end program dt_io

[Bug fortran/88735] Nested assignment triggers call of final method for right hand side

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735

--- Comment #1 from martin  ---
Remark: output should be one line
setting:  123

If the output starts with
finalising:  123
then this is wrong (as b%x%i is not associated when finalise is called for
b%x).

Also present in current gfortran-9 branch compiled a couple of days ago.

[Bug fortran/88735] New: Nested assignment triggers call of final method for right hand side

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735

Bug ID: 88735
   Summary: Nested assignment triggers call of final method for
right hand side
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

In the following code a type "t" is defined in module mod, which provides an
assignment method and a final routine. The program itself defines a type "s",
with a component of type "t". Assignment "b=a" should call the final method for
b%x, as procedure "set" has intent(out) for self. However, as can be seen from
the output, finalise is called for the right hand side (the intent(in)
argument). The set routine is called afterwards, surprisingly still thinks that
x%i is allocated (it has been wrongly deallocated within finalise). The value
however is somehow set to zero (looks like the deallocated memory zeroed?).

The problem does not occur with intent(inout) for argument "self" in procedure
"set", as finalise is not called at all. The problem does not occur if a and b
are of type t. The nested assignment via type s is necessary to trigger the
bug.


module mod

implicit none
private

type, public :: t
   integer, pointer :: i => null()

contains
   procedure, public :: set
   generic, public :: assignment(=) => set
   final :: finalise
end type t


contains

subroutine set(self, x)
   class(t), intent(out) :: self
   class(t), intent(in)  :: x
   if (associated(x%i)) then
  print *, 'setting: ', x%i
  self%i => x%i
  self%i = self%i + 1
   end if
end subroutine set


subroutine finalise(self)
   type(t), intent(inout) :: self
   if (associated(self%i)) then
  print *, 'finalising: ', self%i
  deallocate(self%i)
   end if
end subroutine finalise

end module mod


program finalise_assign
use mod
implicit none

type :: s
   type(t) :: x
end type s

type(s) :: a, b

allocate(a%x%i)
a%x%i = 123

b = a

end program finalise_assign

[Bug fortran/88669] New: Contiguous attribute wrongly rejected

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669

Bug ID: 88669
   Summary: Contiguous attribute wrongly rejected
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

The code below gives the following error

contiguous_pointer.f90:7:51:

class(t), dimension(:), contiguous, pointer :: x
   1
Error: Component ‘x’ at (1) has the CONTIGUOUS attribute but is not an array
pointer

With type(t) instead of class(t) , the error does not occur.



program contiguous_pointer

type t
end type t

type s
   class(t), dimension(:), contiguous, pointer :: x
end type s

end program contiguous_pointer

[Bug fortran/88447] Non-contiguous array argument of some class not passed properly to subroutine

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88447

--- Comment #1 from martin  ---
Here is a smaller reproducer. The component "integer :: i" in type t is
necessary to reproduce the bug.

module mod

implicit none
private

public qv

type, public :: s
   real, dimension(1:3) :: vec
end type s

type, public :: t
   integer :: i
   type(s) :: v
end type t


contains


subroutine qv(x)
   class(s), dimension(:), intent(in) :: x
   integer :: i
   write(*,'(a,*(3f12.3," |"))') 'x = ', (x(i)%vec, i=1,ubound(x,1))
end subroutine qv

end module mod



program noncontiguous

use mod
implicit none

integer :: k
type(t), dimension(1:2) :: a

do k = 1,2
   a(k)%i = k
   a(k)%v%vec = [real(k)+1.0, real(k)+2.0, real(k)+3.0]
end do

call qv(a%v)

end program noncontiguous

[Bug fortran/88447] New: Non-contiguous array argument of some class not passed properly to subroutine

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88447

Bug ID: 88447
   Summary: Non-contiguous array argument of some class not passed
properly to subroutine
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

Using a non-contiguous argument to a subroutine whose declaration is "class(s),
dimension(:)" gives wrong results. The output looks like that some internal
offset in the array descriptor is computed wrongly. Using type(s) instead of
class(s) fixes the problem. The bug also occurs with the class(*) variant.

module mod

implicit none
private

public p, qi, qr, qv

type, public :: s
   real, dimension(1:3) :: vec
end type s

type, public :: t
   integer :: i
   type(s) :: v
   real :: r
end type t


contains


subroutine p(x)
   class(*), dimension(:), intent(in) :: x
   integer :: i
   select type (x)
   type is (integer)
  write(*,'(a,*(i12))')   'x = ', x
   type is (real)
  write(*,'(a,*(f12.3))') 'x = ', x
   type is (s)
  write(*,'(a,*(3f12.3," |"))') 'x = ', (x(i)%vec, i=1,ubound(x,1))
   end select
end subroutine p


subroutine qi(x)
   integer, dimension(:), intent(in) :: x
   write(*,'(a,*(i12))')   'x = ', x
end subroutine qi

subroutine qr(x)
   real, dimension(:), intent(in) :: x
   write(*,'(a,*(f12.3))') 'x = ', x
end subroutine qr

subroutine qv(x)
   ! with type(s) the bug does not occur
   !type(s), dimension(:), intent(in) :: x
   class(s), dimension(:), intent(in) :: x
   integer :: i
   write(*,'(a,*(3f12.3," |"))') 'x = ', (x(i)%vec, i=1,ubound(x,1))
end subroutine qv

end module mod



program noncontiguous

use mod
implicit none

integer :: k
type(t), dimension(1:4) :: a

do k = 1,4
   a(k)%i = k
   a(k)%r = 10.0 * 2.0*real(k)
   a(k)%v%vec = [real(k)-2.0, real(k)-3.0, real(k)-5.0]
end do

! wrong output for all three calls
call p(a%i)
call p(a%r) 
call p(a%v)

! correct output for the first and second call,
! wrong output for third call (correct if type(s) instead of class(s) is used)
call qi(a%i)
call qr(a%r)
call qv(a%v)

end program noncontiguous

[Bug fortran/87448] ICE at trans-expr:3417 in allocate statement with type signature using an associated variable

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448

--- Comment #2 from martin  ---
Originally I came across this problem in a large module with a slightly more
complex function with gfortran-7.3.0 (standard version from ubuntu 18.4). I got
the same bogus error, which Janus has seen for this reduced testcase with
gfortran-5.5. Taking out the function and related class I got the ICE, but was
not able to reproduce this error.

In short: I think that the bogus error is still present in recent gfortran
versions (or is just another symptom of this problem).

[Bug fortran/87448] New: ICE at trans-expr:3417 in allocate statement with type signature using an associated variable

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448

Bug ID: 87448
   Summary: ICE at trans-expr:3417 in allocate statement with type
signature using an associated variable
   Product: gcc
   Version: 8.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 following code triggers an ICE (also seen in some gfortran-7 version):

module mod

implicit none
public

contains

function fun(cs) result(rs)
   character(len=:), allocatable :: rs
   character(len=*), intent(in) :: cs

   associate(l => len(cs))
  allocate(character(len=1+l) :: rs)
   end associate
end function fun

end module mod


gfortran -c assoc_len.f90 gives

assoc_len.f90:13:0:

   allocate(character(len=1+l) :: rs)

internal compiler error: in gfc_conv_expr_op, at fortran/trans-expr.c:3417
0x5b156d gfc_conv_expr_op
../.././gcc/fortran/trans-expr.c:3417
0x5b156d gfc_conv_expr(gfc_se*, gfc_expr*)
../.././gcc/fortran/trans-expr.c:7918
0x72bfb9 gfc_trans_allocate(gfc_code*)
../.././gcc/fortran/trans-stmt.c:6115
0x6bc4b7 trans_code
../.././gcc/fortran/trans.c:1996
0x72858f gfc_trans_block_construct(gfc_code*)
../.././gcc/fortran/trans-stmt.c:2058
0x6bc527 trans_code
../.././gcc/fortran/trans.c:1924
0x6e293b gfc_generate_function_code(gfc_namespace*)
../.././gcc/fortran/trans-decl.c:6507
0x6bfec9 gfc_generate_module_code(gfc_namespace*)
../.././gcc/fortran/trans.c:
0x6734f4 translate_all_program_units
../.././gcc/fortran/parse.c:6108
0x6734f4 gfc_parse_file()
../.././gcc/fortran/parse.c:6324
0x6b991f gfc_be_parse_file
../.././gcc/fortran/f95-lang.c:204

The problem is triggered by the combination of using associate in conjunction
with the allocate. With a local variable instead of the associate for l, or
with another statement instead of an allocate (i.e. "print *,l), gfortran
compiles.
Also when simplifying the length expression in the allocate from "len=1+l" to
just "len=l" the ICE disappears.

[Bug fortran/87142] Aliasing issue with overloaded assignment and allocatable components

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142

--- Comment #1 from martin  ---
The relevant passage from the standard is:

F2008, 12.4.3.4.3 (Defined assignments) says: "A defined assignment is treated
as a reference to the subroutine, with the left-hand side as the first argument
and the right-hand side enclosed in parentheses as the second argument."

The important part is the "enclosed in parentheses".

Please note that in most circumstances, the problem can only be seen in
valgrind. I have not been able to write a testcase, which consistently fails in
a simply visible manner. It all depends on the inner workings of the malloc
routines, whether the code works or segfaults or produces wrong results
(usually with control characters in the result).

[Bug fortran/86328] [8/9 Regression] Runtime segfault reading an allocatable class(*) object in allocate statements

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328

--- Comment #17 from martin  ---
Thanks for fixing it! Using class(*) with gfortran is still a bit of a
precarious ride.

[Bug fortran/87142] New: Aliasing issue with overloaded assignment and allocatable components

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142

Bug ID: 87142
   Summary: Aliasing issue with overloaded assignment and
allocatable components
   Product: gcc
   Version: 7.3.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 following code does not work, as the left hand side in "str = str%cs(1:10)"
is deallocated, before the right hand side, where str also appears, is
evaluated. With gfortran-7.3.0, the output looks right, but I see invalid
memory accesses in valgrind. In other circumstances, depending on the length of
the string and with 8.1.0, I have also seen wrong results, but then depending
on the optimisation level. As far as I know, this is a violation of the
standard, which requires that the right hand side is evaluated before the left
hand side is modified (i.e. in this case deallocated).

module mod

implicit none
private

type, public :: string
   character(len=:), allocatable :: cs

contains
   procedure, public :: assign
   generic, public :: assignment(=) => assign
end type string

contains

elemental subroutine assign(self, cs)
class(string), intent(inout) :: self
character(len=*), intent(in) :: cs

! this is not working if cs and self%cs are aliasing
self%cs = cs
end subroutine assign

end module mod



program assign_alias

use mod
implicit none

type(string) :: str

str%cs = repeat('0123456789', 100)

str = str%cs(1:10)

end program assign_alias

[Bug fortran/86328] [8/9 Regression] Runtime segfault reading an allocatable class(*) object in allocate statements

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328

--- Comment #12 from martin  ---
The workaround mentioned by Paul in comment #9 is working only partially. For
character sequences (and possibly other data types), valgrind still complains.
Surprisingly, using a single character works as well. On the other with three
or more characters, valgrind sees one more invalid read than with two
characters. The workaround for me was to switch to a string derived-type, which
encapsulates the character variable. Then I only see memory leaks, but no
invalid reads, or other serious stuff.

Here is the variation which still shows the problems with a character constant:

program classstar_alloc3

   type :: t
  class(*), allocatable :: val
   end type

   type :: list
  type(t), dimension(:), pointer :: ll
   end type

   integer :: i
   type(list) :: a

   allocate(a%ll(1:2))
   do i = 1,2
  allocate(a%ll(i)%val, source='01')
   end do

   call rrr(a)

contains

   subroutine rrr(a)
  type(list), intent(in) :: a
  class(*), allocatable :: c

  ! allocate(c, source=a%ll(2)%val)
  c = a%ll(2)%val
   end subroutine

end program classstar_alloc3

[Bug fortran/86350] Missed optimization with multiplication by zero

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86350

martin  changed:

   What|Removed |Added

 CC||mscfd at gmx dot net

--- Comment #5 from martin  ---
@kargl: "Rather odd to need an option to get standard conforming
behavior."
I do not understand this sentence. From what you cited from the standard it is
clear that it is not necessary to call function bar() from your example, but
the compiler is allowed to do so. Hence evaluating bar() is definitely standard
conformant. Not evaluating it is also standard conformant. This is not a nice
situation allowed by the standard.

But in my opinion, a compiler aiming for portability should definitely always
call bar() if the standard allows this, even if it might mean a missed
optimisation. If the programmer is keen on such optimisations, the code can
easily be rewritten to take advantage of not calling bar if the first operand
is zero.

[Bug fortran/86328] Runtime segfault reading an allocatable class(*) object in allocate statements

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328

martin  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86117

--- Comment #1 from martin  ---
Related bug: PR86117

[Bug fortran/86328] New: Runtime segfault reading an allocatable class(*) object in allocate statements

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328

Bug ID: 86328
   Summary: Runtime segfault reading an allocatable class(*)
object in allocate statements
   Product: gcc
   Version: 8.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 following code leads to a runtime segfault:

program ptr_alloc

   type :: t
  class(*), allocatable :: val
   end type t

   type :: list
  type(t), dimension(:), pointer :: ll
  integer :: cnt
   end type list

   integer :: i
   type(list) :: a

   allocate(a%ll(1:1))
   do i = 1,10
  print *,i
  a%cnt = i
  allocate(a%ll(i)%val, source=i)
  call rrr(a)
   end do

contains

   subroutine rrr(a)
  type(list) :: a

  integer :: s, i
  type(t), dimension(:), pointer :: mm

  s = ubound(a%ll,1) + 1
  allocate(mm(1:s))

  do i = 1, s-1
 if (allocated(a%ll(i)%val)) then
allocate(mm(i)%val, source=a%ll(i)%val)
!allocate(mm(i)%val, mold=a%ll(i)%val)
!mm(i)%val = a%ll(i)%val

deallocate(a%ll(i)%val)
 end if
  end do
  deallocate(a%ll)
  a%ll => mm
   end subroutine rrr

end program ptr_alloc


Using the commented mold and assignment version also leads to a segfault. Using
allocation on assignment (just the commented assignment) works, but then the
deallocation statement fails with a segfault.

valgrind reports an "Invalid read of size 8".

[Bug fortran/86119] New: Intrinsic len has wrong type if used within select type for a class(*) string

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86119

Bug ID: 86119
   Summary: Intrinsic len has wrong type if used within select
type for a class(*) string
   Product: gcc
   Version: 8.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 following program, compiled with -Wall gives the warning

   l2 = len(s)
   1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4)
at (1) [-Wconversion]

(No warning for len_trim!)

This is directly related to the use of select type in conjunction with
class(*).
If s is declared as character(len=:) and the select type block is removed, then
there is no warning.


program proglen

implicit none

   class(*), allocatable :: s
   integer :: l1, l2

   allocate(s, source = '123  ')

   select type(s)
   type is (character(len=*))
  l1 = len_trim(s)
  l2 = len(s)
   end select

end program proglen

[Bug fortran/86117] New: bogus warning maybe-uninitialized with class(*) and source argument in allocate

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86117

Bug ID: 86117
   Summary: bogus warning maybe-uninitialized with class(*) and
source argument in allocate
   Product: gcc
   Version: 8.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: ---

Compiling the following module with

gfortran -Og -Wall -fcheck=all -c mod.f90

gives

 Warning: ‘’ may be used uninitialized in this function
[-Wmaybe-uninitialized]

When leaving out any one of the three options -Og, -Wall or -fcheck=all the
warning disappears.

When replacing class(*) with integer the warning also disappears.

When using scalars for a and b (omitting the dimension(:) part and the do loop)
the warning also disappears.


module mod

private
public sub

   type, public :: generic
  class(*), allocatable :: item
  ! with integer instead of class(*), there is no warning
!  integer, allocatable :: item
   end type generic

contains

   subroutine sub(a, b)
  type(generic), dimension(:), intent(in) :: a
  type(generic), dimension(:), intent(out) :: b

  integer :: i

  do i = 1, 10
 allocate(b(i)%item, source=a(i)%item)
  end do
   end subroutine sub

end module mod

[Bug fortran/86116] New: Ambiguous generic interface not recognised

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86116

Bug ID: 86116
   Summary: Ambiguous generic interface not recognised
   Product: gcc
   Version: 8.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 following module should not compile. Calling sub(z) with z declared as
"type(t), allocatable :: z" shows the ambiguity.
Replacing "type(t) :: x" by "integer :: x" in the definition of s1 gives the
expected error "Ambiguous interfaces in generic interface 'sub' for ‘s1’ at (1)
and ‘s2’ at (2)".

module mod

private
public sub

   type, public :: t
   end type t

   interface sub
  module procedure s1
  module procedure s2
   end interface sub

contains

   subroutine s1(x)
  type(t) :: x
  ! with integer, gfortran recognises the ambiguity
!  integer :: x
   end subroutine s1

   subroutine s2(x)
  class(*), allocatable :: x
   end subroutine s2

end module mod

[Bug fortran/86115] New: move_alloc for class(*) containing value of type character(len=*) looses data

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86115

Bug ID: 86115
   Summary: move_alloc for class(*) containing value of type
character(len=*) looses data
   Product: gcc
   Version: 8.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: ---

related: bug 72790

Applying move_alloc(x,y) for x and y both declared as class(*) and x currently
containing a string (character(len=...)) fails. The type seems to be
transfered, but the value is empty.

Test case, which shows that for integer variables move_alloc works as expected,
but which fails for strings:

program movealloc

   class(*), allocatable :: x, y, s, t

   allocate(x, source=1234)
   allocate(s, source='5678')

   call p(x)
   call p(y)
   call p(s)
   call p(t)
   call move_alloc(x, y)
   call move_alloc(s, t)
   print *,'---'
   call p(x)
   call p(y)
   call p(s)
   call p(t)


contains

   subroutine p(z)
  class(*), allocatable, intent(in) :: z

  if (allocated(z)) then
 select type(z)
 type is (character(len=*))
print *, 'string: ', z
 type is (integer)
print *, 'integer: ', z
 class default
print *, 'unknown type'
 end select

  else
 print *, 'not allocated'
  end if
   end subroutine p

end program


expected output (confirmed with ifort):
 integer: 1234
 not allocated
 string: 5678
 not allocated
 ---
 not allocated
 integer: 1234
 not allocated
 string: 5678


gfortran output:
 integer: 1234
 not allocated
 string: 5678
 not allocated
 ---
 not allocated
 integer: 1234
 not allocated
 string: 

(not that it does not report 'unknown type')