Bug in Compiler

[paulbalaji]

So we seem to have found a compiler bug - and we can't fix the bug because we can't update gcc/g++ to a newer version

How do we work around this because it seems impractical to change our code just to get around a compiler bug?

gaussian_blur.hpp:51:30: internal compiler error: in expand_expr_real_1, at expr.c:9456 {{redacted code sample}} ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions. Preprocessed source stored into /tmp/cc3ZAsp7.out file, please attach this to your bugreport.

[m8pple]

I've run across this problem so many times I've lost count, across various environments, including DoC teaching labs (it was Solaris then), ICT Redhat machines, industry workstations, client sites, ... the list goes on. Compiler bugs used to be a fact of life, particularly in -O3 (this could easily degrade into a "In my day we compiled uphill, both ways" thing - eventually you'll be old and want to do it it (for you it might be, "in my day we had to use Javascript!", cue children gasping in shock)). Using g++ 4.9.2 (2014) in 2017 is pretty good going. But they all boil down to knowing that there is a compiler bug, but you can't upgrade for operational reasons as you don't control the env.

While it's a pain, I'm afraid the idea that it is impractical to work around the compiler bug doesn't really hold- you can't tell a client "Your build env is too old, I cannot work with this." If they turn round and say "We are running a July 2017 version of Debian stable", what are you going to say? (I just did an update/upgrade, and nothing changed). At worst, you just revert to the previous version of the code. Ideally, you work around it.

Most compiler bugs can be worked around, by re-ordering things, or splitting things up in different ways:

• You know roughly which line it occurs on, so what happens if you start splitting it up, or calculating it in a separate function?
• If you re-order lines does it help?
• Can you rebracket expressions (stupid, but it can help)?
• If it is a constant, can you write it out to a volatile, then read it back in again?
• How can you confuse the compiler, to stop it taking the same parsing/optimisation/codegen path?

In terms of updating/upgrading the compiler, is there a newer version that actually works? So if you upgrade the distribution, does a newer g++ compile it correctly?

[paulbalaji]

Hmm yeah, not ideal but understandable

I think we're running newer g++ on our laptops, and that seems to compile fine - but not tested by upgrading distribution on AWS

Like you said, probably should just find a workaround - might actually be quicker than updating distributions