/dbglibs changing program behaviour?

[IanH]

This one has got me a bit confused. Consider the following:

[fortran]MODULE MyMod
  IMPLICIT NONE
  TYPE :: VarChar
    CHARACTER(:), ALLOCATABLE :: item
  END TYPE VarChar  
CONTAINS
  SUBROUTINE GetTheOdds(list)  
    TYPE(VarChar), INTENT(INOUT), ALLOCATABLE :: list(:)    
    !----
    LOGICAL :: mask(SIZE(list))  
    !****
    mask(1::2) = .TRUE.
    mask(2::2) = .FALSE.  
    list = PACK(list, mask)    
  END SUBROUTINE GetTheOdds
END MODULE MyMod

PROGRAM PackingThemIn
  USE MyMod
  IMPLICIT NONE
  TYPE(VarChar), ALLOCATABLE :: list(:)  
  INTEGER :: i    
  !****
  list = [  &
      VarChar('One'),   VarChar('Two'),   VarChar('Three'),  &
      VarChar('Four'),  VarChar('Five'),  VarChar('Six') ]  
  PRINT "(999(A,:,' '))", (list(i)%item, i = 1, SIZE(list))
  CALL GetTheOdds(list)    
  PRINT "(999(A,:,' '))", (list(i)%item, i = 1, SIZE(list))
END PROGRAM PackingThemIn
[/fortran]

Using ifort 12.1.0 under the included vs 2010 shell environment:

[plain]>ifort /check:all /warn:all /standard-semantics PackingThemIn.f90 && PackingThemIn.exe
Intel Visual Fortran Compiler XE for applications running on IA-32, Version 12.1.0.233 Build 20110811
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

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

-out:PackingThemIn.exe
-subsystem:console
PackingThemIn.obj
One Two Three Four Five Six
One Three Five[/plain]

But add /dbglibs to that:

[plain]>ifort /check:all /warn:all /standard-semantics /dbglibs PackingThemIn.f90 && PackingThemIn.exe
Intel Visual Fortran Compiler XE for applications running on IA-32, Version 12.1.0.233 Build 20110811
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

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

-out:PackingThemIn.exe
-subsystem:console
PackingThemIn.obj
One Two Three Four Five Six
  [/plain]

Those odds don't look good!

I think I get the same strangeness with 12.0.5 and VS2005, but I guess there's the possibility that the libraries that are being linked in are the same. What's /dbglibs actually do?

Interesting that the components end up with the right length.

[Steven_L_Intel1]

/dbglibs causes the "debug" version of the MSVC libraries to be linked in. One of the effects this has is that memory allocations are done with "guard areas" before and after that help the C library detect misuse of pointers.

I took a quick look at this and it seems the PACK is not storing the correct values. We'll look closer.

[Steven_L_Intel1]

The problem is that when the code is creating the new value for list, it reuses the contents of original element values rather than allocating new ones. It then deallocates the old ones. With /dbglibs, this deallocation fills the memory with a garbage pattern resulting in the unprintable characters. Without /dbglibs, the old values remain until something reuses that space. I tried a workaround I thought of but it made matters worse!

Escalated as issue DPD200173379.

[Steven_L_Intel1]

This has been fixed for a release later this year. When doing an assignment with PACK on the right side, the compiler was failing to consider that there could be overlap between the LHS and RHS.