Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compilation fails with gcc trunk (futur gcc 11), protobuf 3.15.0 and -std=gnu++20: const_cast is not accepted in a constexpr expression #8310

Closed
Romain-Geissler-1A opened this issue Feb 18, 2021 · 2 comments

Comments

@Romain-Geissler-1A
Copy link
Contributor

Hi,

All is in the title: I tried to compile protobuf 3.15.0 with gcc trunk and -std=gnu++20, and it fails with this error:

google/protobuf/unittest_lite.pb.cc:155:86: error: 'constinit' variable 'protobuf_unittest::_TestAllTypesLite_default_instance_' does not have a constant initializer
  155 | PROTOBUF_ATTRIBUTE_NO_DESTROY PROTOBUF_CONSTINIT TestAllTypesLiteDefaultTypeInternal _TestAllTypesLite_default_instance_;
      |                                                                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./google/protobuf/unittest_lite.pb.h:25,
                 from google/protobuf/unittest_lite.pb.cc:4:
google/protobuf/unittest_lite.pb.cc:155:86:   in 'constexpr' expansion of 'protobuf_unittest::TestAllTypesLiteDefaultTypeInternal()'
google/protobuf/unittest_lite.pb.cc:149:7:   in 'constexpr' expansion of '((protobuf_unittest::TestAllTypesLiteDefaultTypeInternal*)this)->protobuf_unittest::TestAllTypesLiteDefaultTypeInternal::<anonymous>.protobuf_unittest::TestAllTypesLiteDefaultTypeInternal::<unnamed union>::_instance.protobuf_unittest::TestAllTypesLite::TestAllTypesLite((google::protobuf::internal::ConstantInitialized(), google::protobuf::internal::ConstantInitialized()))'
google/protobuf/unittest_lite.pb.cc:97:5:   in 'constexpr' expansion of '((protobuf_unittest::TestAllTypesLite*)this)->protobuf_unittest::TestAllTypesLite::default_string_.google::protobuf::internal::ArenaStringPtr::ArenaStringPtr(0)'
../../src/google/protobuf/arenastring.h:179:9:   in 'constexpr' expansion of '((google::protobuf::internal::ArenaStringPtr*)this)->google::protobuf::internal::ArenaStringPtr::tagged_ptr_.google::protobuf::internal::TaggedPtr<std::__cxx11::basic_string<char> >::TaggedPtr(default_value)'
../../src/google/protobuf/arenastring.h:95:14: error: conversion of 'const google::protobuf::internal::ExplicitlyConstructed<std::__cxx11::basic_string<char> >*' null pointer to 'google::protobuf::internal::ExplicitlyConstructed<std::__cxx11::basic_string<char> >*' is not a constant expression
   95 |       : ptr_(const_cast<ExplicitlyConstructed<std::string>*>(ptr)) {}
      |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It seems that const_cast can't be used in a constexpr expression, so the constinit instantiation failed.

Note: one way to avoid reinterpret_cast or other kind of forbidden casts in constexpr expression might be to use some union struct having the multiple types you want to cast things into.

Cheers,
Romain

acozzette added a commit to acozzette/protobuf that referenced this issue Feb 19, 2021
Our use of constinit does not seem to work with GCC yet (see
protocolbuffers#8310), so this
commit disables it on GCC for now.

This commit also updates mutex.h to work around the fact that MinGW's
std::mutex apparently does not have a constexpr constructor. We already
have this kind of workaround for MSVC, so we can just use the same
workaround.
@acozzette
Copy link
Member

@Romain-Geissler-1A Thanks for the bug report. I am going to disable our use of constinit for GCC until we can figure out a better solution.

acozzette added a commit that referenced this issue Feb 19, 2021
Our use of constinit does not seem to work with GCC yet (see
#8310), so this
commit disables it on GCC for now.

This commit also updates mutex.h to work around the fact that MinGW's
std::mutex apparently does not have a constexpr constructor. We already
have this kind of workaround for MSVC, so we can just use the same
workaround.
@dlj-NaN
Copy link
Contributor

dlj-NaN commented Oct 7, 2021

This no longer appears to be an issue as of gcc-12-4218-g57c7ec62ee0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants