[Bug c++/91891] [7 Regression] std::function with lambda default initializer in aggregate construction causes ICE

[dascandy at gmail dot com]

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++/91892] [5.x,6.x ARM] Having a global pair causes code gen bug for init list of pair

[dascandy at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91892

--- Comment #2 from Peter Bindels  ---
Good to know. Thanks for the quick reply!

[Bug c++/91892] New: [5.x,6.x ARM] Having a global pair causes code gen bug for init list of pair

[dascandy at gmail dot com]

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++/91891] New: std::function with lambda default initializer in aggregate construction causes ICE

[dascandy at gmail dot com]

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 web/45688] New: Typo in __attribute__((version-id)) docs

[dascandy at gmail dot com]

 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

[dascandy at gmail dot com]

--- 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

[Bug c++/32505] New: Partial specialization halfway accepted after instantiation

[dascandy at gmail dot com]

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 typename T
struct A {
T o;
};

int sizeofa = sizeof(Aint *);

template typename T
struct AT * {
T o[5];
};

int newsizeofa = sizeof(Aint *);

int main() {
printf(%d, %d, %d\n, sizeofa, sizeof(Aint *), sizeof(Adouble *));
}


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

[dascandy at gmail dot com]

--- 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