[Bug lto/109263] New: '-g0 -ggdb -flto' gives linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109263 Bug ID: 109263 Summary: '-g0 -ggdb -flto' gives linker error Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: lukeocamden at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hello, I have not seen this before! $ echo 'int main() { }' | g++ -g0 -ggdb -flto -xc++ - /usr/bin/ld: /tmp/ccgMzjuI.ltrans0.ltrans.o:(.debug_info+0x2f): undefined reference to `g_stdin_.7138a6a3' collect2: error: ld returned 1 exit status $ g++ --version g++ (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Unfortunately my build too insists on -g0 so I am using this as a workaround: $ echo 'int main() { }' | g++ -g0 -g -ggdb -flto -xc++ - Thanks!
[Bug libstdc++/61909] Small function optimization not applied to small objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909 --- Comment #4 from lukeocamden at gmail dot com --- (In reply to Jonathan Wakely from comment #3) > (In reply to lukeocamden from comment #2) > > (In reply to Jonathan Wakely from comment #1) > > > This is by design. > > > > I don't really follow - do you mean a consequence of the design, or does the > > standard mandate copying/moving the object into the heap, or does using the > > heap have some other benefit? > > None of the above. > > I mean the author of our std::function intentionally chose to only avoid the > heap for function pointers > > /** >* Trait identifying "location-invariant" types, meaning that the >* address of the object (or any of its members) will not escape. >* Also implies a trivial copy constructor and assignment operator. >*/ If this doesn't offer a clear advantage, should I try to come up with a patch to support small objects too?
[Bug libstdc++/61909] Small function optimization not applied to small objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909 --- Comment #2 from lukeocamden at gmail dot com --- (In reply to Jonathan Wakely from comment #1) > This is by design. I don't really follow - do you mean a consequence of the design, or does the standard mandate copying/moving the object into the heap, or does using the heap have some other benefit? > I have a patch to do the optimization a bit more aggressively, but still > only for trivially copyable types and others known to be location invariant > (which should include lambdas) That would be a great start - thanks very much!
[Bug libstdc++/61909] New: Small function optimization not applied to small objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909 Bug ID: 61909 Summary: Small function optimization not applied to small objects Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lukeocamden at gmail dot com Seems like std::function only manages to avoid malloc for function pointers, but not for small objects. $ g++ --version g++ (GCC) 4.10.0 20140720 (experimental) Here's a test I ran on my Linux machine: #include extern "C" void* malloc(size_t) { abort(); } struct X { void operator()() { } }; void foo() { } int main() { std::function f1((static_cast([]{}))); // OK std::function f2(foo); // OK std::function f3((X())); // abort std::function f4([]{}); // abort }
[Bug tree-optimization/53802] Spurious 'may be used uninitialized' related to shifts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53802 lukeocamden at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from lukeocamden at gmail dot com --- Works fine with g++ (GCC) 4.9.0 20140202 (experimental)
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 53802, which changed state. Bug 53802 Summary: Spurious 'may be used uninitialized' related to shifts http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53802 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/60046] New: internal compiler error: in nothrow_spec_p, at cp/except.c:1280
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60046 Bug ID: 60046 Summary: internal compiler error: in nothrow_spec_p, at cp/except.c:1280 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lukeocamden at gmail dot com Sorry: no preprocessed source yet. $ g++ --version g++ (GCC) 4.9.0 20140202 (experimental) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat nothrow-ice.cpp #include template struct Container : public std::vector { typedef std::vector vec; void swap(Container& rhs) { vec::swap(rhs); } }; int main() { Container ca; Container cb; ca.swap(cb); return 0; } $ g++ -std=c++11 nothrow-ice.cpp nothrow-ice.cpp: In instantiation of 'void Container::swap(Container&) [with T = int]': nothrow-ice.cpp:20:13: required from here nothrow-ice.cpp:11:18: internal compiler error: in nothrow_spec_p, at cp/except.c:1280 vec::swap(rhs); ^ 0x625335 nothrow_spec_p(tree_node const*) gcc/cp/except.c:1279 0x56fff8 set_flags_from_callee(tree_node*) gcc/cp/call.c:330 0x5700c9 build_call_a(tree_node*, int, tree_node**) gcc/cp/call.c:362 0x5710f2 build_cxx_call(tree_node*, int, tree_node**, int) gcc/cp/call.c:7241 0x57c4c8 build_over_call gcc/cp/call.c:7225 0x579a0d build_new_method_call_1 gcc/cp/call.c:7887 0x579a0d build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) gcc/cp/call.c:7957 0x63abf8 finish_call_expr(tree_node*, vec**, bool, bool, int) gcc/cp/semantics.c:2306 0x5a4414 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) gcc/cp/pt.c:14625 0x5a79d8 tsubst_expr gcc/cp/pt.c:13812 0x5a6bb6 tsubst_expr gcc/cp/pt.c:13233 0x5a7971 tsubst_expr gcc/cp/pt.c:13424 0x5a67d2 instantiate_decl(tree_node*, int, bool) gcc/cp/pt.c:19690 0x5bce7b instantiate_pending_templates(int) gcc/cp/pt.c:19806 0x5d50cf cp_write_global_declarations() gcc/cp/decl2.c:4149 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 --- Comment #5 from lukeocamden at gmail dot com 2013-03-08 11:07:45 UTC --- Created attachment 29619 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29619 Generated by icc 13
[Bug c++/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 --- Comment #4 from lukeocamden at gmail dot com 2013-03-08 10:47:10 UTC --- Created attachment 29618 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29618 Preprocessed with ICC
[Bug c++/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 --- Comment #3 from lukeocamden at gmail dot com 2013-03-08 10:32:34 UTC --- Sorry for my cryptic comments about the "other object file". It's compiled with icc 13. I will attach the preprocessed source and generated assembly.
[Bug c++/56564] [4.7 Regression] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 --- Comment #1 from lukeocamden at gmail dot com 2013-03-07 16:26:39 UTC --- Created attachment 29611 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29611 Preprocessed source file
[Bug c++/56564] New: [4.7 Regression] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 Bug #: 56564 Summary: [4.7 Regression] movdqa on possibly-8-byte-aligned struct with -O3 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lukeocam...@gmail.com #include struct foo { }; int main() { boost::copy_exception(foo()); } Compiling the above with -O3 results in the following instruction being emitted: movdqa %xmm0, _ZZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep(%rip) But that symbol need not be 16-byte aligned (it's a boost::exception_ptr, which contains a boost::shared_ptr, which is just a pair of pointers). This crashes if _ZZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep comes from another object file where it is declared with 8-byte alignment. Possible duplicate of 54167? Works fine with 4.6.2 Preprocessed source is attached.
[Bug c++/54420] New: Segmentation in decl_mangling_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54420 Bug #: 54420 Summary: Segmentation in decl_mangling_context Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lukeocam...@gmail.com Created attachment 28107 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28107 Preprocessed source file Discovered when compiling llvm+lldb. Preprocessed file attached. Stack trace: #0 0x0058f3b3 in decl_mangling_context (decl=0x2bf38508) at ../.././gcc/cp/mangle.c:759 #1 decl_mangling_context (decl=0x2bf38508) at ../.././gcc/cp/mangle.c:749 #2 0x005963a4 in write_name (decl=0x2bf38508, ignore_local_scope=ignore_local_scope@entry=0) at ../.././gcc/cp/mangle.c:795 #3 0x005931b4 in write_class_enum_type (type=) at ../.././gcc/cp/mangle.c:2424 #4 write_type (type=type@entry=0x2bf4e7e0) at ../.././gcc/cp/mangle.c:1903 #5 0x00596db9 in mangle_special_for_type (type=0x2bf4e7e0, code=0xd3042e "TV") at ../.././gcc/cp/mangle.c:3445 #6 0x0051062e in get_vtable_name (type=0x2bf4e7e0) at ../.././gcc/cp/class.c:709 ...
[Bug tree-optimization/53802] New: Spurious 'may be used uninitialized' related to shifts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53802 Bug #: 53802 Summary: Spurious 'may be used uninitialized' related to shifts Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: lukeocam...@gmail.com Trivial changes in the following program suppress the warning: inline void foo(const unsigned char* mem_, unsigned int* value_) { unsigned int value = *mem_; value <<= 8; value |= *++mem_; value <<= 8; value |= *++mem_; value <<= 8; value |= *++mem_; value <<= 8; value |= *++mem_; *value_ = value; } inline void bar(unsigned char* dest_, unsigned int value_) { if (!value_) return; dest_[0] = 0; dest_[1] = value_ >> 24; dest_[2] = value_ >> 16; dest_[3] = value_ >> 8; dest_[4] = value_; } int main() { for (unsigned int number = 0x; number; number >>= 1) { unsigned char buf[5]; bar(buf, number); unsigned int val; foo(buf, &val); if (number != val) return 0; } } $ gcc main.cpp -O -Wall main.cpp: In function 'int main()': main.cpp:6:19: warning: '*((void*)& buf +1)' may be used uninitialized in this function [-Wmaybe-uninitialized] main.cpp:31:19: note: '*((void*)& buf +1)' was declared here main.cpp:12:19: warning: '*((void*)& buf +4)' may be used uninitialized in this function [-Wmaybe-uninitialized] main.cpp:31:19: note: '*((void*)& buf +4)' was declared here main.cpp:10:19: warning: '*((void*)& buf +3)' may be used uninitialized in this function [-Wmaybe-uninitialized] main.cpp:31:19: note: '*((void*)& buf +3)' was declared here main.cpp:8:19: warning: '*((void*)& buf +2)' may be used uninitialized in this function [-Wmaybe-uninitialized] main.cpp:31:19: note: '*((void*)& buf +2)' was declared here