Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

how to report compiler bugs

Martin1
New Contributor I
1,953 Views

I just tried oneAPI, came across two compiler bugs and thought I might report those. But where?

"Request support" in the support center is the wrong place to go, as I do not seek any support. Nevertheless I tried, but as I do not have any support contract, the two tickets I opened were immediately closed.

Is intel interested in bug reports at all? And if yes, how should bugs be reported?

 

1 Solution
Ron_Green
Moderator
1,937 Views

Customers with active support contracts use the Online Service Center to enter bug reports.

Without active support you can post bug reports here on this Forum.  We'd like to see them and can grab it from here and put it into our bug tracking system.

View solution in original post

7 Replies
Martin1
New Contributor I
1,946 Views

After searching recent posts, I found that the forum is now used as bug tracking tool.

 

0 Kudos
Ron_Green
Moderator
1,938 Views

Customers with active support contracts use the Online Service Center to enter bug reports.

Without active support you can post bug reports here on this Forum.  We'd like to see them and can grab it from here and put it into our bug tracking system.

accowa
Beginner
1,141 Views
Bug report: 
Array  shape checking fails to detect runtime errors in all but the simplest assignment cases. Any operations on the RHS seem to disable checking even though the operations are returning mis-matched arrays. All these demonstator cases are detected correctly by gfortran with the -bounds-check option. Failure to detect these errors slows down development and discourages use of the intel compiler.
 

I've tried reporting this through an active support contract but having to go through our IT department may lose something in translation. Here are the details and a working demonstrator:

ifort -V
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.4.0 Build 20210910_000000
Copyright (C) 1985-2021 Intel Corporation. All rights reserved.
(and earlier releases)
 
Demonstration:
 
ifort -o trya2d_c -check shape trya2d_c.f90
./trya2d_c
 
  SHAPE(htau) 100 100
  L/UBOUND(htau) 2 2 101 101
  SHAPE(gphit) 102 102
  L/UBOUND(gphit) 1 1 102 102
This line is not detected as a shape mismatch even with -check shape at compilation:
htau(:,:) = MAX( 0.5, MIN( 30., 45.* ABS( SIN( 3.142/180. * gphit(:,:) ) ) ))
Even though the shapes do not match:
  100 100 102 102
  Note: this error is detected correctly by gfortran with -bounds-check
 
In fact, a simple operation with the RHS prevents shape checking:
 A: htau(:,:) = 1.0 * gphit(:,:) 102 102
 B: htau(:,) = gphit(:,:) * 1.0 102 102
 
Only a simple assignment is trapped correctly:
 C: htau(:,:) = gphit(:,:) 102 102
forrtl: severe (408): fort: (33): Shape mismatch: The extent of dimension 2 of array HTAU is 100 and the corresponding extent of array GPHIT is 102
 
Image PC Routine Line Source
trya2d_c 0000000000406F8F Unknown Unknown Unknown
trya2d_c 0000000000404370 Unknown Unknown Unknown
trya2d_c 0000000000403852 Unknown Unknown Unknown
libc-2.17.so 00002ADBAFD7E555 __libc_start_main Unknown Unknown
trya2d_c 0000000000403769 Unknown Unknown Unknown
Demonstrator program:
 
cat trya2d_c.f90
REAL, ALLOCATABLE, DIMENSION(:,:) :: htau, gphit
ALLOCATE(htau(2:101,2:101), gphit(102,102))
WRITE(*,*) ' SHAPE(htau)     ', SHAPE(htau)
WRITE(*,*) ' L/UBOUND(htau)  ', LBOUND(htau), UBOUND(htau)
WRITE(*,*) ' SHAPE(gphit)    ', SHAPE(gphit)
WRITE(*,*) ' L/UBOUND(gphit) ', LBOUND(gphit), UBOUND(gphit)
!
write(*,'(a)') 'This line is not detected as a shape mismatch even with -check shape at compilation: '
write(*,'(a)') 'htau(:,:) =  MAX(  0.5, MIN( 30., 45.* ABS( SIN( 3.142/180. * gphit(:,:) ) ) ))'
htau(:,:) =  MAX(  0.5, MIN( 30., 45.* ABS( SIN( 3.142/180. * gphit(:,:) ) ) ))
write(*,'(a)') 'Even though the shapes do not match: '
write(*,*) SHAPE(htau), SHAPE( MAX(  0.5, MIN( 30., 45.* ABS( SIN( 3.142/180. * gphit(:,:) ) ) )))
write(*,'(a)') '  Note: this error is detected correctly by gfortran with -bounds-check '
!
write(*,'(a)') 'In fact, a simple operation with the RHS prevents shape checking: '
write(*,*) 'A: htau(:,:) = 1.0 * gphit(:,:) ', SHAPE(1.0 * gphit(:,:))
htau(:,:) =   1.0 * gphit(:,:)
!
write(*,*) 'B: htau(:,) = gphit(:,:)  * 1.0 ',SHAPE(gphit(:,:)  * 1.0)
htau(:,:) =   gphit(:,:)  * 1.0
!
write(*,'(a)') 'Only a simple assignment is trapped correctly: '
write(*,*) 'C: htau(:,:) = gphit(:,:) ',SHAPE(gphit(:,:))
htau(:,:) =   gphit(:,:)
!
write(*,*) 'D'
end
0 Kudos
ndd21
Novice
580 Views

Hello, I've just encountered this problem in a Fortran+OpenMP program:

 

laptop3:~> cat t.f90
PROGRAM t
IMPLICIT NONE
INTEGER,PARAMETER :: N=10,M=20
INTEGER :: i
TYPE pwdat_type
REAL,ALLOCATABLE :: r(:)
END TYPE pwdat_type
TYPE(pwdat_type) :: p(N)
REAL :: x(M)

DO i=1,N
ALLOCATE(p(i)%r(M))
p(i)%r=1.23
ENDDO ! i

!$OMP PARALLEL WORKSHARE DEFAULT(none) SHARED(x,p)
x=p(1)%r
!$OMP END PARALLEL WORKSHARE

END PROGRAM t
laptop3:~> ifort --version
ifort (IFORT) 2021.9.0 20230302
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

laptop3:~> ifort -O0 -check bounds -qopenmp t.f90
At least one variable in the private list was not emitted
beblk_t OMP (0x7f5778613c10)
======================================================
shared_list:
(* emitted *) "t_$P$1_V$3f"
(* emitted *) "t_$X_V$3e"
======================================================
private_list:
"var$48_V$6b"
======================================================
t.f90(16): catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
compilation aborted for t.f90 (code 1)

0 Kudos
JNorw
Beginner
1,691 Views

I think this is more of an dpc++ library bug.

dpc++ allows you to create multiple queues on a device.

dpc++ allows you to use depends_on(event1,event2,...) to synchronize execution.

dpc++ accepts events returned from different queues in the depends_on statement, however it appears that depends_on fails to work correctly if the current queue context is not the same as  the queue returning the event.

I'll provide example code modified from the dpc++ book to use multiple queues.  With event.wait() it works as expected.  Attempting to use the commented out depends_on(event) statements fails to execute the kernels.

 

Sorry, I found there was a more appropriate place for this in the dpc++ forum.  Please ignore this.

0 Kudos
Barbara_P_Intel
Moderator
1,687 Views

dpc++ has its own forum for asking questions and posting bugs.  Can you post this there?

 

0 Kudos
Steve_Lionel
Black Belt Retired Employee
566 Views

Please start a new thread, instead of tacking on to an unrelated one from a long time ago. Be sure to choose a meaningful title..

0 Kudos
Reply