[Bug fortran/96325] New: Invalid call of a type-bound procedure is accepted

[chilikin.k at gmail dot com]

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

Bug ID: 96325
   Summary: Invalid call of a type-bound procedure is accepted
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

Created attachment 48928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48928&action=edit
Test case

Attached file contains an invalid call of a "type-bound procedure"

A = T%R1%GET(I)

where T%R1 is not a derived type at all, it is a REAL(REAL64).

With the following compiler:

Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10.2.0/configure --prefix=/opt/gcc-10.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC) 

and compilation command:

$ gfortran -c -o test.o test.f90

the code is accepted. With version 10.1.0, the code is also accepted.
With version 8.3.0, the following error is reported:

test.f90:37:4:

 A = T%R1%GET(I)
1
Error: Unclassifiable statement at (1)

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

[chilikin.k at gmail dot com]

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

--- Comment #2 from Kirill Chilikin  ---
Yes, there is no type-bound procedure really, and, yes, there is a bug in the
code (intentionally: it was called for the wrong variable, which is removed for
the test case). The module M2 indeed does not use anything from M1 (due to
simplification of the real code). And, yes, the gfortran should tell that this
statement is not classifiable - 8.3.0 does this, but 10.2.0 successfully
compiles the code without reporting any error.

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

[chilikin.k at gmail dot com]

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

--- Comment #3 from Kirill Chilikin  ---
I tested the reduced test case. It also compiles successfully with version
10.2.0, while it should not. With 8.3.0, an error is reported:

$ /usr/bin/gfortran -c -o test.o test2.f90
test2.f90:14:9:

  a = t%r1%get(i)
 1
Error: Unclassifiable statement at (1)

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

[chilikin.k at gmail dot com]

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

--- Comment #4 from Kirill Chilikin  ---
Thus, this error (or, more exactly, absence of error) does not depend on the
presence of a type-bound procedure with the same name for another derived type.
The bug description should probably be modified.

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

[chilikin.k at gmail dot com]

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

--- Comment #7 from Kirill Chilikin  ---
Result of git bisect:

$ git bisect log
git bisect start
# bad: [6e6e3f144a33ae504149dc992453b4f6dea12fdb] Update ChangeLog and version
files for release
git bisect bad 6e6e3f144a33ae504149dc992453b4f6dea12fdb
# good: [406c2abec3f998e9064919b22db62f38a7c0e7b9] * gennews (files): Add files
for GCC 8.
git bisect good 406c2abec3f998e9064919b22db62f38a7c0e7b9
# good: [7d75ea04cf6d9c8960d5c6119d6203568b7069e9] re PR c++/85437 (member
pointer static upcast rejected in a constexpr context)
git bisect good 7d75ea04cf6d9c8960d5c6119d6203568b7069e9
# good: [5fae049dc272144f8e61af94ee0ba42b270915e5] OpenACC Profiling Interface
(incomplete)
git bisect good 5fae049dc272144f8e61af94ee0ba42b270915e5
# bad: [271da732841345d3834cf458d47f8242ac5ef513] PR testsuite/92127: Disable
unrolling for some vect code model cases
git bisect bad 271da732841345d3834cf458d47f8242ac5ef513
# good: [4a2e9be1ac7c8f4c37b5deb4ce0b0f39925e56c9] [Ada] New parameter Quiet
for procedure GNAT.Command_Line.Getopt
git bisect good 4a2e9be1ac7c8f4c37b5deb4ce0b0f39925e56c9
# bad: [0968003dd08a9e9f83bee955bbdc259a781f044f] PR c++/91819 - ICE with
operator++ and enum.
git bisect bad 0968003dd08a9e9f83bee955bbdc259a781f044f
# good: [32b1d51f16fe56b34e979fcfba4bc74dbd3592a9] runtime: move osinit to Go
git bisect good 32b1d51f16fe56b34e979fcfba4bc74dbd3592a9
# bad: [a1fc3891ebb77c1bdf68ce70c074eb907d21771a] go/internal/gccgoimporter:
support embedded field in pointer loop
git bisect bad a1fc3891ebb77c1bdf68ce70c074eb907d21771a
# bad: [e7414688f16c4c9db2dacbc31da683887b4ba1bd] re PR middle-end/90501 (ICE:
address taken, but ADDRESSABLE bit not set)
git bisect bad e7414688f16c4c9db2dacbc31da683887b4ba1bd
# good: [a37ab089c22f8be834bb1b5fd4c0454224db9b0f] 2019-09-01  François Dumont 

git bisect good a37ab089c22f8be834bb1b5fd4c0454224db9b0f
# bad: [c6c2d1bc9bc3eb3606af6a198e74170bd906e199] re PR other/79543
(Inappropriate "ld --version" checking)
git bisect bad c6c2d1bc9bc3eb3606af6a198e74170bd906e199
# good: [1525fa83cc704ba18738eb2eab76a7f4d6bfde6b] re PR
tree-optimization/91632 (Probably wrong code since r275026)
git bisect good 1525fa83cc704ba18738eb2eab76a7f4d6bfde6b
# bad: [75f935365dba3eb5e9cbd11bc0d75009cad3d019] [AArch64] Add Linux hwcap
strings for some extensions
git bisect bad 75f935365dba3eb5e9cbd11bc0d75009cad3d019
# bad: [f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47] re PR fortran/91589 (ICE in
gfc_conv_component_ref, at fortran/trans-expr.c:2447)
git bisect bad f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47
# good: [be0fb5484a64414878c31a1606b07175b54ecb90] re PR fortran/91552 (ICE
with valid array constructor)
git bisect good be0fb5484a64414878c31a1606b07175b54ecb90
# first bad commit: [f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47] re PR
fortran/91589 (ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2447)

f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47 is the first bad commit
commit f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47
Author: Paul Thomas 
Date:   Mon Sep 2 19:54:02 2019 +

re PR fortran/91589 (ICE in gfc_conv_component_ref, at
fortran/trans-expr.c:2447)

2019-09-02  Paul Thomas  

PR fortran/91589
* primary.c (gfc_match_varspec): Return MATCH_NO on an apparent
component ref, when the primary type is intrinsic.

2019-09-02  Paul Thomas  

PR fortran/91589
* gfortran.dg/pr91589.f90 : New test.

From-SVN: r275324

[Bug fortran/96423] New: It is not checked whether module procedures have separate interface bodies.

[chilikin.k at gmail dot com]

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

Bug ID: 96423
   Summary: It is not checked whether module procedures have
separate interface bodies.
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

The following code:

MODULE M
CONTAINS
  MODULE SUBROUTINE S()
  END SUBROUTINE
END MODULE

compiles successfully with gfortran 10.2.0. However, it should not compile, as
S() is a separate module procedure and it should have a separate interface
body.

Compiler configuration:

Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10.2.0/configure --prefix=/opt/gcc-10.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC) 

Compilation command:

$ gfortran -c -o test.o test.f90

[Bug fortran/54370] New: error: non-trivial conversion in unary operation

[chilikin.k at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54370

 Bug #: 54370
   Summary: error: non-trivial conversion in unary operation
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: chiliki...@gmail.com


The following:

  MODULE M
  CONTAINS

  LOGICAL(C_BOOL) FUNCTION L() BIND(C)
  USE, INTRINSIC :: ISO_C_BINDING
  L = .FALSE.
  END FUNCTION

  SUBROUTINE S()
  DO WHILE (L())
  ENDDO
  END

  END

(also in attached file)

Results in:

$ gfortran -c test.f08 
test.f08: In function 's':  
test.f08:10:0: error: non-trivial conversion in unary operation 
logical(kind=4) 
logical(kind=1)
D.1858 = ~D.1857;

test.f08:10: confused by earlier errors, bailing out

With compiler:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.7.0/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/opt/gcc-4.7.0/
Thread model: posix
gcc version 4.7.0 (GCC) 

The same error appears in version 4.7.1.

Compilation works in version 4.6.3 without any errors.

[Bug fortran/54370] error: non-trivial conversion in unary operation

[chilikin.k at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54370

--- Comment #1 from Kirill Chilikin  2012-08-24 
21:51:19 UTC ---
Created attachment 28080
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28080
testcase

[Bug fortran/70006] New: Duplicate errors "label not defined"

[chilikin.k at gmail dot com]

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

Bug ID: 70006
   Summary: Duplicate errors "label not defined"
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

Created attachment 37815
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37815&action=edit
Test program

Compilation of the following program (attached)

$ cat test.f
  PROGRAM TEST
  PRINT 1, 'STRING 1'
  PRINT 1, 'STRING 2'
!1 FORMAT(A)
  GOTO 2 ! LINE 5
  GOTO 2 ! LINE 6
!2 CONTINUE
  END PROGRAM

results in duplicate error messages instead of two different errors for each of
two labels:

$ gfortran -o test test.f
test.f:3:13:

   PRINT 1, 'STRING 2'
 1
Error: FORMAT label 1 at (1) not defined
test.f:3:13:

   PRINT 1, 'STRING 2'
 1
Error: FORMAT label 1 at (1) not defined
test.f:6:72: Error: Label 2 referenced at (1) is never defined
test.f:6:72: Error: Label 2 referenced at (1) is never defined

Compiler version:

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-5.3/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure --prefix=/opt/gcc-5.3
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 5.3.0 (GCC) 

Error messages with gcc 4.9.2:

$ /usr/bin/gfortran -o test test.f
test.f:3.13:

  PRINT 1, 'STRING 2'   
 1
Error: FORMAT label 1 at (1) not defined
test.f:3.13:

  PRINT 1, 'STRING 2'   
 1
Error: FORMAT label 1 at (1) not defined
test.f:6.72:

  GOTO 2 ! LINE 6   
1
Error: Label 2 referenced at (1) is never defined
test.f:6.72:

  GOTO 2 ! LINE 6   
1
Error: Label 2 referenced at (1) is never defined

[Bug rtl-optimization/48757] New: internal compiler error: in compensate_edge, at reg-stack.c:2788

[chilikin.k at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48757

   Summary: internal compiler error: in compensate_edge, at
reg-stack.c:2788
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: chiliki...@gmail.com


Created attachment 24093
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24093
fconc64.f (from CERNLIB / MATHLIB, simplified)

Version of compiler: 4.6.0
The same problem exists in version 4.5.2

System type and configuration of the compiler:
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/opt/gcc-4.6.0/
Thread model: posix

Triggering the bug (fconc64.f is attached file):
gfortran -c -O2 fconc64.f
The bug does not occur without optimization flag -O2

Compiler output:
fconc64.f:18.72:

  ASSIGN 1 TO JP
1
Warning: Deleted feature: ASSIGN statement at (1)
fconc64.f:20.72:

1 ASSIGN 2 TO JP
1
Warning: Deleted feature: ASSIGN statement at (1)
fconc64.f:24.72:

   12 ASSIGN 3 TO JP
1
Warning: Deleted feature: ASSIGN statement at (1)
fconc64.f:28.72:

   13 ASSIGN 4 TO JP
1
Warning: Deleted feature: ASSIGN statement at (1)
fconc64.f:36.38:

   IF(ABS(R-RR) .LT. EPS) GO TO JP, (1,2,3,4)   
  1
Warning: Deleted feature: Assigned GOTO statement at (1)
fconc64.f:43.38:

   IF(ABS(R-RR) .LT. EPS) GO TO JP, (1,2,3,4)   
  1
Warning: Deleted feature: Assigned GOTO statement at (1)
fconc64.f: In function 'dfconc':
fconc64.f:52:0: internal compiler error: in compensate_edge, at
reg-stack.c:2788
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/105501] New: The statement TYPE IS without a space is accepted

[chilikin.k at gmail dot com via Gcc-bugs]

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

Bug ID: 105501
   Summary: The statement TYPE IS without a space is accepted
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

The following module

MODULE M
  TYPE T
INTEGER I
  END TYPE
CONTAINS
  SUBROUTINE S(X)
CLASS(T), POINTER :: X
SELECT TYPE (X)
  TYPEIS (T)
PRINT *, 'T'
END SELECT
  END SUBROUTINE
END MODULE

compiles without any messages with gfortran 11.3.0:

$ gfortran -c -std=f2018 -pedantic test.f90

(there are no warnings)

However, "TYPEIS" requires one or more blank characters between "TYPE" and "IS"
in accordance with the section "Blank characters in free form" of the standard
as it is not included in the list of exceptions with optional blanks.

For comparison, the output of flang 14.0.3 is:

$ flang -c -std=f2018 test.f90
test.f90:9:12: missing space
TYPEIS (T)
 ^
test.f90:9:7: in the context: type guard statement
TYPEIS (T)
^
test.f90:8:5: in the context: SELECT TYPE construct
  SELECT TYPE (X)
  ^
test.f90:8:5: in the context: execution part construct
  SELECT TYPE (X)
  ^
test.f90:8:5: in the context: execution part
  SELECT TYPE (X)
  ^
test.f90:6:3: in the context: SUBROUTINE subprogram
SUBROUTINE S(X)
^
test.f90:5:1: in the context: module subprogram part
  CONTAINS
  ^
test.f90:1:1: in the context: module
  MODULE M
  ^

[Bug fortran/110987] New: Segmentation fault after finalization of a temporary variable

[chilikin.k at gmail dot com via Gcc-bugs]

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

Bug ID: 110987
   Summary: Segmentation fault after finalization of a temporary
variable
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

Created attachment 55720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55720&action=edit
Test case

The attached test program works fine with gfortran 12.2.0 and crashes with
a segmentation fault when compiled with gfortran 13.2.0. The compilation
command is

gfortran -g -o test test.f90

The segmentation fault happens when the function T1_GET_NEXT() tries to access
SELF%NEXT(1)%T1, which is deallocated and overwritten:

$ valgrind ./test

==1651009== Invalid read of size 8
==1651009==at 0x40251D: __test_module_MOD_t1_get_next (in test)
==1651009==by 0x403678: MAIN__ (in test)
==1651009==by 0x4036D0: main (in test)
==1651009==  Address 0x4e92d48 is 8 bytes inside a block of size 16 free'd
==1651009==at 0x48399AB: free (vg_replace_malloc.c:538)
==1651009==by 0x402876: __test_module_MOD_t1_destructor (in test)
==1651009==by 0x401812: __test_module_MOD___final_test_module_T1 (in test)
==1651009==by 0x4035CF: MAIN__ (in test)
==1651009==by 0x4036D0: main (in test)
==1651009==  Block was alloc'd at
==1651009==at 0x483877F: malloc (vg_replace_malloc.c:307)
==1651009==by 0x4026AF: __test_module_MOD_t1_set_n_next (in test)
==1651009==by 0x402466: __test_module_MOD_t2_constructor (in test)
==1651009==by 0x402E93: MAIN__ (in test)
==1651009==by 0x4036D0: main (in test)

The corresponding part of the output of

$ objdump -S ./test | less

is attached. The final-subroutine call which incorrectly deallocates memory
happens at 4035cd, between the calls of __test_module_MOD_t3_constructor and
__test_module_MOD_t1_set_n_next. Thus, the finalization seems to happen for
the temporary variable allocated as the result of T3() call, which is assigned
then to X3, and the memory corresponding to

CLASS(T1_POINTER), ALLOCATABLE :: NEXT(:)

is probably the same for that temporary variable and X3 (in contradiction with
10.2.1.3.13 item (2) of Fortran 2018?).

May be related to the fix of bug 80524.

[Bug fortran/110987] Segmentation fault after finalization of a temporary variable

[chilikin.k at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Kirill Chilikin  ---
Created attachment 55721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55721&action=edit
Objdump of the corresponding code

[Bug fortran/110987] Segmentation fault after finalization of a temporary variable

[chilikin.k at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Kirill Chilikin  ---
Some additional information:

$ gfortran -g -o test test.f90 -fdump-tree-original
$ cat test.f90.005t.original | head -n 747 | tail -n 26
  {
struct t3 zero.25;
struct array00_t3 desc.26;
struct t3 D.4638;

desc.26.dtype = {.elem_len=80, .rank=0, .type=5};
desc.26.data = (void * restrict) &zero.25;
desc.26.span = (integer(kind=8)) desc.26.dtype.elem_len;
{
  struct array00_t3 desc.27;

  desc.27.dtype = {.elem_len=80, .rank=0, .type=5};
  desc.27.data = (void * restrict) &x3;
  desc.27.span = (integer(kind=8)) desc.27.dtype.elem_len;
  __final_test_module_T1 (&desc.27, 80, 0);
} 
D.4638 = x3;
x3 = (struct t3) t3_constructor ();
if ((struct t1_pointer[0:] * restrict) D.4638.t1.next._data.data != 0B)
  {
__builtin_free ((void *) D.4638.t1.next._data.data);
(struct t1_pointer[0:] * restrict) D.4638.t1.next._data.data = 0B;
  }
D.4638.t1.next._vptr = (struct __vtype_test_module_T1_pointer * {ref-all})
&__vtab_test_module_T1_pointer;
__vtab_test_module_T3._final (&desc.26, __vtab_test_module_T3._size, 0);
  }

The call of __vtab_test_module_T3._final is on desc.26 pointing to otherwise
unused zero.25.

$ gdb ./test
(gdb) b 102
Breakpoint 1 at 0x4033ca: file test.f90, line 102.
(gdb) r
Breakpoint 1, test_program () at test.f90:102
102   X3 = T3()
(gdb) p x2
$1 = ( t1 = ( n_next = 1, next = ( _data = (( t1 = ( _data = 0x4062a0 ,
_vptr = 0x406140 <__test_module_MOD___vtab_test_module_T1> ) )), _vptr =
0x4061a0 <__test_module_MOD___vtab_test_module_T1_pointer> ) ), x =
1.40129846e-45 )
(gdb) b t1_destructor
Breakpoint 2 at 0x4027f0: file test.f90, line 49.
(gdb) ignore 2 3
Will ignore next 3 crossings of breakpoint 2.
(gdb) c
Breakpoint 2, test_module::t1_destructor (self=...) at test.f90:49
49  IF (ALLOCATED(SELF%NEXT)) THEN
(gdb) backtrace
#0  test_module::t1_destructor (self=...) at test.f90:49
#1  0x00401813 in test_module::__final_test_module_T1 (array=...,
byte_stride=80, fini_coarray=.FALSE.) at test.f90:90
#2  0x004035d0 in test_program () at test.f90:102
(gdb) p self
$2 = ( n_next = 1, next = ( _data = (( t1 = ( _data = 0x4062a0 , _vptr =
0x406140 <__test_module_MOD___vtab_test_module_T1> ) )), _vptr = 0x4061a0
<__test_module_MOD___vtab_test_module_T1_pointer> ) )

But in the compiled program, it seems to finalize X2%T1.

[Bug fortran/116705] New: Incorrect error in omp target teams distribute parallel do

[chilikin.k at gmail dot com via Gcc-bugs]

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

Bug ID: 116705
   Summary: Incorrect error in omp target teams distribute
parallel do
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

With gfortran 14.2.0,

$ cat test.f90 
SUBROUTINE S
  USE, INTRINSIC :: ISO_C_BINDING
  USE, INTRINSIC :: ISO_FORTRAN_ENV
  IMPLICIT NONE
  INTEGER, PARAMETER :: N = 100
  REAL(REAL64), DIMENSION(N) :: A, B, C
  TYPE(C_PTR) PTR
  INTEGER I
  !$OMP TARGET TEAMS DISTRIBUTE PARALLEL DO IS_DEVICE_PTR(PTR)
  DO I = 1, N
A(I) = B(I) + C(I)
  ENDDO
END SUBROUTINE
$ gfortran -c test.f90 -fopenmp
test.f90:9:58:

9 |   !$OMP TARGET TEAMS DISTRIBUTE PARALLEL DO IS_DEVICE_PTR(PTR)
  |  1
Error: List item 'ptr' in IS_DEVICE_PTR clause at (1) must be of TYPE(C_PTR)

The error is incorrect: the argument "PTR" is indeed of the type TYPE(C_PTR).
Similar example with just "omp target" works:

SUBROUTINE S
  USE, INTRINSIC :: ISO_C_BINDING
  USE, INTRINSIC :: ISO_FORTRAN_ENV
  IMPLICIT NONE
  INTEGER, PARAMETER :: N = 100
  REAL(REAL64), DIMENSION(N) :: A, B, C
  TYPE(C_PTR) PTR
  INTEGER I
  !$OMP TARGET IS_DEVICE_PTR(PTR)
  DO I = 1, N
A(I) = B(I) + C(I)
  ENDDO
  !$OMP END TARGET
END SUBROUTINE

[Bug fortran/95397] [Fortran/OpenACC] Wrong results with 'loop vector' inside 'routine'

[chilikin.k at gmail dot com via Gcc-bugs]

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

Kirill Chilikin  changed:

   What|Removed |Added

 CC||chilikin.k at gmail dot com

--- Comment #4 from Kirill Chilikin  ---
I found another case of incorrect results depending on the presence of the "acc
loop vector" directive (and the original example also fails):

$ cat test1.f90 
PROGRAM TEST
  USE, INTRINSIC :: ISO_FORTRAN_ENV
  IMPLICIT NONE
  INTEGER, PARAMETER :: N1 = 32
  INTEGER, PARAMETER :: N2 = 32
  REAL(REAL64), DIMENSION(N1, N2) :: A
  INTEGER I1, I2
  !$ACC PARALLEL COPYOUT(A)
  !$ACC LOOP WORKER
  DO I2 = 1, N2
BLOCK
  REAL(REAL64), DIMENSION(N1) :: V
  !$ACC LOOP VECTOR
  DO I1 = 1, N1
V(I1) = REAL(I1)
  ENDDO
  !$ACC LOOP VECTOR
  DO I1 = 1, N1
A(I1,I2) = V(I1)
  ENDDO
END BLOCK
  ENDDO
  !$ACC END PARALLEL
  PRINT *, A(:, 1)
END PROGRAM

$ gfortran -o test1 test1.f90 -fopenacc -foffload=nvptx-none
-foffload-options="-misa=sm_35"
chilikin@comp1:/mnt/raid/chilikin/binp/belle2/analysis_physics/psipik/externals/test_offloading/vectorization$
./test1 
   1.0.0.  
 0.0.0.   
0.0.0.   
0.0.0.   
0.0.0.   
0.0.0.   
0.0.0.   
0.0.0.   
0.0.0.   
0.0.0.   
0.0. 

If the first "acc loop vector" directive is removed (test2.f90), then

$ gfortran -o test2 test2.f90 -fopenacc -foffload=nvptx-none
-foffload-options="-misa=sm_35"
$ ./test2
   1.2.3.  
 4.5.6.   
7.8.9.   
10.00011.00012.000   
13.00014.00015.000   
16.00017.00018.000   
19.00020.00021.000   
22.00023.00024.000   
25.00026.00027.000   
28.00029.00030.000   
31.00032.000 

GPU is Nvidia GeForce GT 710, compiler is
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/path/offloading/libexec/gcc/x86_64-pc-linux-gnu/14.2.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /source_path/gcc-14.2.0/configure --prefix=/path/offloading
--with-gmp=/path --with-mpfr=/path --with-mpc=/path --with-isl=/path
--disable-multilib --enable-offload-targets=nvptx-none
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.0 (GCC)

[Bug fortran/95397] [Fortran/OpenACC] Wrong results with 'loop vector' inside 'routine'

[chilikin.k at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Kirill Chilikin  ---
Created attachment 59111
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59111&action=edit
Test case

[Bug fortran/95397] [Fortran/OpenACC] Wrong results with 'loop vector' inside 'routine'

[chilikin.k at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Kirill Chilikin  ---
Created attachment 59112
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59112&action=edit
Test case (works)

[Bug fortran/110987] Segmentation fault after finalization of a temporary variable

[chilikin.k at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Kirill Chilikin  ---
The derived type T3 has zero components but not zero length as it extends T1;
the test does not crash after the following changes:

diff --git a/gcc/fortran/trans.cc b/gcc/fortran/trans.cc
index 961b0b5a573..e5d12f25e5e 100644
--- a/gcc/fortran/trans.cc
+++ b/gcc/fortran/trans.cc
@@ -1624,7 +1624,7 @@ gfc_finalize_tree_expr (gfc_se *se, gfc_symbol *derived,
 }
   else if (derived && gfc_is_finalizable (derived, NULL))
 {
-  if (derived->attr.zero_comp && !rank)
+  if ((derived->components == NULL) && !rank)
{
  /* Any attempt to assign zero length entities, causes the gimplifier
 all manner of problems. Instead, a variable is created to act as
@@ -1685,7 +1685,7 @@ gfc_finalize_tree_expr (gfc_se *se, gfc_symbol *derived,
}
 }

-  if (derived && derived->attr.zero_comp)
+  if (derived && (derived->components == NULL))
 {
   /* All the conditions below break down for zero length derived types. 
*/
   tmp = build_call_expr_loc (input_location, final_fndecl, 3,

[Bug lto/117303] New: Link-time optimization optimizes away subroutine referred to via C_FUNLOC

[chilikin.k at gmail dot com via Gcc-bugs]

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

Bug ID: 117303
   Summary: Link-time optimization optimizes away subroutine
referred to via C_FUNLOC
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

Created attachment 59440
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59440&action=edit
test.f90

With gfortran 14.2.0, the following program:

$ cat test.f90 
MODULE M1
  USE, INTRINSIC :: ISO_C_BINDING
  TYPE T
TYPE(C_FUNPTR) FUNPTR
  END TYPE
  TYPE(T), POINTER :: T_POINTER
CONTAINS
  SUBROUTINE SET_FUNPTR(F)
TYPE(C_FUNPTR), INTENT(IN) :: F
T_POINTER%FUNPTR = F
  END SUBROUTINE
  SUBROUTINE S1() BIND(C)
  END SUBROUTINE
END MODULE

PROGRAM TEST
  USE M1
  ALLOCATE(T_POINTER)
  CALL SET_FUNPTR(C_FUNLOC(S1))
  PRINT *, T_POINTER%FUNPTR
END PROGRAM

works if it is compiled without link-time optimization:

$ gfortran -O1 -o test test.f90
$ ./test 
  4198811

but with link-time optimization, there is a linker error:

$ gfortran -O1 -flto -o test test.f90
ld: /tmp/ccL2ip3g.ltrans0.ltrans.o: in function `MAIN__':
:(.text+0x21): undefined reference to `s1'
collect2: error: ld returned 1 exit status

[Bug rtl-optimization/116875] New: Internal compiler error: in make_decl_rtl, at varasm.cc:1443

[chilikin.k at gmail dot com via Gcc-bugs]

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

Bug ID: 116875
   Summary: Internal compiler error: in make_decl_rtl, at
varasm.cc:1443
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

Created attachment 59217
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59217&action=edit
test.f90

With gfortran 14.1.0:

$ cat test.f90 

MODULE M1
  IMPLICIT NONE

  ABSTRACT INTERFACE
SUBROUTINE S1()
END SUBROUTINE
  END INTERFACE

END MODULE
$ cat test2.f90 

MODULE M2
  USE M1

CONTAINS

  SUBROUTINE CALL_S1(S1_POINTER)
PROCEDURE(S1), POINTER :: S1_POINTER
CALL S1_POINTER()
  END SUBROUTINE

  SUBROUTINE S2()
BLOCK
  PROCEDURE(S1), POINTER :: S1_POINTER
  CALL CALL_S1(S1_POINTER)
END BLOCK
  END SUBROUTINE

END MODULE
$ gfortran -c test.f90
$ gfortran -c test2.f90
during RTL pass: expand
test2.f90:15:30:

   15 |   CALL CALL_S1(S1_POINTER)
  |  ^
internal compiler error: in make_decl_rtl, at varasm.cc:1443
0x7f257a0ab249 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f257a0ab304 __libc_start_main_impl
../csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug rtl-optimization/116875] Internal compiler error: in make_decl_rtl, at varasm.cc:1443

[chilikin.k at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Kirill Chilikin  ---
Created attachment 59218
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59218&action=edit
test2.f90