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

Allocatable array: Not fixed in the major release as promised?

abhimodak
New Contributor I
479 Views

Hi

I believe that issue # 46180 is NOT fixed in 11.0.61. I had submitted this compiler bug to premier support with reference T82642-CP as suggested by Steve Lionel.

We had been told in March 2008 that this is fixed internally and will be available in "next" major release. We were using 10.0.025 that time and it looks like this bug is there in 11.0.061.

The build log with 11.0.061 is

1>------ Rebuild All started: Project: Test_Allocate, Configuration: Release Win32 ------
1>Deleting intermediate files and output files for project 'Test_Allocate', configuration 'Release|Win32'.
1>Compiling with Intel Fortran 11.0.061 [IA-32]...
1>Test_Allocate.f90
1>Linking...
1>Embedding manifest...
1>
1>Build log written to "file://C:\Abhi\MySource\Tests\Test_Allocate\Release\BuildLog.htm"
1>Test_Allocate - 0 error(s), 0 warning(s)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

See the source code below. I get the same values as before.

Abhi

===============================
Program Test_Allocate
!
! Purpose: Check Allocation.
!
Implicit None
!
Integer, Parameter :: DOUBLE = kind(1.0d0)
Real(DOUBLE), Allocatable :: A(:), B(:), C(:)
!
Integer :: n, ial, idal
!
!###################
!
DeAllocate(A, stat=idal)
print *, idal ! ... [1]

Allocate(A(10), stat=ial)
print *, ial, Size(A) ! ... [2]

Allocate(A(20), stat=ial)
print *, ial, Size(A) ! ... [3]

A(16) = 1.0d0
Print *, A(16) ! ... [4]
!
End Program Test_Allocate
-------------------------------------------------------------------
In the "release" build, the output produced by Intel Fortran 10.0.25 with VS2005 is:
[1] => 153
[2] => 0, 10
[3] => 151, 20
[4] => 1.00000000000

In the debug build, there is warning indicating heap corruption but one can continue.

0 Kudos
1 Solution
Steven_L_Intel1
Employee
479 Views

Interesting. When I try it with 11.0.061 it works:

c:Projects>ifort a2.f90
Intel Visual Fortran Compiler Professional for applications running on IA-32,
Version 11.0 Build 20080930 Package ID: w_cprof_p_11.0.061
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

Microsoft Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:a2.exe
-subsystem:console
a2.obj
c:Projects>a2.exe
153
0 10
151 10
1.00000000000000

I also tried it in Visual Studio and got the same result. How certain are you that you are executing the newly built executable? Also, I do not see a heap corruption error in the Debug build, but I do get an array bounds error as I should.

View solution in original post

0 Kudos
3 Replies
Steven_L_Intel1
Employee
480 Views

Interesting. When I try it with 11.0.061 it works:

c:Projects>ifort a2.f90
Intel Visual Fortran Compiler Professional for applications running on IA-32,
Version 11.0 Build 20080930 Package ID: w_cprof_p_11.0.061
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

Microsoft Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:a2.exe
-subsystem:console
a2.obj
c:Projects>a2.exe
153
0 10
151 10
1.00000000000000

I also tried it in Visual Studio and got the same result. How certain are you that you are executing the newly built executable? Also, I do not see a heap corruption error in the Debug build, but I do get an array bounds error as I should.

0 Kudos
abhimodak
New Contributor I
479 Views

Hi Steve

I believe I "judged" too early...

I indeed get the 10 instead of 20 for the third line in output with 11.0.061 AND the debug does give me an array bounds error.

I believe the root of the problem is actually in my thinking..I somehow keep expecting that the assignment A(16) will not happen; even in the release mode. It understand it does not work like that and I think A(16)'s memory is up for grab for anything else and can get stomped over.

In short, please accept my apologies.

Sincerely

Abhi

0 Kudos
Steven_L_Intel1
Employee
479 Views

No worries, as they say down under. I'm just glad that it is indeed fixed!

As you say, the assignment of A(16) just stomps on whatever memory is at that offset from the array base.

0 Kudos
Reply