Why is DumpBin telling me there are no COMDATs in my binaries when I know there are truckloads of the things?

Question

This is the output I get from dumpbin AchievementsTable.obj /HEADERS

Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file AchievementsTable.obj

File Type: ANONYMOUS OBJECT

ANON OBJECT HEADER VALUES
               1 version
             14C machine (x86)
        4C51334D time date stamp Thu Jul 29 08:52:45 2010
                 ClassID: {0CB3FE38-D9A5-4DAB-AC9B-D6B6222653C2}
            945F size
               0 flags

ALL my source does this. I am using VisualStudio 2005. I know for a fact that there are lots of COMDATs being exported, as the .exe subsequently links and executes correctly: are there compiler switches I should be avoiding? Here are the ones I am using:

/O1
/Ob2
/Oi
/GT
/GL
/I "..\dxsdk\include" <lots of include paths>
/D "WIN32" <lots of #defines>
/GF
/FD
/MT
/GS-
/Gy
/arch:SSE2
/fp:fast
/GR-
/Fo <directory specified>
/Fd <pdb filename specified>
/FR <directory specified>
/W4
/c
/Zi
/TP .\Source\databases\AchievementsTable.cpp

I'm open to commentary on my selection in general, but DumpBin use is the focus of this question: take it away, boys and girls...

Answer 1

After a day of elimination, I discovered that the DUMPBIN documentation is a little ambiguous.

Switching on function level linking (/Gy) is needed to get the COMDAT output. Switching on cross module optimisations (/GL) delays code generation to link time. Therefore, although it is true that header information is available to code compiled with /GL, it is very limited. That's why it's the only option available to DUMPBIN - all the other options require more information, the generation of which is delayed by /GL.