G++ 4.8.2 insists simple variable members are arrays - c++

Question

This problem only occurs with g++ 4.8.2 for ARMv6 (stock pidora); it compiles without error or warning on x86_64 w/ clang 3.4.2 and g++ 4.8.3. I am having a hard time not seeing it as a compiler bug, but wanted to get some other opinions.
It involves a simple member variable that g++ keeps insisting is an array and
error: array must be initialized with a brace-enclosed initializer
The header for the class looks like this:
namespace SystemStateMonitor {
class ramInput : public input, public inputFile {
public:
typedef enum {
RATIO,
PERCENT,
KiBYTES,
MiBYTES
} style_t;
ramInput (
const std::string &label = "RAM",
style_t style = style_t::PERCENT
);
unsigned int getAvailable ();
double getDV ();
double ratio ();
protected:
style_t style;
unsigned int available;
void setStyle (style_t);
friend input* jsonInputRAM (jsonObject);
};
}
The constructor looks like this:
#define PROC_FILE "/proc/meminfo"
using namespace std;
using namespace SystemStateMonitor;
ramInput::ramInput (
const string &label,
ramInput::style_t s
) :
input (label),
inputFile (PROC_FILE),
style (s),
available (0)
{
setStyle(style);
}
And when I compile this with the ARMv6 g++, I get:
inputs/ramInput.cpp:19:14: error: array must be initialized with a brace-enclosed initializer
available (0)
^
The superclasses do not have any member "available"; there is no potential weird collision. Interestingly, if I then modify the constructor:
) :
input (label),
inputFile (PROC_FILE),
style (s)
{
available = 0;
setStyle(style);
}
I now get the same error for style (s). If I then do the same thing with style (move initialization into the body), I get the error for inputFile (PROC_FILE), which is even more bizarre because that's a super constructor call.
inputs/ramInput.cpp:17:22: error: array must be initialized with a brace-enclosed initializer
inputFile (PROC_FILE)
^
Unfortunately but not surprisingly, an SSCCE starting with this:
class test {
public:
test () : x(0) { };
unsigned int x;
};
Does not reproduce the problem.
What could be going wrong here? Am I right to believe this isn't my fault?

Answer 1

As Mike Seymour points out in comments on the question, the cascading nature of the error indicated the compiler was simply pointing to the end of the problem initialization list, rather than the correct entry. The array turned out to be in a superclass constructor default initializer:
std::array<double,2> range = { 0 }
That particular g++ chokes on that, and:
std::array<double,2> range = { 0.0, 0.0 }
But:
std::array<double,2> range = { }
Works. Good thing I didn't want any non-zero values there...