[Bug c++/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active

[dyp-cpp at gmx dot net]

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

--- Comment #1 from dyp-cpp at gmx dot net ---
Same issue if the LocalException is a non-local class with internal linkage.

[Bug c++/78651] New: Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active

[dyp-cpp at gmx dot net]

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

Bug ID: 78651
   Summary: Incorrect exception handling when catch clause uses
local class and PIC and sanitizer are active
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dyp-cpp at gmx dot net
  Target Milestone: ---

Consider the following program:


#include 

#ifndef EXCEPTION_TYPE
#  define EXCEPTION_TYPE LocalException
#endif

#define STRINGIFY(X) STRINGIFY2(X)
#define STRINGIFY2(X) #X

struct Exception {};

int main()
{
  struct LocalException {};

  try
  {
std::cout << "throwing int\n";
throw 42;
  }catch(EXCEPTION_TYPE const& d)
  {
std::cout << "caught " STRINGIFY(EXCEPTION_TYPE) "\n";
  }catch(...)
  {
std::cout << "caught ...\n";
  }
}


Compile with -fPIC -fsanitize=address on x86-64, then the first catch clause
(EXCEPTION_TYPE const&) is executed. If you drop either option (fPIC or
fsanitize), then the second catch clause is executed. I ran into this issue on
g++4.8.5, but the behaviour is still the same with the current master branch.

By setting -DEXCEPTION_TYPE=Exception, the first catch clause uses a non-local
class and is never executed, even with -fPIC and -fsanitize.

Problem does not occur on clang++.

[Bug libstdc++/72847] New: vector copy-assignment basic exception safety

[dyp-cpp at gmx dot net]

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

Bug ID: 72847
   Summary: vector copy-assignment basic exception safety
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dyp-cpp at gmx dot net
  Target Milestone: ---

vector's copy-assignment operator uses a very simple algorithm if
resizing is required: first, free the current allocation, then create a new
allocation. The pointer data member that holds the allocation is not touched by
the first step, then assigned-to by the second step. Therefore, if the second
step (the allocation) fails via exception, that pointer (_M_end_of_storage -
size()) is dangling. Destruction of a vector in such a state leads to a
double deletion.

[Bug c++/65816] New: Constructor delegation does not perform zero-initialization

[dyp-cpp at gmx dot net]

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

Bug ID: 65816
   Summary: Constructor delegation does not perform
zero-initialization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dyp-cpp at gmx dot net

In the following program, I expect the object `t` to be zero-initialized via
constructor delegation. Clang++ does this, but g++ 6.0 2015-04-20 does not.

-

struct test
{
int m;

test() = default;
test(int) : test() {}
};

#include iostream

int main()
{
test t(0);
std::cout  t.m;
}

-

While C++14 IS [class.base.init]p6 is unclear about this, as far as I can tell,
paragraph 7 implies (in the parenthesized clause) that the constructor
`test(int)` is required to value-initialize the object:

 The expression-list or braced-init-list in a mem-initializer is used to 
 initialize the designated subobject (or, in the case of a delegating 
 constructor, the complete class object) according to the initialization rules 
 of 8.5 for direct-initialization.

The class `test` does not have a user-provided default constructor, hence
zero-initialization should be performed as per [dcl.init]p8.2

[Bug c++/61504] New: Move elision after cast to rvalue reference

[dyp-cpp at gmx dot net]

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

Bug ID: 61504
   Summary: Move elision after cast to rvalue reference
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dyp-cpp at gmx dot net

Created attachment 32935
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32935action=edit
Test case as in description.

Move elision is applied even though the object has been bound to a reference
(see [class.copy]/31). Test case:

---

#include iostream

struct loud
{
loud(){ std::cout  default\n; }
loud(loud ) { std::cout  move\n; }
~loud()   { std::cout  dtor\n; }
};

int main()
{
loud l1{ static_castloud(loud{}) };
}

--

Expected output (also, recent clang++):

default
move
dtor
dtor

Output produced by g++ -std=c++11 -Wall -Wextra -pedantic 4.10.0 20140611:

default
dtor

Possibly related:
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1376