C++ (not a flame war) FYI and a question

NTDEV
1

We recently ran into a rats nest of compiler madness here regarding virtual
function tables (vtables) and c++ class hierarchies. Specifically an
engineer testing a modification to a complex C++ based driver discovered to
his horror that sending an IOCTL to a specific device object in this driver
ended up in the DispatchSystemControl method rather than the
DispatchDeviceControl method. An examination, using windbg, of the vtable
for this device extension object revealed that indeed where the address for
DispatchDeviceControl ought to be was instead the address of
DispatchSystemControl. Further examination unraveled the confusion: the
compiler knows better than a mere programmer. The compiler examines code
segments associated with virtual functions and only emits one version of any
identical segment. (It may do this for non-virtual functions, and it may
only do this for virtual functions only within a class hierarchy, I don’t
know the details nor can I find any documentation regarding this behavior.)
So if you run into this horror show, don’t worry, be happy, the compiler
knows better.

Now to the question. I wouldn’t mind this compiler behavior in the free
build, where I expect all sorts of code-mangling obfuscations from the
compiler, but I really hate it in the checked build, where I expect A to be
A and not B. So does anyone know how to turn this particular optimization
off?

=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com

2

“Roddy, Mark” wrote:

The compiler examines code
segments associated with virtual functions and only emits one version of any
identical segment. (It may do this for non-virtual functions, and it may
only do this for virtual functions only within a class hierarchy, I don’t
know the details nor can I find any documentation regarding this behavior.)

I’ve noticed that regular functions that are completely identical get
merged into a single function. E.g.:

NTSTATUS DispatchSomething(PDEVICE_OBJECT fdo, PIRP Irp)
{
return CompleteRequest(Irp, STATUS_SUCCESS, 0);
}

NTSTATUS DispatchSomethingElse(PDEVICE_OBJECT fdo, PIRP Irp)
{
return CompleteRequest(Irp, STATUS_SUCCESS, 0);
}

The compiler, even in the debug build, emits just one function. Is this
what you’re talking about?

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

3

Yup, that’s the behavior. So at least it isn’t C++ specific. However the
docs clearly state that this optimization is turned off by /Od, and that is
set in the checked build. I think this is a plain old bug.

=====================
Mark Roddy

-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, September 22, 2003 10:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

“Roddy, Mark” wrote:
> The compiler examines code
> segments associated with virtual functions and only emits
one version
> of any identical segment. (It may do this for non-virtual
functions,
> and it may only do this for virtual functions only within a class
> hierarchy, I don’t know the details nor can I find any
documentation
> regarding this behavior.)

I’ve noticed that regular functions that are completely
identical get merged into a single function. E.g.:

NTSTATUS DispatchSomething(PDEVICE_OBJECT fdo, PIRP Irp)
{
return CompleteRequest(Irp, STATUS_SUCCESS, 0);
}

NTSTATUS DispatchSomethingElse(PDEVICE_OBJECT fdo, PIRP Irp)
{
return CompleteRequest(Irp, STATUS_SUCCESS, 0);
}

The compiler, even in the debug build, emits just one
function. Is this what you’re talking about?

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

4

> I’ve noticed that regular functions that are completely identical get

merged into a single function. E.g.:
[…]
The compiler, even in the debug build, emits just one function. Is
this
what you’re talking about?

This is the result of the linker’s mechanism to merge redundant template
function instantiations. Though your functions are not template
functions, they are still merged.

Chuck

5

That’s a pretty aggressive optimization, it will fail if the function has a
shadow of a side-effect, and not all side-effects are trackable by a
compiler. It’s just as well that there’s an optimization to turn it off,
however, do you know what else does /Od turn off ?

Alberto.

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Monday, September 22, 2003 10:23 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

Yup, that’s the behavior. So at least it isn’t C++ specific. However the
docs clearly state that this optimization is turned off by /Od, and that is
set in the checked build. I think this is a plain old bug.

=====================
Mark Roddy

-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, September 22, 2003 10:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

“Roddy, Mark” wrote:
> The compiler examines code
> segments associated with virtual functions and only emits
one version
> of any identical segment. (It may do this for non-virtual
functions,
> and it may only do this for virtual functions only within a class
> hierarchy, I don’t know the details nor can I find any
documentation
> regarding this behavior.)

I’ve noticed that regular functions that are completely
identical get merged into a single function. E.g.:

NTSTATUS DispatchSomething(PDEVICE_OBJECT fdo, PIRP Irp)
{
return CompleteRequest(Irp, STATUS_SUCCESS, 0);
}

NTSTATUS DispatchSomethingElse(PDEVICE_OBJECT fdo, PIRP Irp)
{
return CompleteRequest(Irp, STATUS_SUCCESS, 0);
}

The compiler, even in the debug build, emits just one
function. Is this what you’re talking about?

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

6

You misunderstand me. The docs say /Od turns it off, but the docs appear to
be wrong. Given that, neither I nor the docs have any idea what /Od really
turns off :-).

=====================
Mark Roddy

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Monday, September 22, 2003 10:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

That’s a pretty aggressive optimization, it will fail if the
function has a shadow of a side-effect, and not all
side-effects are trackable by a compiler. It’s just as well
that there’s an optimization to turn it off, however, do you
know what else does /Od turn off ?

Alberto.

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Monday, September 22, 2003 10:23 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

Yup, that’s the behavior. So at least it isn’t C++ specific.
However the docs clearly state that this optimization is
turned off by /Od, and that is set in the checked build. I
think this is a plain old bug.

=====================
Mark Roddy

> -----Original Message-----
> From: Walter Oney [mailto:xxxxx@oneysoft.com]
> Sent: Monday, September 22, 2003 10:12 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: C++ (not a flame war) FYI and a question
>
>
> “Roddy, Mark” wrote:
> > The compiler examines code
> > segments associated with virtual functions and only emits
> one version
> > of any identical segment. (It may do this for non-virtual
> functions,
> > and it may only do this for virtual functions only within a class
> > hierarchy, I don’t know the details nor can I find any
> documentation
> > regarding this behavior.)
>
> I’ve noticed that regular functions that are completely
> identical get merged into a single function. E.g.:
>
> NTSTATUS DispatchSomething(PDEVICE_OBJECT fdo, PIRP Irp)
> {
> return CompleteRequest(Irp, STATUS_SUCCESS, 0);
> }
>
> NTSTATUS DispatchSomethingElse(PDEVICE_OBJECT fdo, PIRP Irp)
> {
> return CompleteRequest(Irp, STATUS_SUCCESS, 0);
> }
>
> The compiler, even in the debug build, emits just one
> function. Is this what you’re talking about?
>
> –
> Walter Oney, Consulting and Training
> Basic and Advanced Driver Programming Seminars
> Check out our schedule at http://www.oneysoft.com
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named
addressee only. It
contains information that may be confidential. Unless you are
the named
addressee or an authorized designee, you may not copy or use
it, or disclose
it to anyone else. If you received it in error please notify
us immediately
and then destroy it.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

I don’t understand. Is this causing a problem? If the compiler is
collapsing redundant, identical functions, then your functional behavior
is still identical, right?

Is it just that this behavior is unsettling? Or is it causing confusion
during debugging because you’re suddenly in an unfamiliar method, albeit
one that works identically to the one you expected?

And can I write any more sentences that end in question marks?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, September 22, 2003 9:22 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] C++ (not a flame war) FYI and a question

We recently ran into a rats nest of compiler madness here regarding
virtual function tables (vtables) and c++ class hierarchies.
Specifically an engineer testing a modification to a complex C++ based
driver discovered to his horror that sending an IOCTL to a specific
device object in this driver ended up in the DispatchSystemControl
method rather than the DispatchDeviceControl method. An examination,
using windbg, of the vtable for this device extension object revealed
that indeed where the address for DispatchDeviceControl ought to be was
instead the address of DispatchSystemControl. Further examination
unraveled the confusion: the compiler knows better than a mere
programmer. The compiler examines code segments associated with virtual
functions and only emits one version of any identical segment. (It may
do this for non-virtual functions, and it may only do this for virtual
functions only within a class hierarchy, I don’t know the details nor
can I find any documentation regarding this behavior.) So if you run
into this horror show, don’t worry, be happy, the compiler knows better.

Now to the question. I wouldn’t mind this compiler behavior in the free
build, where I expect all sorts of code-mangling obfuscations from the
compiler, but I really hate it in the checked build, where I expect A to
be A and not B. So does anyone know how to turn this particular
optimization off?

=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@sublinear.org To
unsubscribe send a blank email to xxxxx@lists.osr.com

8

> That’s a pretty aggressive optimization, it will fail if the function
has a

shadow of a side-effect, and not all side-effects are trackable by a
compiler. It’s just as well that there’s an optimization to turn it
off,
however, do you know what else does /Od turn off ?

Uh, if two functions are binary equivalent, how would removal of a
redundant copy cause a failure?

Chuck

9

Oh I agree that if done correctly the optimization does not alter functional
behavior. However, as I said, I expect code mangling in the free build, I do
not expect it in the checked build. I expect that when I step into the
dispatch function that is supposed to handle IOCTLs, that the debugger will
indicate that this function is named something like ‘DispatchDeviceControl’,
not ‘DispatchSystemControl’. I also expect that /Od, set in the checked
build, disables ALL OF THIS CRAP, as it states that it does.

Offline another person has indicated that this behavior is associated with
the (what appears to be undocumented) linker’s ‘duplicate template function
removal’ optimizations. That is fine again, but the checked build ought to
turn this off, or there ought to be a documented way to turn this off.

=====================
Mark Roddy

-----Original Message-----
From: Arlie Davis [mailto:xxxxx@sublinear.org]
Sent: Monday, September 22, 2003 11:04 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: C++ (not a flame war) FYI and a question

I don’t understand. Is this causing a problem? If the
compiler is collapsing redundant, identical functions, then
your functional behavior is still identical, right?

Is it just that this behavior is unsettling? Or is it
causing confusion during debugging because you’re suddenly in
an unfamiliar method, albeit one that works identically to
the one you expected?

And can I write any more sentences that end in question marks?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, September 22, 2003 9:22 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] C++ (not a flame war) FYI and a question

We recently ran into a rats nest of compiler madness here
regarding virtual function tables (vtables) and c++ class
hierarchies. Specifically an engineer testing a modification
to a complex C++ based driver discovered to his horror that
sending an IOCTL to a specific device object in this driver
ended up in the DispatchSystemControl method rather than the
DispatchDeviceControl method. An examination, using windbg,
of the vtable for this device extension object revealed that
indeed where the address for DispatchDeviceControl ought to
be was instead the address of DispatchSystemControl. Further
examination unraveled the confusion: the compiler knows
better than a mere programmer. The compiler examines code
segments associated with virtual functions and only emits one
version of any identical segment. (It may do this for
non-virtual functions, and it may only do this for virtual
functions only within a class hierarchy, I don’t know the
details nor can I find any documentation regarding this
behavior.) So if you run into this horror show, don’t worry,
be happy, the compiler knows better.

Now to the question. I wouldn’t mind this compiler behavior
in the free build, where I expect all sorts of code-mangling
obfuscations from the compiler, but I really hate it in the
checked build, where I expect A to be A and not B. So does
anyone know how to turn this particular optimization off?

=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@sublinear.org To unsubscribe
send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

10

Um, no. If two functions are binary identical, that is, bit-for-bit
exactly the same, then the side-effects are also identical. This is a
safe optimization; if it wasn’t, it would have broken someone,
somewhere. MSVC has been doing this for a long, long time.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Moreira, Alberto
Sent: Monday, September 22, 2003 10:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

That’s a pretty aggressive optimization, it will fail if the function
has a shadow of a side-effect, and not all side-effects are trackable by
a compiler. It’s just as well that there’s an optimization to turn it
off, however, do you know what else does /Od turn off ?

Alberto.

11

Though I don’t know of a documented way, and you may have considered this,
but perhaps a decent hack of a work around would be:

#ifdef DBG
__asm nop
#endif

Just to differ the functions ever so slightly. Ugly, sure, and I hope
there’s a ‘supported’ way to do it…but if not, this should work.

Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Monday, September 22, 2003 10:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: C++ (not a flame war) FYI and a question

Oh I agree that if done correctly the optimization does not alter functional
behavior. However, as I said, I expect code mangling in the free build, I do
not expect it in the checked build. I expect that when I step into the
dispatch function that is supposed to handle IOCTLs, that the debugger will
indicate that this function is named something like ‘DispatchDeviceControl’,
not ‘DispatchSystemControl’. I also expect that /Od, set in the checked
build, disables ALL OF THIS CRAP, as it states that it does.

Offline another person has indicated that this behavior is associated with
the (what appears to be undocumented) linker’s ‘duplicate template function
removal’ optimizations. That is fine again, but the checked build ought to
turn this off, or there ought to be a documented way to turn this off.

=====================
Mark Roddy

-----Original Message-----
From: Arlie Davis [mailto:xxxxx@sublinear.org]
Sent: Monday, September 22, 2003 11:04 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: C++ (not a flame war) FYI and a question

I don’t understand. Is this causing a problem? If the
compiler is collapsing redundant, identical functions, then
your functional behavior is still identical, right?

Is it just that this behavior is unsettling? Or is it
causing confusion during debugging because you’re suddenly in
an unfamiliar method, albeit one that works identically to
the one you expected?

And can I write any more sentences that end in question marks?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, September 22, 2003 9:22 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] C++ (not a flame war) FYI and a question

We recently ran into a rats nest of compiler madness here
regarding virtual function tables (vtables) and c++ class
hierarchies. Specifically an engineer testing a modification
to a complex C++ based driver discovered to his horror that
sending an IOCTL to a specific device object in this driver
ended up in the DispatchSystemControl method rather than the
DispatchDeviceControl method. An examination, using windbg,
of the vtable for this device extension object revealed that
indeed where the address for DispatchDeviceControl ought to
be was instead the address of DispatchSystemControl. Further
examination unraveled the confusion: the compiler knows
better than a mere programmer. The compiler examines code
segments associated with virtual functions and only emits one
version of any identical segment. (It may do this for
non-virtual functions, and it may only do this for virtual
functions only within a class hierarchy, I don’t know the
details nor can I find any documentation regarding this
behavior.) So if you run into this horror show, don’t worry,
be happy, the compiler knows better.

Now to the question. I wouldn’t mind this compiler behavior
in the free build, where I expect all sorts of code-mangling
obfuscations from the compiler, but I really hate it in the
checked build, where I expect A to be A and not B. So does
anyone know how to turn this particular optimization off?

=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@sublinear.org To unsubscribe
send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@positivenetworks.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

12

Not if the function involves any position-dependent code. For example,
breakpoints won’t necessarily behave the same way.

Alberto.

-----Original Message-----
From: Arlie Davis [mailto:xxxxx@sublinear.org]
Sent: Monday, September 22, 2003 11:27 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

Um, no. If two functions are binary identical, that is, bit-for-bit
exactly the same, then the side-effects are also identical. This is a
safe optimization; if it wasn’t, it would have broken someone,
somewhere. MSVC has been doing this for a long, long time.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Moreira, Alberto
Sent: Monday, September 22, 2003 10:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

That’s a pretty aggressive optimization, it will fail if the function
has a shadow of a side-effect, and not all side-effects are trackable by
a compiler. It’s just as well that there’s an optimization to turn it
off, however, do you know what else does /Od turn off ?

Alberto.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

13

All you need is some position-dependent code. For example, a goto jumping
outside it, $+128 can be different in the two cases if it doesn’t fall
inside the function.

Alberto

-----Original Message-----
From: Chuck Batson [mailto:xxxxx@cbatson.com]
Sent: Monday, September 22, 2003 11:00 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

That’s a pretty aggressive optimization, it will fail if the function
has a
shadow of a side-effect, and not all side-effects are trackable by a
compiler. It’s just as well that there’s an optimization to turn it
off,
however, do you know what else does /Od turn off ?

Uh, if two functions are binary equivalent, how would removal of a
redundant copy cause a failure?

Chuck

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

14

IIRC you need to play with linker’s flag /OPT:NOICF
Try it please.

Bye,
Sab

-----Original Message-----
From: Chuck Batson [mailto:xxxxx@cbatson.com]
Sent: Monday, September 22, 2003 4:23 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

> I’ve noticed that regular functions that are completely
identical get
> merged into a single function. E.g.:
[…]
> The compiler, even in the debug build, emits just one function. Is
this
> what you’re talking about?

This is the result of the linker’s mechanism to merge
redundant template
function instantiations. Though your functions are not template
functions, they are still merged.

Chuck

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@mastereye.kiev.ua
To unsubscribe send a blank email to xxxxx@lists.osr.com

15

True but it’s rather difficult to write position-dependent functions in
standard C or C++. As such I’d say it’s a perfectly reasonable
optimization and hardly qualifies as aggressive.

Chuck

----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Monday, September 22, 2003 11:06 PM
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

> All you need is some position-dependent code. For example, a goto
jumping
> outside it, $+128 can be different in the two cases if it doesn’t fall
> inside the function.
>
> Alberto
>
> -----Original Message-----
> From: Chuck Batson [mailto:xxxxx@cbatson.com]
> Sent: Monday, September 22, 2003 11:00 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: C++ (not a flame war) FYI and a question
>
>
> > That’s a pretty aggressive optimization, it will fail if the
function
> has a
> > shadow of a side-effect, and not all side-effects are trackable by a
> > compiler. It’s just as well that there’s an optimization to turn it
> off,
> > however, do you know what else does /Od turn off ?
>
> Uh, if two functions are binary equivalent, how would removal of a
> redundant copy cause a failure?
>
> Chuck

16

> IIRC you need to play with linker’s flag /OPT:NOICF

I concur – this should stop the function merging. Although, the docs
say, “ICF is on by default if REF is on and needs to be explicitly
turned on in a debug build.” So perhaps Mark should the linker flags
for his checked build to see if /OPT:REF is being inadvertently
specified. He would also have to be specifying /Gy during compilation,
which would also be out of the ordinary for a debug build.

Chuck

17

Yes, by default -OPT:REF and -OPT:ICF are specified in MAKEFILE.DEF (see LINK_REF_FLAG).
So, it’s need to set -OPT:NOICF explicitly or define LINKER_NOICF or LINKER_NOICF (see MAKEFILE.DEF) to do the same.

Bye,
Sab

-----Original Message-----
From: Chuck Batson [mailto:xxxxx@cbatson.com]
Sent: Monday, September 22, 2003 6:54 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

> IIRC you need to play with linker’s flag /OPT:NOICF

I concur – this should stop the function merging. Although, the docs
say, “ICF is on by default if REF is on and needs to be explicitly
turned on in a debug build.” So perhaps Mark should the linker flags
for his checked build to see if /OPT:REF is being inadvertently
specified. He would also have to be specifying /Gy during
compilation,
which would also be out of the ordinary for a debug build.

Chuck

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@mastereye.kiev.ua
To unsubscribe send a blank email to xxxxx@lists.osr.com

18

Check LINKER_NOREF entry in Windows 2003 DDK documentation (don’t know if it
exists in earlier versions).

-htfv

----- Original Message -----
From: “Sasha Bublik - (BS)”
To: “Windows System Software Devs Interest List”
Sent: Monday, September 22, 2003 8:45 PM
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

Yes, by default -OPT:REF and -OPT:ICF are specified in MAKEFILE.DEF (see
LINK_REF_FLAG).
So, it’s need to set -OPT:NOICF explicitly or define LINKER_NOICF or
LINKER_NOICF (see MAKEFILE.DEF) to do the same.

---------
Bye,
Sab

> -----Original Message-----
> From: Chuck Batson [mailto:xxxxx@cbatson.com]
> Sent: Monday, September 22, 2003 6:54 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: C++ (not a flame war) FYI and a question
>
>
> > IIRC you need to play with linker’s flag /OPT:NOICF
>
> I concur – this should stop the function merging. Although, the docs
> say, “ICF is on by default if REF is on and needs to be explicitly
> turned on in a debug build.” So perhaps Mark should the linker flags
> for his checked build to see if /OPT:REF is being inadvertently
> specified. He would also have to be specifying /Gy during
> compilation,
> which would also be out of the ordinary for a debug build.
>
> Chuck
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@mastereye.kiev.ua
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@vba.com.by
To unsubscribe send a blank email to xxxxx@lists.osr.com

19

I was slightly wrong about /Gy. There are two cases where functions get
packaged regardless of using /Gy (from the docs):

  1. Inline functions if they are instantiated as calls (which occurs, for
    example, if inlining is turned off or you take a function address)

  2. Member functions defined within the class declaration

Chuck

----- Original Message -----
From: “Chuck Batson”
To: “Windows System Software Devs Interest List”
Sent: Monday, September 22, 2003 11:53 PM
Subject: [ntdev] Re: C++ (not a flame war) FYI and a question

> > IIRC you need to play with linker’s flag /OPT:NOICF
>
> I concur – this should stop the function merging. Although, the docs
> say, “ICF is on by default if REF is on and needs to be explicitly
> turned on in a debug build.” So perhaps Mark should the linker flags
> for his checked build to see if /OPT:REF is being inadvertently
> specified. He would also have to be specifying /Gy during
compilation,
> which would also be out of the ordinary for a debug build.