[Bug fortran/113118] ICE on assignment of derived types with allocatable class component

[baradi09 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Bálint Aradi  ---
Last note: replacing the problematic line with

allocate(item)
item%item = derived_type(name=name, val=val)

seems to compile (but I did not check, whether the compiled code behaves
correctly).

[Bug fortran/113118] ICE on assignment of derived types with allocatable class component

[baradi09 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Bálint Aradi  ---
Just a further note, if I leave away dummy argument names, I do not get an ICE
any more, but the program still does not compile:


   24 | item = base_type_item(derived_type(name, val))
  | 1
Error: Too many components in structure constructor at (1)

Apparently, the fields of the base type are not considered, when the structure
constructor of the derived type is called.

[Bug fortran/113118] New: ICE on assignment of derived types with allocatable class component

[baradi09 at gmail dot com via Gcc-bugs]

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

Bug ID: 113118
   Summary: ICE on assignment of derived types with allocatable
class component
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

I get an internal compiler error with the following demo code. As far, as I can
judge, the code is standard conforming.

module bugdemo
  implicit none

  type :: base_type
character(:), allocatable :: name
  end type base_type

  type :: base_type_item
class(base_type), allocatable :: item
  end type base_type_item

  type, extends(base_type) :: derived_type
integer :: val = 0
  end type derived_type

contains

  function derived_type_as_item(name, val) result(item)
character(*), intent(in) :: name
integer, intent(in) :: val
type(base_type_item), allocatable :: item

item = base_type_item(derived_type(name=name, val=val))

  end function derived_type_as_item

end module bugdemo

Compiling it with

gfortran -c bugdemo.f90

results in

   23 | item = base_type_item(derived_type(name=name, val=val)) 
  |   1 
internal compiler error: in fold_convert_loc, at fold-const.cc:2627 
0x69f6fa fold_convert_loc(unsigned int, tree_node*, tree_node*) 
../.././gcc/fold-const.cc:2627  
0x824e17 gfc_trans_subcomponent_assign 
../.././gcc/fortran/trans-expr.cc:9027 
0x825a22 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool) 
../.././gcc/fortran/trans-expr.cc:9265
0x826808 gfc_conv_structure(gfc_se*, gfc_expr*, int)   
../.././gcc/fortran/trans-expr.cc:9332 
0x81d6fc gfc_conv_expr(gfc_se*, gfc_expr*) 
../.././gcc/fortran/trans-expr.cc:9500 
0x829ab5 gfc_trans_assignment_1
../.././gcc/fortran/trans-expr.cc:11877
0x7e0f77 trans_code
../.././gcc/fortran/trans.cc:2229  
0x80f1e9 gfc_generate_function_code(gfc_namespace*)
../.././gcc/fortran/trans-decl.cc:7715 
0x7e5641 gfc_generate_module_code(gfc_namespace*)  
../.././gcc/fortran/trans.cc:2649  
0x785d35 translate_all_program_units   
../.././gcc/fortran/parse.cc:6707  
0x785d35 gfc_parse_file()  
../.././gcc/fortran/parse.cc:7026  
0x7dde4f gfc_be_parse_file 
../.././gcc/fortran/f95-lang.cc:229
Please submit a full bug report, with preprocessed source. 
Please include the complete backtrace with any bug report. 
See  for instructions.

[Bug fortran/105170] Invalid finalization in intrinsic assignment

[baradi09 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Bálint Aradi  ---
Thanks, with 13.2.0, it seems to behave correctly.

[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types

[baradi09 at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Bálint Aradi  ---
Thanks a lot for fixing it!

[Bug fortran/109358] Wrong formatting with T-descriptor during stream output

[baradi09 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Bálint Aradi  ---
I also think that by allowing for explicit EORs caused by achar(10) characters
in the variable being written or by explicit new_line() calls, the standard
made the formatted stream output probably more complicated then it is worth of.
And the fact that apparently none of the widely used compilers handle those
cases correctly, also indicates over-complication.

However, I still think, that formatted stream output has its justification, as
it allows you to become independent from record length limits, which are set up
when a file is opened and which can not be adapted afterwards. We had been hit
by run-time errors a few times, when the character variable being written
turned out to be too big. (Of course, one could do unformatted stream output
instead, but then one always have to think about adding the newlines manually
at the end of each line...)

[Bug fortran/109358] New: Wrong formatting with T-descriptor during stream output

[baradi09 at gmail dot com via Gcc-bugs]

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

Bug ID: 109358
   Summary: Wrong formatting with T-descriptor during stream
output
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

This is a very minor bug, but probably easy to fix. It seems, that the T data
edit descriptor handling is non-standard conforming when using formatted stream
I/O:

Given the following MWE:

program tabformat
  implicit none

  integer :: fd

  open(newunit=fd, file="test.stream.txt", access="stream", form="formatted")  
  write(fd, "(a)") "1234567890123"
  write(fd, "(a, t10, a)") "1234", "0123"  ! A-descriptor, file positioning
allowed 
  write(fd, "(i4, t10, i4.4)") 1234, 0123  !  I-descriptor, file positioning
not allowed   
  close(fd)

end program tabformat

The resulting file contains

1234567890123
1234 0123   # 9 spaces between blocks
1234 0123   # 9 spaces between blocks

Apparently, a file positioning takes place during the execution of the write
statement. 

However, if I understand 13.7.1 §1 correctly, file positioning may only happen
with the A-descriptor (and it is optional even there). So the standard
conforming output would be either (if file positioning happens after the
A-descriptor)

1234567890123
1234 0123# 9 spaces
1234 0123# 5 spaces

or (if no file positioning happens after the A-descriptor)

1234567890123
1234 0123# 5 spaces
1234 0123# 5 spaces

I personally would prefer latter, and it would be also equivalent to the
behavior of the Intel and NAG compilers.

[Bug fortran/107362] Internal compiler error for recursive class

[baradi09 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Bálint Aradi  ---
> I'm getting the same issue on a recursive tree structure, I will post my
> testcase here instead of opening a new bug. 

I am not sure, whether the two bugs are identical. If I understand correctly,
you can compile the code and obtain the segfault during execution. In the case
demonstrated above, the compiler itself generates an ICE during the
compilation, so no executable code is generated at all. (I have changed the
title of the bug report to pronounce that more.)

[Bug fortran/107362] New: Segfault for recursive class

[baradi09 at gmail dot com via Gcc-bugs]

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

Bug ID: 107362
   Summary: Segfault for recursive class
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

When trying to build Fortuno (https://github.com/aradi/fortuno), our new
Fortran unit testing system, I encounter a segfault with GFortran. The problem
can be reduced to the following MWE:

[details: failureinfo.f90]
module fortuno_failureinfo
  implicit none

  type :: failure_info
class(failure_info), allocatable :: previous
  end type failure_info

end module fortuno_failureinfo
[/details]

> gfortran -freport-bug -c failureinfo.f90 
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report, with preprocessed source.
See 
for instructions.

Apparently, the problem is the "class(failure_info)" field within the derived
type. Turning it into "type(failure_info)" allows compilation.

I use GNU Fortran (conda-forge gcc 12.2.0-18) 12.2.0 on x86_64/Linux.

Thanks a lot for having a look at it in advance!

[Bug fortran/106507] New: Invalid structure constructor for extending derive type

[baradi09 at gmail dot com via Gcc-bugs]

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

Bug ID: 106507
   Summary: Invalid structure constructor for extending derive
type
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

The following snippet triggers a compilation error

test.f90:17:25:

   17 | inst = type2("test", 1)
  | 1
Error: Too many components in structure constructor at (1)

when compiled with

gfortran -c test.f90

although being standard compliant. The problem seems to be the deferred length
character component. If the component is changed to fixed length (but still has
the allocatable attribute), the compiler happily compiles it.

--> test.f90 <--
module mod2
  implicit none

  type :: type1
character(:), allocatable :: name
  end type type1

  type, extends(type1) :: type2
integer :: data
  end type

contains

  subroutine mysub()

type(type2) :: inst
inst = type2("test", 1)

  end subroutine mysub

end module mod2

[Bug fortran/105170] New: Invalid finalization in intrinsic assignment

[baradi09 at gmail dot com via Gcc-bugs]

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

Bug ID: 105170
   Summary: Invalid finalization in intrinsic assignment
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

Created attachment 52754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52754=edit
Minimal working example demonstrating the bug

I have a derived type (TWrapper), which has a component with defined
assignment. The containing derived type itself has no defined assignment. Upon
an assignment between two TWrapper instances, a copy of the RHS seems to get
finalized.

The attached MWE demonstrates the problem.

Expected output (as delivered by current Intel and NAG compilers):

RefCounter_final, id:0
TRefCounter_init: id:42
-> Assignment wrapper2 = wrapper
TRefCounter_final, id:0
TRefCounter_final, id:0
TRefCounter_assign: this%id, other%id: 0 42

GFortran output:

TRefCounter_final, id:0
TRefCounter_init: id:42
-> Assignment wrapper2 = wrapper
TRefCounter_final, id:42
TRefCounter_assign: this%id, other%id: 0 42

One finalization seems to be missing. Additionally, the finalized instance
seems to be a copy of the RHS. (A copy, because after the finalization, the RHS
still seems to have kept its id-value...)

[Bug fortran/104036] New: Derived type assigment to allocatable with dynamic type

[baradi09 at gmail dot com via Gcc-bugs]

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

Bug ID: 104036
   Summary: Derived type assigment to allocatable with dynamic
type
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

Created attachment 52196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52196=edit
Demonstration code

Dear developers,

the behaviour of the GNU compiler is probably not standard conforming, when
assigning a derived type without user defined assignment, which contains a
derived type component with user defined assignment, to an allocatable variable
with dynamic type.

Some discussion about the topic can be found here:

https://fortran-lang.discourse.group/t/intrinsic-assigment-of-derived-types-containing-components-with-user-defined-assignment/2595

I have also attached the demonstration program, where I would expect the user
defined assignment be triggered when line 41 is executed, which does not
happen. (On line 39 it does, as expected.)

Best regards,

Bálint

[Bug fortran/103434] New: Pointer subobject does not show to correct memory location

[baradi09 at gmail dot com via Gcc-bugs]

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

Bug ID: 103434
   Summary: Pointer subobject does not show to correct memory
location
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

Based on the discussion on FD
(https://fortran-lang.discourse.group/t/is-the-section-of-a-pointer-to-an-array-a-valid-pointer/2331),
I'd assume, that the following code is standard conforming. However, the result
with gfortran seems to be incorrect.

*** Code:

module test
  implicit none

  type :: pointer_wrapper
real, pointer :: ptr(:) => null()
  end type pointer_wrapper

contains

  subroutine store_pointer(wrapper, ptr)
type(pointer_wrapper), intent(out) :: wrapper
real, pointer, intent(in) :: ptr(:)
wrapper%ptr => ptr
  end subroutine store_pointer


  subroutine use_pointer(wrapper)
type(pointer_wrapper), intent(inout) :: wrapper
wrapper%ptr(:) = wrapper%ptr + 1.0
  end subroutine use_pointer

end module test


program testprog
  use test
  implicit none

  real, allocatable, target :: data(:,:)
  real, pointer :: ptr(:,:)

  type(pointer_wrapper) :: wrapper
  integer :: ii

  allocate(data(4, 2))
  ptr => data(:,:)
  data(:,:) = 0.0
  do ii = 1, size(data, dim=2)
print *, "#", ii
print *, "BEFORE ", ii, maxval(ptr(:,ii))
call store_pointer(wrapper, ptr(:,ii))
print *, "BETWEEN", ii, maxval(ptr(:,ii))
call use_pointer(wrapper)
print *, "AFTER  ", ii, maxval(ptr(:,ii))
  end do

end program testprog

*** Output:

 #   1
 BEFORE1   0.
 BETWEEN   1   0.
 AFTER 1   1.
 #   2
 BEFORE2   1.
 BETWEEN   2   1.
 AFTER 2   1.

*** Expected output:

 #   1
 BEFORE1   0.
 BETWEEN   1   0.
 AFTER 1   1.
 #   2
 BEFORE2   0.
 BETWEEN   2   0.
 AFTER 2   1.

It seems, as if store_pointer would point to a memory location larger as it
should be, so that also data outside of the actual stride is modified. Intel
and NAG deliver the expected output.

[Bug fortran/103418] New: random_number() does not accept pointer, intent(in) array argument

[baradi09 at gmail dot com via Gcc-bugs]

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

Bug ID: 103418
   Summary: random_number() does not accept pointer, intent(in)
array argument
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

The following module is, at least according to the discussion on
fortran-lang.discourse
(https://fortran-lang.discourse.group/t/meaning-of-the-intent-for-pointer-dummy-arguments/2328/11)
is standard complying, but gfortran stops with an error message when compiling
it. Someone in that topic also posted a gcc-patch, which may fix the issue.

Code:

module m
contains
   subroutine s1(a)
  real, pointer, intent(in) :: a
  call s2(a )   !<-- Ok with gfortran
  call random_number(a) !<-- but not this
   end subroutine
   subroutine s2(x)
  real, intent(out) :: x
  call random_number(x)
   end subroutine
end module

Error message:

bug3.f90:6:25:

6 |   call random_number(a) !<-- but not this
  | 1
Error: ‘harvest’ argument of ‘random_number’ intrinsic at (1) cannot be
INTENT(IN)