- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page