/dbglibs changing program behaviour?

/dbglibs changing program behaviour?

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

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

Using ifort 12.1.0 under the included vs 2010 shell environment:

>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

But add /dbglibs to that:

>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
  

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.

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

/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.

Steve - Intel Developer Support

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.

Steve - Intel Developer Support

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.

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today