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

/Qvc option differences between 11.1 and 12.0 Update 3

lou-muccioli
Beginner
552 Views
When I compile a simple Fortran progam using the following ifort command at Intel Visual Fortran 11.1, I get an object file. So far so good.
ifort /c /debug:full /Qvc9 prog.F
When I compile using the same command above at Intel Fortran Compiler XE 12.0 Update 3 I get an object file AND a vc90.pdb. This seems a bit odd since I'm doing this from the command line and not in Visual Studio 2008 and I'm compiling Fortran, not C/C++. Can someone please explain why the Fortran compiler would create a vc90.pdb file? I thought the debug info was embedded in the obj file.
Thanks,
Lou
0 Kudos
13 Replies
Steven_L_Intel1
Employee
552 Views
In 12.0 we switched to generating a separate PDB because of complaints from users about the size of object files. This matches the Microsoft C++ behavior. You can use /Z7 to force the debug information to be embedded in the object. The name of the PDB is based on the VC version you are integrating with (/Qvc).
0 Kudos
strohhaecker
Beginner
552 Views
In 12.0 we switched to generating a separate PDB because of complaints from users about the size of object files. This matches the Microsoft C++ behavior.

All parameters regarding the placement/naming are still broken in update3, see
http://software.intel.com/en-us/forums/showthread.php?t=78957
which is applicable for all 12.0 releases/updates and is definitely different from the MS C++ behavior.
0 Kudos
lou-muccioli
Beginner
552 Views
Thanks for clearing that up Steve. Another question, should the following let me specify a PDB name of my choice? It still creates a vc90.pdb. And, is the option /Fd or /pdbfile? The online doc vs. ifort /? seems a little inconsistent but I tried both and still couldn't seem to specify a PDB name of my choice.

ifort /Zi /Fd:mypdbfile /c prog.F

With that said, perhaps I should still use /Z7 because I build several static libaries from batch scripts, some libaries are built using ifort *.F and some are built as follows:

ifort file1.F
ifort file2.F
ifort file3.F

In either case I'm not sure how to preserve the PDB file for all of the files.

Thanks,

Lou
0 Kudos
Steven_L_Intel1
Employee
552 Views
Lou,

I have escalated the issue of /Fd being ignored as issue DPD200168013.

In the case you describe, the compiler will update vcxx.pdb on the subsequent compilations, so you need only one.
0 Kudos
lou-muccioli
Beginner
552 Views
OK, thanks Steve! It turns out a I have a more serious issue regardless of whether or not I use /Zi or /Z7. When I create my "main" static library via the "LIB" command, I get the following error:

LINK : fatal error LNK1248: image size (8012AC6B) exceeds maximum allowable size (80000000)

Looks like I'm going to have to split up my static library since it's a bit over 2GB. I didn't realized this was a Windows limit even on x64.

The same static debug library was 1.6 GB using IVF 11.1 so I was getting close anyways.

Thanks again,

Lou
0 Kudos
Steven_L_Intel1
Employee
552 Views
Splitting the library isn't going to help. There is a 2GB total limit on static code and data even on X64. If you have large static arrays, I suggest making them ALLOCATABLE to avoid this problem.
0 Kudos
lou-muccioli
Beginner
552 Views

Actually splitting the static library into two worked fine. When our application is compiled with optimization the static library is around 600 MB, with the following debug options it's 1.6 GB with IVF 11.1 and over 2 GB with IVF 12.0. The "LIB" command failed, not the creating of the executable, e.g. LINK.EXE. I realize that "LIB" inherently calls "LINK.EXE" but I was just doing a "LIB /out:mylib.lib *.obj" Apparently there is a 2 GB static library file size limit. BTW, we don't use large static arrays, we dynamically allocate.

ifort /Zi /Od /fpp /recursive /debug-parameters:all /fpe:0 /names:uppercase /traceback /check:uninit /Qau

to /Qtrapuv /libs:dll /threads /Qopenmp /QaxAVX

Lou

0 Kudos
Steven_L_Intel1
Employee
552 Views
The issue with /Fd being ignored has been fixed for a future version of the compiler. For a long time the compiler did not write separate PDB files and ignored /Fd so as to not break build scripts. When we changed the compiler to write separate PDBs we forgot to go back and re-enable /Fd.
0 Kudos
Allen_Barnett
Beginner
552 Views

Hi: Has this issue been resolved? I tried to make two .lib files today, but they really couldn't live together in the same installation directory because both pdb files were named vc100.pdb. /pdbfile: didn't seem to work, but perhaps there's more to it. (This is third party software so I'm a bit limited in how much I can monkey with their build system.)

Thanks,

Allen

0 Kudos
lou-muccioli
Beginner
552 Views

Yes, this has been resolved by using the /Fd option.

Thanks,

Lou

0 Kudos
Allen_Barnett
Beginner
552 Views

Hi Lou: Do you know which release resolved this issue? I have ifort 12.0.1.127 and "ifort /c /debug:full /Fd:example example.f90" still produces a vc100.pdb file.

Thanks,

Allen

0 Kudos
Steven_L_Intel1
Employee
552 Views

It would be compiler version 12.1, or Compose XE 2011 Update 6. You're using a compiler earlier than the one cited in this thread.

0 Kudos
Allen_Barnett
Beginner
552 Views

OK. I updated my windows version to 13.1.0.149 and it works fine. Thank you!

Allen

0 Kudos
Reply