[Bug c++/95976] New: [[no_unique_address]] on union members has the opposite-of-intended effect

[metaprogrammingtheworld at gmail dot com]

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

Bug ID: 95976
   Summary: [[no_unique_address]] on union members has the
opposite-of-intended effect
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: metaprogrammingtheworld at gmail dot com
  Target Milestone: ---

When using [[no_unique_address]] with union members, ironically, each member is
now given a unique address! Without [[no_unique_address]], the layout is as one
would expect. This is particularly unfortunate since it means that a union's
size grows in proportion to the number of members when using
[[no_unique_address]]!

Example:

//
struct empty {};

union no_attribute_t
{
  empty _0;
  empty _1;
};

union with_attribute_t
{
  [[no_unique_address]] empty _0;
  [[no_unique_address]] empty _1;
};

constexpr no_attribute_t no_attribute{};
constexpr with_attribute_t with_attribute{};

// This succeeds
static_assert( _attribute._0 == _attribute._1 );

// This fails
static_assert( _attribute._0 == _attribute._1 );
//

[Bug libstdc++/85517] std::variant exception safety problems

[metaprogrammingtheworld at gmail dot com]

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

Matt Calabrese  changed:

   What|Removed |Added

 CC||metaprogrammingtheworld@gma
   ||il.com

--- Comment #2 from Matt Calabrese  
---
Example copy-assign non-compliance:

//

#include 

struct bar
{
  bar() noexcept = default; 
  bar(bar&&) { /*never throws, but not noexcept*/ }
  bar(bar const&)  // A copy constructor that throws.
  {
throw 0;
  }

  bar& operator=(bar&&) noexcept = default;
  bar& operator=(bar const&) noexcept = default;
};

int main()
{
  std::variant v1, v2 = bar();

  try
  {
v1 = v2;
  }
  catch( int )
  {
return 0;
  }

  return 1;
}

[Bug c++/52757] New: [C++11] A lamba functions is not able to be used as a function pointer when passed as an explicit template argument

[metaprogrammingtheworld at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52757

 Bug #: 52757
   Summary: [C++11] A lamba functions is not able to be used as a
function pointer when passed as an explicit template
argument
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: metaprogrammingthewo...@gmail.com


The following are two simple test-cases for what appears to be the same
problem. The main issue is that you can't use a lambda function as a template
argument where the template parameter type is a function pointer type. It seems
that this happens because there is no constexpr conversion operator from the
lambda function type to the corresponding function pointer type (in places
where the pointer is not required to be a compile-time constant, the conversion
works properly, as expected).

First test-case:

//
template int (*)()  struct foo;
typedef foo [] { return 0; }  bar;
//

main.cpp:2:31: error: could not convert template argument '{}' to 'int (*)()'
main.cpp:2:36: error: invalid type in declaration before ';' token



Second test-case (error message may shed light on the root of the problem):

//
constexpr int (*foo)() = [] { return 0; };
//

main.cpp:1:41: error: 'lambda()::operator int (*)()() const' is not a
constexpr function

[Bug c++/52757] [C++11] A lamba functions is not able to be used as a function pointer when passed as an explicit template argument

[metaprogrammingtheworld at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52757

--- Comment #2 from Matt Calabrese metaprogrammingtheworld at gmail dot com 
2012-03-28 20:10:02 UTC ---
Hmm. That seems artificially limiting, but thanks for looking it up -- sorry
for the erroneous bug report.