What is the state of GCC5?

I finished now my first compile compilation tests against the large code base using GCC5 (or GCC4 as you call it but version is 5.4.x or something like this if I’m not mistaken). The results are somewhat mixed. I know the GCC4 one is not supported but some behavior makes me quite anxious.

One test module contains the Bullet library. It contains an aligned object allocator class which in turn uses placement new. This very simple and unproblematic “new” line causes an “internal compiler error”. How comes the GCC5 version in Haiku drops into an internal compiler error on something trivial as a placement new? Is the GCC5 heavily modified or not build from genuine GCC5 source base? On my system I’ve got 5.4.0 and everything works totally fine.

Something similar happens withe the Theora library. It’s a simple “a.x = float-value;” line which drops the compiler into “internal compiler error”.

I’m on nightly build updated with pkgman.

It is not heavily modified, but there are some patches. Our sources for gcc are hosted here:
In http://cgit.haiku-os.org/buildtools/log/gcc you can see the history and patches that were made. Most revolve around tweaking the configuration for Haiku and enabling features as we need. I don’t expect these things to end up with an internal error.

It would be nice to have some extra information:

  • Which version of Haiku are you using? gcc2hybrid, “gcc4”/x86, or x86_64?
  • Which hrev (you can see this in Aboutsystem)?
  • Which version of the compiler? (gcc -v or gcc-x86 -v)

Here goes nothing:

  • Haiku-Version: gcc4/x86 (is x86_64 more stable? i would prefer 64bit)
  • hrev 50494
  • gcc version 5.4.0 (2016_06_04) [i’m not using gcc2, setarch in terminal]

Concerning the error this is what I get:

Case 1: Placement New:
Bullet/LinearMath/btAlignedObjectArray.h:79: Internal compiler error.
Bullet/LinearMath/btAlignedObjectArray.h:79: Please submit info to Oliver Tappe gcc@hirschkaefer.de.


new (&dest[i]) T(m_data[i]); // T is templated class

Case 2: Harmless assignment
dethVideoDecoder.cpp: In method void dethVideoDecoder::DefConvParams(dethVideoDecoder::sConversionParamers &)': dethVideoDecoder.cpp:362: Internal compiler error, output_operand_lossageinvalid expression as operand’


convParams.c4 = 1.772f; // c4 is float

This compiler is really strange. The following code for example fails to compile on Haiku (but works on all other systems I tried it on):

class TestClass{

class TestClass2{
TestClass2(const TestClass& test){}

// somewhere inside code

This fails with an error like “parameter type omitted”. It’s just a temporary object used as constant reference in a constructor call. This compiler here gets me :confused:

That snippet compiles just fine here, both with gcc5 and gcc2. So there must be something broken in your Haiku install.

I’ve downloaded and installed the nightly image without any changes and am updating it daily with pkgman. I doubt something is wrong on it. Granted this is a simplified code snippet out of my head to illustrate the situation in which the compiler fails. I assume it needs a larger function/code base before messing up the internal states. Nevertheless the compiler is failing to compile in certain situations no other GCC 5.4 does with the very same code base on other systems.

I’ll try to see to produce a complete sample file tomorrow which shows the bug without the entire code base around it.

I’ve got difficulty to produce a simple source file showing the problem. Starts to smell like memory bug inside gcc triggered by larger source base (and i’ve got some source files which are quite large). I can’t seem to make a simple example. That said I noticed the Haiku image does have memory issues. For example on terminals if I delete (back-space) soemthing it can happen strange things happen like character elsewhere vanishing and saving the file then (for example while using nano) saves broken lines I didn’t edit. Somebody else seeing similar problems?

As a side note… can I cross-compile from Linux to Haiku? This way I could at least finish my tests.

I tried now the 64-bit nightly image. With this one the compiler problems vanished. Then I tried again the 32-bit hybrid variant with the same problems. Looks like the 32-bit hybrid is FUBAR. I’ll stick now to the 64-bit version which anyways is more to my liking than the 32-bit one. No idea what’s broken with the 32-bit compiler.