Optimiser Repressing Linker Error

[Frederick Gotham]

Let's say I have a program consisting one translation unit as follows:

extern void Func(void);

bool constexpr g_condition = false;

int main()
{
if ( g_condition )
Func();
}

If I compile this single translation unit to a program with the GNU compiler as follows:

g++ -o prog prog.cpp

then it compiles and links fine.

It seems that an automated optimiser realises that "Func" will never be called and so it doesn't require its definition.

[Paavo Helde]

If you do not want to rely on random optimizations, you can rewrite this as:

extern void Func(void);

bool constexpr g_condition = false;

int main() {

if constexpr (g_condition)
Func();
}

Now the Func() call gets officially discarded and Func can legally
remain undefined.

[Bonita Montero]

Where's the problem ?

[Alf P. Steinbach]

Gah, where's the upvote button on this Usenet thing?

- Alf

[Juha Nieminen]

Frederick Gotham <cauldwel...@gmail.com> wrote:
> It seems that an automated optimiser realises that "Func" will never be called and so it doesn't require its definition.

I doubt that the standard guarantees linker errors for code that might
or might not be optimized away by the linker.

Btw, this is one of the reasons why one should *always* test compiling
one's projects *with* and *without* optimizations. It has bitten me
in the behind more than once that I have the habit of always
compiling with optimizations and never trying what happens if I leave
optimizations out. More than once when compiling without optimizations
I have got linker errors because I didn't realize that something
was not defined properly but the compiler was hiding the error with
optimizations.

(Of course even then you can really rely on finding this out by
simply leaving optimizations options out, as there's no guarantee that
the compiler will not keep optimizing some things out.)

[Frederick Gotham]

On Tuesday, June 30, 2020 at 7:15:52 AM UTC+1, Juha Nieminen wrote:
>
> I doubt that the standard guarantees linker errors for code that might
> or might not be optimized away by the linker.
>
> Btw, this is one of the reasons why one should *always* test compiling
> one's projects *with* and *without* optimizations. It has bitten me
> in the behind more than once that I have the habit of always
> compiling with optimizations and never trying what happens if I leave
> optimizations out. More than once when compiling without optimizations
> I have got linker errors because I didn't realize that something
> was not defined properly but the compiler was hiding the error with
> optimizations.
>
> (Of course even then you can really rely on finding this out by
> simply leaving optimizations options out, as there's no guarantee that
> the compiler will not keep optimizing some things out.)

I had one executable program that I decided to split into one executable program and two libraries.

So I did the split, and then I tried to link everything together. Well the exectuable program linked successfully even when I didn't link it with one of the new libraries I had created. I spent maybe about an hour copy-pasting function declarations and moving ".cpp" files, before I decided to look at where the function is called in the code, and I saw that I had an if-statement with a compile-time-constant boolean.