[Bug c++/91891] [7 Regression] std::function with lambda default initializer in aggregate construction causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91891 --- Comment #4 from Peter Bindels --- For posterity, #include #include #include #include #include template std::future make_ready_future(T t); struct y { intv; std::function v2 = [this]() { v; }; }; template auto xx(Ts... ts) { return make_ready_future(y{ ts... }); } int main() { auto f = xx(); }
[Bug c++/32505] New: Partial specialization halfway accepted after instantiation
The following code produces predictable but odd output. The compiler should either generate a warning for this case or throw away the instantiation of the type upon encountering the better-matching partial specialization, somehow keeping it for code above the given line. template struct A { T o; }; int sizeofa = sizeof(A); template struct A { T o[5]; }; int newsizeofa = sizeof(A); int main() { printf("%d, %d, %d\n", sizeofa, sizeof(A), sizeof(A)); } The given output is 4, 4, 40, whereas the expected output would be 4, 20, 40. It appears that the specialization is accepted for any type not yet instantiated. Configured with: ../gcc-4.1.2/configure --prefix=/usr --enable-shared --enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --with-arch=i486 --target=i486-slackware-linux --host=i486-slackware-linux gcc version 4.1.2 -- Summary: Partial specialization halfway accepted after instantiation Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dascandy at gmail dot com GCC build triplet: i486-slackware-linux GCC host triplet: i486-slackware-linux GCC target triplet: i486-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32505
[Bug c++/32505] Partial specialization halfway accepted after instantiation
--- Comment #1 from dascandy at gmail dot com 2007-06-25 20:51 --- The problem doesn't produce a warning when compiled with -Wall -Wextra -pedantic. One of these (I expect -Wall is the best fit) should produce a warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32505
[Bug c++/91891] New: std::function with lambda default initializer in aggregate construction causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91891 Bug ID: 91891 Summary: std::function with lambda default initializer in aggregate construction causes ICE Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dascandy at gmail dot com Target Milestone: --- https://godbolt.org/z/_XP2No Confirmed working on 6.x, 8.x and 9.x, but broken on all 7.x available on Godbolt. Example is mostly minimized, but not completely.
[Bug c++/91892] New: [5.x,6.x ARM] Having a global pair causes code gen bug for init list of pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91892 Bug ID: 91892 Summary: [5.x,6.x ARM] Having a global pair causes code gen bug for init list of pair Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dascandy at gmail dot com Target Milestone: --- https://godbolt.org/z/Q3BQRS Code that sees the global first generates 16-byte aligned register allocation for loading an initializer_list. Code that does not see the global first generates 8-byte aligned register allocation for the same initializer_list. Net result is that the pair is stored in r1/r2 (left tab) and loaded from r2/r3 (right tab). Confirmed working normally on 7.x+. Generates an ABI warning on 6.x, but also generates broken code. The warning might be this problem, but in that case I'd expect the other half to compile at least in the same way.
[Bug c++/91892] [5.x,6.x ARM] Having a global pair causes code gen bug for init list of pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91892 --- Comment #2 from Peter Bindels --- Good to know. Thanks for the quick reply!
[Bug web/45688] New: Typo in __attribute__((version-id)) docs
> HP-UX system header files may use version level functioning for some system > calls. This is a very amusing (what I assume to be) typo in the documentation of function-level versioning. Not sure this is the right bug tracker but this is one that I know... -- Summary: Typo in __attribute__((version-id)) docs Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dascandy at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
[Bug web/45688] Typo in __attribute__((version-id)) docs
--- Comment #1 from dascandy at gmail dot com 2010-09-16 10:23 --- http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes The link where the typo is to be found. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688