[Bug libstdc++/93208] duplicated memory_resource, monotomic_buffer_resource vtable, type_info d/t all-inline virtual functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93208 --- Comment #7 from Marc Mutz --- Thanks!
[Bug libstdc++/93208] duplicated memory_resource, monotomic_buffer_resource vtable, type_info d/t all-inline virtual functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93208 Marc Mutz changed: What|Removed |Added Version|10.0|9.1.0 --- Comment #1 from Marc Mutz --- Also in 9.1, according to gotbolt.org. Making the dtors out-of-line should be a binary-compatible.
[Bug libstdc++/93208] New: duplicated memory_resource, monotomic_buffer_resource vtable, type_info d/t all-inline virtual functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93208 Bug ID: 93208 Summary: duplicated memory_resource, monotomic_buffer_resource vtable, type_info d/t all-inline virtual functions Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: marc at kdab dot com Target Milestone: --- Both `memory_resource` and `monotonic_buffer_resource` have all virtual methods inline, so their vtables (and rtti) are not pinned to libstdc++.so, but are duplicated in each executable (.so or application), causing minor executable code bloat and false negative dynamic_casts. Expected: At least their dtor should be out-of-line, so the vtable and the type_info object are emitted in libstdc++.so, and only there.
[Bug c++/92856] incorrectly accepts invalid C++11 braced initialisation of double from long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92856
--- Comment #3 from Marc Mutz ---
Indeed, I didn't check that it actually fails in SFINAE. Sorry for that.
This works:
// https://godbolt.org/z/EfJmS4
#include
#include
template
using nonnarrowing_test = decltype(To{std::declval()});
template
using is_narrowing =
std::negation>;
static_assert(is_narrowing{});
static_assert(!is_narrowing{});
[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55783 Marc Mutz changed: What|Removed |Added CC||marc at kdab dot com --- Comment #15 from Marc Mutz --- *** Bug 92856 has been marked as a duplicate of this bug. ***
[Bug c++/92856] incorrectly accepts invalid C++11 braced initialisation of double from long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92856 Marc Mutz changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Marc Mutz --- *** This bug has been marked as a duplicate of bug 55783 ***
[Bug c++/92856] New: incorrectly accepts invalid C++11 braced initialisation of double from long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92856
Bug ID: 92856
Summary: incorrectly accepts invalid C++11 braced
initialisation of double from long double
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marc at kdab dot com
Target Milestone: ---
The following code:
// https://godbolt.org/z/tWa2dr
int main() {
extern long double ld;
double d{ld};
}
is invalid according to [dcl.list.init]3.9
(http://eel.is/c++draft/dcl.init.list#3.9): regardless of a target's actual
size for these types, long double -> double is considered a narrowing
conversion [dcl.list.init]/7 (http://eel.is/c++draft/dcl.init.list#7.2), and
the compiler cannot use the constant expression loophole here.
Clang and MSVC correctly error on this.
Actual behaviour: GCC only warns (-Wnarrowing), even with -pedantic.
Expected behaviour: GCC does not accept this code.
This bug exists in all compiler versions, afaict (4.7.4, 4.8.3, 9.1, trunk).
[Bug c++/59423] Misleading warning when 'enum class' base type unresolved: elaborated-type-specifier for a scoped enum must not use the ‘class’ keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59423
marc at kdab dot com changed:
What|Removed |Added
CC||marc at kdab dot com
--- Comment #2 from marc at kdab dot com ---
Still in GCC 10. The error message and surrounding warning are pointing at
everything _but_ where the error is:
:1:6: warning: elaborated-type-specifier for a scoped enum must not use
the 'class' keyword
1 | enum class IntegerSystem : int8 {};
| ^
| -
:1:12: error: use of enum 'IntegerSystem' without previous declaration
1 | enum class IntegerSystem : int8 {};
|^
:1:26: error: expected unqualified-id before ':' token
1 | enum class IntegerSystem : int8 {};
| ^
[Bug c++/22395] -Weffc++ shouldn't warn about non-virtual dtor of private subclasses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22395 --- Comment #8 from marc at kdab dot com --- I don't think Effective C++ is the benchmark any more, so water under bridges that have already burned, but fwiw: contrary to C.127 these days, I learned this rule as "A base class's destructor should be public and virtual or else protected and non-virtual" (implying that, otherwise, don't use inheritance, but aggregation; could've been from CS:101 from Andrej and Herb).
[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90379 marc at kdab dot com changed: What|Removed |Added CC||marc at kdab dot com --- Comment #9 from marc at kdab dot com --- The patch does no longer apply to current gcc-9-branch, which, however, still has the problem. The_Atomic stuff is easy to spot, though, and I can confirm this fixes it for me, too (though I guess it's a hotfix, and nothing mergeable, otherwise it would already be merged?).
[Bug c++/90372] New: [x64][missed optimization] pushes unused r12 onto stack on unique_ptr use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90372 Bug ID: 90372 Summary: [x64][missed optimization] pushes unused r12 onto stack on unique_ptr use Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marc at kdab dot com Target Milestone: --- In the following example: https://godbolt.org/z/jHSYue one(), using std::unique_ptr, pushes r12 to the stack just to pop it back at the end. r12 does not appear to be used in-between. The similar two() function does not do this, even though the rest of the function (except the stack unwind trampoline) is instruction-by-instruction identical. Expected: r12 is not pushed/popped.
[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343 --- Comment #10 from marc at kdab dot com --- I cannot confirm that this is fixed in 7.0.0 20161005. This is at commit: PR sanitizer/77823. I still see these errors.
[Bug sanitizer/70342] g++ -fsanitize=undefined never finishes compiling (>24h) in qtxmlpatterns test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70342 marc at kdab dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #13 from marc at kdab dot com --- confirmed fixed in gcc 6.1.1 20160624
[Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621
--- Comment #7 from marc at kdab dot com ---
Retesting with GCC 6.1, it looks better now:
$ g++ -O2 -o emplace-vs-push_back{.pb,.cpp}
$ g++ -O2 -o emplace-vs-push_back{.eb,.cpp} -DEMPLACE_BACK
$ strip emplace-vs-push_back.*
$ size emplace-vs-push_back.*
textdata bss dec hex filename
4474 680 85162142a emplace-vs-push_back.eb
4830 680 85518158e emplace-vs-push_back.nt
5083 656 857471673 emplace-vs-push_back.pb
somewhat at the expense of pessimising push_back(), which used to be 500b
smaller in Comment 3, but at least the relation between emplace_back and
push_back, and between emplace_back(char[2], char[2], char[2]) and
emplace_back(std::string, std::string, std::string) are now as expected.
[Bug sanitizer/70342] New: g++ -fsanitize=undefined never finishes compiling (>24h) in qtxmlpatterns test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70342 Bug ID: 70342 Summary: g++ -fsanitize=undefined never finishes compiling (>24h) in qtxmlpatterns test suite Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: marc at kdab dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Created attachment 38050 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38050=edit Preprocessed source The following command line never finishes compiling (killed after ~24h of compiling in the background) on GCC 6.0.0 trunk: $ g++ -c -g -O2 -fsanitize=undefined -fno-omit-frame-pointer -Wall -W -D_REENTRANT -fPIC -o .obj/XSDTestSuiteHandler.o XSDTestSuiteHandler.ii the same command without the -fsanitize option finishes in < 3sec.
[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343 marc at kdab dot com changed: What|Removed |Added CC||marc at kdab dot com --- Comment #2 from marc at kdab dot com --- Confirmed that GCC 6.0.0 trunk, too, fails with identical errors when trying to compile Qt 5 with PCH. Only on some files, though. 213 object files get created for QtCore, 50 fail.
[Bug other/70118] UBSan claims misaligned access in SSE instrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118 marc at kdab dot com changed: What|Removed |Added CC||marc at kdab dot com --- Comment #1 from marc at kdab dot com --- Confirmed on gcc version 6.0.0 20160304
[Bug c++/53637] NRVO not applied where there are two different variables involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637 --- Comment #5 from marc at kdab dot com --- You have a very narrow test of NRVO. You're using a completely transparent type, though I give you that defining the copy and move ctors in a separate TU does not change the outcome. At some point I'll check whether having them in a different dll/so/dylib will change something. And you consequently don't test X's which are not created at the top-level scope. These bug reports are about other cases. NRVO should kick in whenever it is statically known which object is returned. I will hand you a pull-request for some more soon, but in Qt, we have also returns of rvalues from some switch cases mixed with returns of case-local lvalues from others, which I didn't cover, yet. I only added slight variations of the existing tests. You seem to have an impressive array of compilers to run the test against, and I invite you to add more cases where lvalues are returned where NRVO could be used and update your interesting paper.
[Bug c++/53637] NRVO not applied where there are two different variables involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637 --- Comment #3 from marc at kdab dot com --- This really should be top priority. But no comment on it for almost three years by GCC devs.
[Bug c++/58055] [meta-bug] RVO / NRVO improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055 --- Comment #6 from marc at kdab dot com --- To expand on my previous comment: the compiler is even allowed to elide the copy if that would save a read/write from a volatile object. So I don't see how this can be implemented anywhere except the front-end.
[Bug libstdc++/65659] New: STL containers not specialized for pointer value_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65659 Bug ID: 65659 Summary: STL containers not specialized for pointer value_type Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: marc at kdab dot com The STL containers are not specialised for pointer types, leading to tons of duplicated virtually-identical binary code. Example: vectorconst T* could be implemented in terms of vectorT* vectorT* could be implemented in terms of vectorvoid* vectorshared_ptrconst T could be implemented in terms of vectorshared_ptrT vectorchared_ptrT could be implemented in terms of vectorshared_ptrvoid Is there anything that prevents this rather obvious optimisation? Allcators having the wrong type?
[Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621 --- Comment #3 from marc at kdab dot com --- Now, what is _really_ weird is that push_back(T) _calls_ emplace_back(). I also tried the magic incantation g++ --param large-unit-insns=1 \ --param inline-unit-growth=1 \ --param max-inline-insns-single=1 \ --param large-function-growth=1 \ --param large-function-insns=1 -O2 to no avail. I can get the two version to within 80 bytes of text of each other by adding -fno-exceptions, so it's probably related to that. The (implicit) move ctor of S cannot throw, but the std::string(const char*) ctor can. Ie. in the rvalue-push_back case, emplace_back only dabbles in noexcept operations, and in the 3xconst char* case, it needs to deal with three throwing ctors. I can reduce the text size to within a few hundreds of bytes by marking both emplace_back and _M_emplace_back_aux as __attribute__((always_inline)), so something prevents gcc from inlining even when turning the inlining paramters all the way up. I can also reduce the text size by passing std::strings instead of conat char*s: textdata bss dec hex filename 5628 672 40634018c4 emplace-vs-push_back.eb 4991 672 4057031647 emplace-vs-push_back.nt 4516 648 4052041454 emplace-vs-push_back.pb (where .nt is EMPLACE_BACK_NOTHROW). Still a large gap... Have we accepted another auto_ptr into the standard? :)
[Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621 marc at kdab dot com changed: What|Removed |Added Attachment #32429|0 |1 is obsolete|| --- Comment #4 from marc at kdab dot com --- Created attachment 34723 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34723action=edit New version of the test programme.
[Bug c++/53637] NRVO not applied in branches when it could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637 marc at kdab dot com changed: What|Removed |Added CC||marc at kdab dot com --- Comment #1 from marc at kdab dot com --- Similar situation in https://codereview.qt-project.org/#/c/104079/1/src/network/ssl/qsslellipticcurve_openssl.cpp,unified (click on the comment in line 61 to see GCC 4.9.3 (from svn) disassembly. Qt is full of functions structured like that and it's not an option to rewrite them all. Lawrence Crowl calls (N)RVO the most important optimisation in C++, and it's really sad that GCC doesn't apply NRVO even in those cases where there is only one possible object returned per basic block, ie. where the compiler knows which object will be returned by at the time of construction of each object. It's even more sad that this report has been sitting here, unconfirmed and ignored by the GCC developers, for 19 months.
[Bug c++/51571] No named return value optimization while adding a dummy scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51571 marc at kdab dot com changed: What|Removed |Added CC||marc at kdab dot com --- Comment #4 from marc at kdab dot com --- I would like to strongly oppose the notion that this just a missed optimisation and not very critical, really. NRVO is not just an optimisation. It's actually one that is explcitly permitted to change observable behaviour of the program and it's extremely powerful. And it it _required_ for performant C++. Just try to return a std::vector by value to see the importance of this optimisation. This is not missed optimisation. This is premature pessimisation. You could just as well stop all optimisation work for the C++ frontend until this is implemented, because any other optimisation effords are dwarfed by the overhead when NRVO is expected by the developer but not applied. Please make this a top priority. Every C++ program will benefit both in text size and in runtime performance - dramatically.
[Bug c++/58055] [meta-bug] RVO / NRVO improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055 marc at kdab dot com changed: What|Removed |Added CC||marc at kdab dot com --- Comment #5 from marc at kdab dot com --- I have no clue about the architecture of GCC, but it sounds to me that NRVO is definitely a front-end optimisation, because it's allowed to change observable behaviour. E.g., you can elide the copy ctor and dtor even if they have side effects. Once you go into some intermediate representation, the information that a set of given side effects can be entirely removed is probably irrevocably lost.
[Bug c++/64150] New: Missed optimisation opportunity with moved-from pimpl classes and a nullptr d-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64150 Bug ID: 64150 Summary: Missed optimisation opportunity with moved-from pimpl classes and a nullptr d-pointer Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marc at kdab dot com Created attachment 34162 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34162action=edit Sample program When compiling attached sample program to assembler source, the compiler emits two calls to destroy(), one for p1 and one for p2. However, it should be statically clear that p1.d == nullptr, always, so dead code elimination should remove the check for nullptr, the branch and the call to destroy(). $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/opt/gcc/trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/opt/gcc/trunk --program-suffix=-trunk --enable-checking=release --enable-languages=c,c++,go,fortran,objc,obj-c++ : (reconfigured) ../gcc/configure --prefix=/opt/gcc/trunk --enable-checking=release --enable-languages=c,c++,go,fortran,objc,obj-c++ Thread model: posix gcc version 5.0.0 20141015 (experimental) (GCC)
[Bug c++/64150] Missed optimisation opportunity with moved-from pimpl classes and a nullptr d-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64150
--- Comment #1 from marc at kdab dot com ---
(compiled with g++ -fverbose-asm -std=c++14 -g -O3 -S -o
test-moved-from-dtor.{s,cpp})
[Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621 --- Comment #2 from marc at kdab dot com --- Yes, that helps a bit, but emplace_back still generates larger code than the corresponding rvalue-push_back. Considering that the latter also needs to generate the implicitly defined move ctor for S, this is still somewhat surprising and runs counter to the motivation to have emplace_back in the first place.
