4

I have a C++ soft that gets compiled with different OSes, platforms & compilers. Now sometimes compiler have bugs e.g. for instance this one, which implies that gcc versions pre 4.6.4 and pre 4.7.3 are a no-go. Now i could include a unit test that showcases the bug (and perhaps this question will reveal that indeed that's what I should be doing) but this is a tedious task: compiler bugs are sometimes hard to repro and turning one into a unit test might not be easy either... and that's when you have the platform & compiler at hand.

What I'm looking for is a repository that tells me which versions of g++, clang++ and msvc++ suffers from fatal bugs for supporting C++11 (i'm not talking about missing features, when features are not there I work around them). I would then fatal crash when building with them in the build system. Nice feature is, I'm not even forced to hit a bug to ban a compiler (so I'm saving myself future trouble).

Does such a list exist?

Community
  • 1
  • 1
Gurg Hackpof
  • 1,304
  • 1
  • 13
  • 26
  • 1
    Each compiler team has their own public bug tracker. – R. Martinho Fernandes Jun 26 '13 at 12:48
  • Do you include bugs like MSVC's lack of correct template isntantiation? Because that's not going to change anytime soon. – Mooing Duck Jun 26 '13 at 18:04
  • Since you run 3 compilers and if 2 of them work with a feature but not the third then it's likely that the third compiler lacks support or has a bug. Even in C++98, with relatively large code, it's possible that you encounter incompatibilities between different compilers and you have to do something about. Making a single list for multiple compilers would be painful. – a.lasram Jun 27 '13 at 00:43

2 Answers2

14

This is probably not the answer you are looking for, but I believe the correct way to deal with this is to have a white-list, rather than a black-list. In other words, have a list of compilers that you know works, and if the customer tries to build using a different version than the ones you have tested with, you issue a warning message as part of the build script saying something like this:

This compiler is not supported, please see http://www.example.com/list_of_supported_compilers.html for a list of compilers we support. If you choose to continue using this compiler, feel free to do so, but don't expect full support from our tech-support, if you find a problem.

The reason I say this is that:

  1. You will not be able to prove that EVERY version other than what is on your blacklist works correctly. You can, however, for whatever testcases you have, prove that compiler X version a.b.c-d works [this doesn't mean that this compiler is bug free - just that you haven't hit any of those bugs in your testing!]
  2. Even if the compiler is "known good" (by whatever standard that is defined), your particular code may trigger bugs that affect your code.

Any sufficiently large software (or hardware) product will have bugs. You can only show that your software works by testing it. Relying on external "there is known bug in version such and such of compiler X" will not help you avoid bugs affecting your code. Having said that, most compilers are fairly well tested, so you (usually) need to do some fairly unusual/complicated things to make the compiler fail.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • 1
    this doesnt cover for (idiotic!!!) not implemented regex in one compiler that I wont name and the fact that afaik at least 2 compilers have screwed up clocks(afaik 1 has just 1 clock that placeholdes for all 3) other one has steady clock that isnt steady :) - by this I mean it is hard to test for this bugs esp the steady clock one so you need to find a bug list... – NoSenseEtAl Jun 26 '13 at 15:13
  • @NoSenseEtAl: It does cover that. If regex isn't implemented, I'm pretty sure the code either won't compile, or at least testing of regex will show up as erroneous from not getting the correct results. And assuming you have some reasonable way to test for messed up clocks that doesn't rely on the clock implementation being correct in the first place, we can test for that too [one could, for example, requests the time from a network timeserver, runs some of the production code for X amount of time, and then requests time from a timeserver again, verifying that the different isn't too large... – Mats Petersson Jun 26 '13 at 15:17
  • actually that compiler is famous for returning false or true(i dont remember exactly) for all regexes :) but it does compile :) – NoSenseEtAl Jun 26 '13 at 15:55
  • Well, then you test something that SHOULD make the other value, and it will show up as "not what you expected". – Mats Petersson Jun 26 '13 at 16:50
  • I agree, point is that you dont want to end up reimplementing tests for those compilers so bug list is useful. :) Also "implemented atm" list :) – NoSenseEtAl Jun 26 '13 at 16:52
  • Yes, but you still want to test that the code USING whatever the feature works - and if you use regex in your code, then you probably want to make sure it works for both "is there" and "isn't there". I'm not saying you should implement "test if compiler supports regex" (although if it's important, you may need to find a workaround for lack of regex, but that's a different matter). – Mats Petersson Jun 26 '13 at 17:31
4

Investigate Boost.Config, in particular the header <boost/config.hpp>.

This includes a large group of macros for a wide variety of compilers (and different versions there of) which indicate which C++ features are enabled, broken etc. It also includes a comprehensive test suite which can be used to test any new compiler for missing features etc.

TemplateRex
  • 69,038
  • 19
  • 164
  • 304
Robert Ramey
  • 1,114
  • 8
  • 16