Work around a nasty compiler bug in GCC 6.3
GCC 6.3 errors out with an ICE or simply hangs when instantiating a certain variant of operator^= on
BitSetVectorReference. This patch works around the problem by forcing the actual XOR instruction
into a separate function for that compiler. The workaround is probably horribly slow, but it
shouldn't have any impact on unaffected compilers.
This probably needs backporting.
Merge request reports
Activity
mentioned in commit 9a9fceea
mentioned in commit b04c8053
mentioned in merge request !529 (merged)
mentioned in commit 868ee4f2
mentioned in merge request !530 (merged)
mentioned in commit 8f902169
mentioned in commit 48931186
315 315 return *this; 316 316 } 317 317 318 private: 319 320 // For some reason, the following variant of operator^= triggers an ICE or a hanging 321 // compiler on Debian 9 with GCC 6.3 and full optimizations enabled (-O3). 322 // The only way to reliably avoid the issue is by making sure that the compiler does not 323 // see the XOR in the context of the function, so here is a little helper that will normally 324 // be inlined, but not on the broken compiler. This incurs a substantial overhead (a function 325 // call), but until someone else has a better idea, it's the only way to make it work reliably. -
My suggestion would be to look at optimize attribute (Ctrl-F optimize) or pragma to disable the specific optimization that triggers this. Not sure whether that's worth the time, though.