[Bug c++/51675] [C++11][4.7 Regression] Cannot create constexpr unions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51675
Daniel Wolf changed:
What|Removed |Added
CC||nephatrine at gmail dot com
--- Comment #4 from Daniel Wolf 2012-02-03
06:24:12 UTC ---
(In reply to comment #1)
> More information: initializing in the constructor doesn't work, either.
>
> union foo
> {
> int x;
> short y;
>
> constexpr foo() : x(0) { }
> };
>
> Also does not compile.
This code does not compile with the latest trunk.
error: uninitialized member 'foo::y' in 'constexpr' constructor
> union foo
> {
> int x = 0;
> short y;
>
> constexpr foo() = default;
> };
This does compile... but I cannot instantiate a constexpr foo. Adding this
line:
constexpr foo test;
Gives me the following output:
g++-4.7 -std=gnu++11 -o Test.o -c Test.cpp
Test.cpp: In function 'int main(int, char**)':
Test.cpp:35:16: error: uninitialized const 'test' [-fpermissive]
Test.cpp:6:7: note: 'const union foo' has no user-provided default constructor
Test.cpp:11:15: note: constructor is not user-provided because it is explicitly
defaulted in the class body
Test.cpp:9:11: note: and the implicitly-defined constructor does not initialize
'short int foo::y'
Test.cpp:35:16: error: 'constexpr foo::foo()' called in a constant expression
Test.cpp:11:15: note: 'constexpr foo::foo()' is not usable as a constexpr
function because:
Yeah... the last line ends with a colon but no followup. Might want to reopen
this...
[Bug c++/51910] New: -frepo linking failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910 Bug #: 51910 Summary: -frepo linking failure Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: nephatr...@gmail.com Created attachment 26388 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26388 Minimal Testcase I'm having an issue with -frepo apparently not instantiating typeinfo/vtables at least on x86_64 (have not tested on other archs). It is creating .rpo files, but it cannot find the functions at the relinking stage. I've attached a minimal testcase. The code compiles cleanly on GCC 4.6.2 without any errors, but 4.7 chokes on it. Here is the output of 'make' on my system for the testcase. g++ -frepo -o main.o -c main.cpp g++ -frepo -o testcase main.o collect: recompiling main.cpp collect: relinking collect2: error: '_ZN3FooIiED0Ev' was assigned to 'main.rpo', but was not defined during recompilation, or vice versa main.o:main.cpp:function Foo::~Foo(): error: undefined reference to 'Foo::~Foo()' main.o:main.cpp:function Bar::~Bar(): error: undefined reference to 'Foo::~Foo()' main.o:main.cpp:function vtable for Foo: error: undefined reference to 'Foo::~Foo()' main.o:main.cpp:function vtable for Foo: error: undefined reference to 'Foo::haggis()' main.o:main.cpp:function typeinfo for Foo: error: undefined reference to 'typeinfo name for Foo' collect2: error: ld returned 1 exit status make: *** [testcase] Error 1
[Bug c++/51910] [4.7 Regression] -frepo linking failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910 --- Comment #2 from Daniel Wolf 2012-01-20 03:44:05 UTC --- (In reply to comment #1) > Is there a reason why you are using -frepo ? It is not as useful as it was > before elf had comdat. Removing -frepo seems to bloat my executable. The GCC documentation (http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html) seemed to portray -frepo as being useful given that the alternatives I'd face are either unnecessarily larger executables or reworking a large header-only template library written in the "Borland model." I suppose explicit instantiation with no implicit instantiation is also an option, but seems needlessly tedious and error-prone to maintain particularly when you have many developers working on a project. >From your comment, I take it there is some way to enable something like COMDAT folding to remove the duplicated function instantiations? If so, what flag(s) would I need to add to the project to enable this? Either way, I'd think the issue should probably be looked at. If -frepo is considered deprecated or just too complicated or unimportant to fix, it should probably just be removed altogether.
[Bug c++/51910] [4.7 Regression] -frepo linking failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910 --- Comment #4 from Daniel Wolf 2012-01-20 04:46:33 UTC --- (In reply to comment #3) > That is the point of COMDAT so that duplicated function instantiations are not > done. They definitely are or the executable wouldn't be larger without -frepo, right? > > Removing -frepo seems to bloat my executable. > Have you tried using -Wl,--gc-sections ? Enabling that flag does make the code smaller, but the combination of -frepo and --gc-sections is smaller still, with the savings exactly equal to the sum of the savings of using each flag individually. The flags seem completely orthogonal in their function. This all is getting pretty tangential to the reported bug, though. Is there a better place to continue this particular discussion? For now I can just leave out the flag and get the project to compile, albeit larger, but it's not an ideal long-term solution. Of course, whether or not an alternative exists doesn't invalidate the bug at hand. What's the point making -frepo available if it does not work?
[Bug c++/51910] [4.7 Regression] -frepo linking failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910 --- Comment #5 from Daniel Wolf 2012-01-22 22:10:17 UTC --- If someone has any ideas about what the issue might be or can point me in the right direction, I'll try to suss this out myself and post a patch if possible. I'm just not very familiar with GCC's internals. The .rpo files created by the working versions (4.6.1 & 4.6.2 - also confirmed also by Ubuntu Linaro GCC maintainer) and trunk are identical aside from having a different -frandom-seed value.
