[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 functional
extern C void* malloc(size_t) { abort(); }
struct X
{
void operator()() { }
};
void foo() { }
int main()
{
std::functionvoid() f1((static_castvoid (*)()([]{}))); // OK
std::functionvoid() f2(foo); // OK
std::functionvoid() f3((X())); // abort
std::functionvoid() f4([]{}); // abort
}
[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 vector
template typename T
struct Container : public std::vectorint
{
typedef std::vectorint vec;
void swap(Container rhs)
{
vec::swap(rhs);
}
};
int main()
{
Containerint ca;
Containerint cb;
ca.swap(cb);
return 0;
}
$ g++ -std=c++11 nothrow-ice.cpp
nothrow-ice.cpp: In instantiation of 'void ContainerT::swap(ContainerT)
[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*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
gcc/cp/call.c:7957
0x63abf8 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, 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 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 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 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] 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 #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] 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 boost/exception_ptr.hpp
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++/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++/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=optimized out) 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
