It fails to compile using g++ 6.1.x

[fabianfrz]

g++ -c -o obj/dbg/re2/dfa.o  -std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I.   -O3 -g re2/dfa.cc
re2/dfa.cc: In Konstruktor »re2::DFA::State::State()«:
re2/dfa.cc:95:10: Fehler: unbekannte Feldgröße in »delete«
   struct State {
          ^~~~~
re2/dfa.cc: In Elementfunktion »re2::DFA::State* re2::DFA::CachedState(int*, int, re2::uint)«:
re2/dfa.cc:703:9: Anmerkung: erzeugte Methode »re2::DFA::State::State()« zuerst hier erfordert 
   State state;
         ^~~~~
make: *** [Makefile:190: obj/dbg/re2/dfa.o] Fehler 1

When I forced it to use clang++ with "make CXX=clang++ test" it worked.

Versions:
clang version 3.8.0 (tags/RELEASE_380/final)
g++ (GCC) 6.1.1 20160707

Translation of the error message to english (if that helps you):
re2/dfa.cc:95:10: Error: unknown array size in »delete«

[junyer]

Ouch! :(

As per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932, this seems to be due to a regression in GCC 6.1. For now, you should be able to work around the problem by changing the flexible array member to a zero-sized array member as follows:

    std::atomic<State*> next_[0];    // Outgoing arrows from State,

I will let you know what the GCC folks say.

[junyer]

Martin Sebor said that it's actually https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71147, which was fixed a couple of months ago. However, the 20160707 snapshot should have included that fix, so I will have to follow up.

[junyer]

It's both of those bugs, apparently. :)

[fabianfrz]

Got an update but the problem does still appear.

Current version:
gcc (GCC) 6.1.1 20160802

[junyer]

Alas, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932 has not yet been fixed.

[tmsimont]

@junyer Where did you put this fix:

std::atomic<State*> next_[0];    // Outgoing arrows from State,

[junyer]

stefanv@86503cb is an example of the workaround.

[LordAro]

Out of interest, is there any reason you couldn't make next_ a vector?

[junyer]

next_ used to be a pointer, but I changed it in commit c78a2a5 for performance reasons. Changing it to a std::vector<> would introduce a similar pointer chase with a similar performance hit.

[jhseu]

It looks like Ubuntu 16.10 includes gcc 6.2, which still has this bug. TensorFlow depends on re2 at the moment, so it also breaks the TensorFlow build in the latest version of Ubuntu. Could we submit a workaround for now?

[jhseu]

Sent a proposed fix at #122 that avoids both flexible array members and undefined behavior.

[junyer]

It's unfortunate that this bug hasn't been fixed yet, but I'd prefer not to throw the baby out with the bathwater, so I'm going to commit the workaround that I've described previously.

[ghost]

Hasn't this been resolved in b94b7cd?

[junyer]

I'm keeping this open until the GCC folks have fixed the regression because I'll have to tweak the workaround if, for example, the regression still exists in 7.0.

[junyer]

No one has reported breakage with GCC 7.x and our build matrix on Travis CI is clean. I'm going to adjust the comment on the workaround and then close this bug.

[stac47]

Hello,
For information, I got this problem with gcc 10 and C++20 support activated. I reported this here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93618.
I worked around the issue the same way you did in commit b94b7cd
Probably a temporary issue then.
Regards,

[junyer]

Thanks for letting me know! If the bug isn't fixed in time for the GCC 10.0 release, please feel free to file a new issue for RE2 to extend the workaround. (Otherwise, I will presumably take care of it when I add GCC 10.x to the Travis CI matrix.)