[Bug libstdc++/113841] Can't swap two std::hash

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

--- Comment #11 from Viktor Ostashevskyi  ---
(In reply to Jonathan Wakely from comment #10)
> This one's much harder to fix:
> 
> #include 
> 
> template
> struct Alloc
> {
>   using value_type = T;
> 
>   Alloc(int) { }
> 
>   template Alloc(const Alloc&) { }
> 
>   T* allocate(std::size_t n) { return std::allocator().allocate(n); }
>   void deallocate(T* p, std::size_t n) { std::allocator().deallocate(p,
> n); }
> };
> 
> template struct wrap { T t; };
> 
> template void do_adl(T&) { }
> 
> void test_pr113841()
> {
>   using Tr = std::char_traits;
>   using test_type = std::basic_string>;
>   std::pair>* h = nullptr;
>   do_adl(h);
> }

Incremental approach? Fixing std::vector first, thinking about std::pair next..
:)

[Bug libstdc++/113841] Can't swap two std::hash

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

--- Comment #9 from Viktor Ostashevskyi  ---
(In reply to Jonathan Wakely from comment #8)
> Calling swap unqualified performs ADL, which has to find all the associated
> namespaces and associated classes. To do that it has to complete all the
> types involved, which means it tries to complete:
> std::hash*>
> std::pair
> MyArrVec
> MyVec
> MyAllocator
> 
> Trying to complete MyVec hits an error outside the immediate context,
> because its default constructor cannot be instantiated, because
> MyAllocator is not default constructible.
> 
> That's why comment 5 fixes it.

Thanks a lot for such a deep explanation. We applied patch from comment #5 to
gcc-13 and now clang-17 can compile our application using libstdc++.

Any plans to apply the patch to gcc-12/gcc-13/gcc-14/trunk?

[Bug libstdc++/113841] Can't swap two std::hash

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

--- Comment #7 from Viktor Ostashevskyi  ---
I'm still wondering why for std::hash, the T type is checked for anything.
It shouldn't matter what T is, as we're hashing T*...

[Bug libstdc++/113841] Can't swap two std::hash

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

--- Comment #3 from Viktor Ostashevskyi  ---
Additional information: everything works fine both for GCC12 and Clang if swap
call is fully qualified, i.e.:

std::swap(h1, h2);

[Bug libstdc++/113841] Can't swap two std::hash

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

--- Comment #1 from Viktor Ostashevskyi  ---
Issue is visible with -std=c++20, works fine for -std=c++17 (for both GCC12 and
Clang).

[Bug libstdc++/113841] Can't swap two std::hash

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

--- Comment #2 from Viktor Ostashevskyi  ---
Compiler exporer link: https://godbolt.org/z/cPqsKq6nM

[Bug libstdc++/113841] New: Can't swap two std::hash

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

Bug ID: 113841
   Summary: Can't swap two std::hash
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

For the following code snippet:
---
#include 
#include 

class Storage;

template 
class MyAllocator 
{
public:
  using value_type = T;
  using pointer = T*;

  MyAllocator(Storage* s);

  template 
  MyAllocator(MyAllocator const& other) noexcept;

  T* allocate( std::size_t n );
  void deallocate(T* p, std::size_t n );

private:
  Storage* s_;
};

class Foo{
public:
Foo(int, int);
};

void x() {
  using std::swap;

  using MyVec = std::vector>;
  using MyArrVec = std::array;
  using MyHash = std::hash*>;

  MyHash h1, h2;
  swap(h1, h2);
}
---

GCC 12 reports:
In file included from
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/vector:64,
 from :2:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_vector.h: In
instantiation of 'constexpr std::_Vector_base<_Tp,
_Alloc>::_Vector_impl::_Vector_impl() [with _Tp = int; _Alloc =
MyAllocator]':
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_vector.h:312:7:  
required by substitution of 'template static std::true_type
std::__do_is_implicitly_default_constructible_impl::__test(const _Tp&, decltype
(__helper(()))*) [with _Tp =
std::array >, 1>]'
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/type_traits:1249:30:  
required from 'struct
std::__is_implicitly_default_constructible_impl >, 1> >'
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/type_traits:1253:12:  
required from 'struct
std::__is_implicitly_default_constructible_safe >, 1> >'
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/type_traits:167:12:  
required from 'struct
std::__and_ >, 1> >,
std::__is_implicitly_default_constructible_safe >, 1> > >'
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/type_traits:1258:12:  
required from 'struct
std::__is_implicitly_default_constructible >, 1> >'
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/type_traits:167:12:  
required from 'struct
std::__and_,
std::__is_implicitly_default_constructible >, 1> > >'
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/type_traits:178:41:  
required from 'struct
std::__not_,
std::__is_implicitly_default_constructible >, 1> > > >'
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_pair.h:226:16:  
required from 'struct std::pair >, 1> >'
:38:14:   required from here
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/type_traits:1240:58:   in
'constexpr' expansion of 'std::vector >()'
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_vector.h:526:7:  
in 'constexpr' expansion of '((std::vector
>*)this)->std::vector
>::.std::_Vector_base >::_Vector_base()'
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_vector.h:139:26:
error: no matching function for call to 'MyAllocator::MyAllocator()'
  139 | : _Tp_alloc_type()
  |  ^
:16:3: note: candidate: 'template
MyAllocator::MyAllocator(const MyAllocator&) [with T = int]'
   16 |   MyAllocator(MyAllocator const& other) noexcept;
  |   ^~~
:16:3: note:   template argument deduction/substitution failed:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_vector.h:139:26:
note:   candidate expects 1 argument, 0 provided
  139 | : _Tp_alloc_type()
  |  ^
:13:3: note: candidate: 'MyAllocator::MyAllocator(Storage*) [with T
= int]'
   13 |   MyAllocator(Storage* s);
  |   ^~~
:13:3: note:   candidate expects 1 argument, 0 provided
:7:7: note: candidate: 'constexpr MyAllocator::MyAllocator(const
MyAllocator&)'
7 | class MyAllocator
  |   ^~~
:7:7: note:   candidate expects 1 argument, 0 provided
:7:7: note: candidate: 'constexpr
MyAllocator::MyAllocator(MyAllocator&&)'
:7:7: note:   candidate expects 1 argument, 0 provided
Compiler returned: 1


Clang 15, 16, 17 also fail to compile with similar error about missing default
constructor for custom allocator when they are using libstdc++ >=12

GCC 13 is able to compile this, same as Clang with libc++.

[Bug tree-optimization/113662] [13/14 Regression] Wrong code for std::sort with fancy pointer

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

--- Comment #2 from Viktor Ostashevskyi  ---
Adding --param=ranger-recompute-depth=1 or --param=ranger-recompute-depth=2
also fixes the issue. Higher values behave wrongly.

[Bug c++/113662] New: [13/14 Regression] Wrong code for std::sort with fancy pointer

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

Bug ID: 113662
   Summary: [13/14 Regression] Wrong code for std::sort with fancy
pointer
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

Hello,

For the following snippet compiled with "-O3 -std=c++20"
---
#include 
#include 

#include 
#include 

struct Foo
{
public:
  uint32_t m1; 
  uint32_t m2;
  uint8_t m3;
};

bool operator<(const Foo& lhs, const Foo& rhs)
{
  return lhs.m1 < rhs.m1;
}

template 
class MyAllocator 
{
public:
  using value_type = T;
  using pointer = boost::interprocess::offset_ptr;

  boost::interprocess::offset_ptr allocate( std::size_t n ) {
  return boost::interprocess::offset_ptr(a.allocate(n));
  }
  void deallocate(  boost::interprocess::offset_ptr p, std::size_t n ) {
  a.deallocate(p.get(), n);
  }

  std::allocator a;
};

int main()
{
boost::container::vector> vec;
vec.emplace_back().m1 = 4748;
vec.emplace_back().m1 = 4687;
vec.emplace_back().m1 = 4717;
vec.emplace_back().m1 = 4779;

std::cout << "before: " <<  vec.size() << '\n';
for (const auto& x : vec)
std::cout << std::to_string(x.m1) << '\n';

std::sort(vec.begin(), vec.end());

std::cout << "after: " <<  vec.size() << '\n';
for (const auto& x : vec)
std::cout << std::to_string(x.m1) << '\n';
}
---

we receive the following output:
---
before: 4
4748
4687
4717
4779
after: 4
4687
4717
4717
4779
---

I've managed to bisect this issue to the following commit:
429a7a88438cc80e7c58d9f63d44838089899b12 is the first bad commit
commit 429a7a88438cc80e7c58d9f63d44838089899b12
Author: Andrew MacLeod 
Date:   Tue Mar 28 12:16:34 2023 -0400
   Add recursive GORI recompuations with a depth limit.
   PR tree-optimization/109154
   gcc/
   * gimple-range-gori.cc (gori_compute::may_recompute_p): Add depth
limit.
   * gimple-range-gori.h (may_recompute_p): Add depth param.
   * params.opt (ranger-recompute-depth): New param.
   gcc/testsuite/
   * gcc.dg/Walloca-13.c: Remove bogus warning that is now fixed.
gcc/gimple-range-gori.cc  | 30 ++
gcc/gimple-range-gori.h   |  4 ++--
gcc/params.opt|  5 +
gcc/testsuite/gcc.dg/Walloca-13.c |  2 +-
4 files changed, 30 insertions(+), 11 deletions(-)

I tried different versions of Boost to ensure that the problem is not coming
from offset_ptr. It looks like that it is possible to reproduce issue with "-O2
-ftree-partial-pre".

Everything works fine with std::vector or std::allocator.

I'd be glad to perform other tests if needed.

[Bug c++/110075] Bogus -Wdangling-reference

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

--- Comment #6 from Viktor Ostashevskyi  ---
(In reply to Marek Polacek from comment #5)
> Yes, because we'd have to analyze the body of the function to see that it
> does not return one of the parameters, which often we can't do.
> 
> There will be an attribute soon to suppress that warning.

I'm wondering whether this diagnostics should be in -Wall or -Wextra at all.
It is assumed that diagnostics in -Wall or -Wextra generally "works".

Here, diagnostics clearly fails on simplest case and I don't think marking huge
codebase with some attribute is a proper solution...

[Bug c++/110075] Bogus -Wdangling-reference

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #4 from Viktor Ostashevskyi  ---
I have even simpler reproducer:

---
class X{};
const X x1;
const X x2;

const X& get(const int& i)
{
   return i == 0 ? x1 : x2;
}

void foo() {
[[maybe_unused]] const X& x = get(10);
}
---

: In function 'void foo()':
:23:31: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
   23 | [[maybe_unused]] const X& x = get(10);
  |   ^
:23:38: note: the temporary was destroyed at the end of the full
expression 'get(10)'
   23 | [[maybe_unused]] const X& x = get(10);
  |

[Bug libstdc++/100667] [11/12 Regression] std::tuple cannot be constructed from A&&, if A not defined (only forward declared)

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #1 from Viktor Ostashevskyi  ---
Hello,

I have another example, but probably related:


#include 
#include 

class Foo{};

std::tuple bar()
{
return { {}, Foo{}};
}


Fails starting from GCC 11.1 in C++11/14/17/20 modes with the following error:

: In function 'std::tuple, std::allocator >, Foo> bar()':
:8:23: error: conversion from '' to
'std::tuple,
std::allocator >, Foo>' is ambiguous
8 | return { {}, Foo{}};
  |   ^
In file included from :1:
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple:1144:9: note:
candidate: 'std::tuple<_T1, _T2>::tuple(std::allocator_arg_t, const _Alloc&)
[with _Alloc = Foo; typename
std::enable_if::value, _T1,
_T2>::__is_implicitly_default_constructible(), bool>::type  = true;
_T1 = std::__cxx11::basic_string; _T2 = Foo]'
 1144 | tuple(allocator_arg_t __tag, const _Alloc& __a)
  | ^
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple:1052:9: note:
candidate: 'constexpr std::tuple<_T1, _T2>::tuple(const _T1&, const _T2&) [with
bool _Dummy = true; typename std::enable_if::__is_implicitly_constructible(), bool>::type
 = true; _T1 = std::__cxx11::basic_string; _T2 = Foo]'
 1052 | tuple(const _T1& __a1, const _T2& __a2)
  |

[Bug lto/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #10 from Viktor Ostashevskyi  ---
Hello,

During GCC 10.1.0 bootstrap in LTO+PGO mode, configured as:

Configured with: ../gcc-10.1.0/configure --disable-multiarch
--disable-libquadmath --disable-libquadmath-support --disable-libssp
--disable-libstdcxx-pch --disable-multilib --disable-nls
--enable-checking=release --enable-__cxa_atexit --enable-languages=c,c++
--enable-libstdcxx-debug --enable-lto --enable-plugin --enable-threads=posix
--enable-tls --with-build-config=bootstrap-lto
--with-default-libstdcxx-abi=gcc4-compatible --with-linker-hash-style=gnu
--with-system-zlib --with-zstd=no --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu

I got following ICE:

/ostash/buildtc10/gcc-10.1.0-build/./prev-gcc/xgcc
-B/ostash/buildtc10/gcc-10.1.0-build/./prev-gcc/
-B/ostash/tc10/x86_64-pc-linux-gnu/bin/ -B/ostash/tc10/x86_64-pc-linux-gnu/bin/
-B/ostash/tc10/x86_64-pc-linux-gnu/lib/ -isystem
/ostash/tc10/x86_64-pc-linux-gnu/include -isystem
/ostash/tc10/x86_64-pc-linux-gnu/sys-include-c -DHAVE_CONFIG_H
-fprofile-use -flto=jobserver -frandom-seed=1  -I.
-I../../gcc-10.1.0/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -Wshadow=local -pedantic  -D_GNU_SOURCE -fcf-protection
../../gcc-10.1.0/libiberty/hashtab.c -o hashtab.o
during IPA pass: fnsummary
../../gcc-10.1.0/libiberty/hashtab.c:997:1: internal compiler error: in
stream_out_histogram_value, at value-prof.c:338
  997 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make[3]: *** [hashtab.o] Error 1
make[3]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build/libiberty'
make[2]: *** [all-stagefeedback-libiberty] Error 2
make[2]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build'
make[1]: *** [stagefeedback-bubble] Error 2
make[1]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build'
make: *** [profiledbootstrap] Error 2


I can provide gcda files if needed.

[Bug c++/93998] [10 Regression] ICE in adjust_temp_type, at cp/constexpr.c:1426

[ostash at ostash dot kiev.ua]

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

--- Comment #3 from Viktor Ostashevskyi  ---
Bisected to:

ee1de08d4d22648cf3168caa60e283135755da85 is the first bad commit
commit ee1de08d4d22648cf3168caa60e283135755da85
Author: Jakub Jelinek 
Date:   Tue Dec 3 20:27:47 2019 +0100

re PR c++/91369 (Implement P0784R7: constexpr new)

PR c++/91369
* constexpr.c (struct constexpr_global_ctx): Add cleanups member,
initialize it in the ctor.
(cxx_eval_constant_expression) : If
TARGET_EXPR_SLOT
is already in the values hash_map, don't evaluate it again.  Put
TARGET_EXPR_SLOT into hash_map even if not lval, and push it into
save_exprs too.  If there is TARGET_EXPR_CLEANUP and not
CLEANUP_EH_ONLY, push the cleanup to cleanups vector.
: Save outer cleanups, set cleanups to
local auto_vec, after evaluating the body evaluate cleanups and
restore previous cleanups.
: Don't crash if the first operand is
NULL_TREE.
(cxx_eval_outermost_constant_expr): Set cleanups to local auto_vec,
after evaluating the expression evaluate cleanups.

* g++.dg/cpp2a/constexpr-new8.C: New test.

From-SVN: r278945

[Bug c++/93998] New: ICE in adjust_temp_type, at cp/constexpr.c:1426

[ostash at ostash dot kiev.ua]

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

Bug ID: 93998
   Summary: ICE in adjust_temp_type, at cp/constexpr.c:1426
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

Hello,

Following code 

#define LIKELY(x) __builtin_expect(!!(x), 1)

class Code
{
public:
  constexpr bool operator==(Code rhs) const noexcept { return value_ ==
rhs.value_; }

private:
  int value_;
};

int func(const Code a, const Code b, bool cond)
{
  return LIKELY(a == b || cond) ? 0 : 1;
}


causes an ICE with GCC:

COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/prefix/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10-20200223/configure --disable-multiarch
--disable-libquadmath --disable-libquadmath-support --disable-libssp
--disable-libstdcxx-pch --disable-multilib --disable-nls
--enable-checking=release --enable-__cxa_atexit --enable-languages=c,c++
--enable-libstdcxx-debug --enable-lto --enable-plugin --enable-threads=posix
--enable-tls --with-build-config=bootstrap-lto
--with-default-libstdcxx-abi=gcc4-compatible --with-linker-hash-style=gnu
--with-system-zlib --with-zstd=no --with-stage1-libs=
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --prefix=/prefix
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200223 (experimental) (GCC)




gccice.cpp: In function 'int func(Code, Code, bool)':
gccice.cpp:1:44: internal compiler error: in adjust_temp_type, at
cp/constexpr.c:1426
1 | #define LIKELY(x) __builtin_expect(!!(x), 1)
  |^
gccice.cpp:14:10: note: in expansion of macro 'LIKELY'
   14 |   return LIKELY(a == b || cond) ? 0 : 1;
  |
Please submit a full bug report,
with preprocessed source if appropriate.



Optimization level doesn't matter and any C++ standard >= c++11 causes an ICE.

[Bug target/40838] gcc shouldn't assume that the stack is aligned

[ostash at ostash dot kiev.ua]

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

--- Comment #96 from Viktor Ostashevskyi  ---
Honestly, I don't see how your compiler flags could help. cost-model=cheap
is default, data-alignment doesn't change incoming stack alignment.

ср, 15 січ. 2020, 14:31 користувач mahatma at eu dot by <
gcc-bugzi...@gcc.gnu.org> пише:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
>
> --- Comment #95 from Dzianis Kahanovich  ---
> Just FYI. Novadays, on my Thinkpad tablet with Atom (32 bit userspace
> Gentoo),
> I globally replace patch/-mstackrealign to "-fvect-cost-model=cheap
> -fsimd-cost-model=cheap -malign-data=cacheline" and all works fine for -O3
> +.
> (This is dirty example, as cacheline for some old SSE CPUs are different,
> etc).
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug target/40838] gcc shouldn't assume that the stack is aligned

[ostash at ostash dot kiev.ua]

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

--- Comment #94 from Viktor Ostashevskyi  ---
(In reply to Florian Weimer from comment #93)
> (In reply to Viktor Ostashevskyi from comment #92)
> > I've tried to run some old binaries yesterday (StarOffice 5.1, get it from
> > archive.org) and hit this bug.
> > 
> > What are possible workarounds?
> 
> You need to use an operating system which was build with -mstackrealign,
> such as Fedora.

Indeed, I can confirm that rebuilding 32-bit libraries with '-mstackrealign' on
Gentoo helps.

Bug probably can be closed as WONTFIX. Additionally, it would be nice to have
this ABI breakage properly documented somewhere (GCC FAQ?).

[Bug target/40838] gcc shouldn't assume that the stack is aligned

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #92 from Viktor Ostashevskyi  ---
I've tried to run some old binaries yesterday (StarOffice 5.1, get it from
archive.org) and hit this bug.

What are possible workarounds?

[Bug c++/91953] New: [8/9/10 Regression] G++ rejects lambda with constexpr variable

[ostash at ostash dot kiev.ua]

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

Bug ID: 91953
   Summary: [8/9/10 Regression] G++ rejects lambda with constexpr
variable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

Hello,

Following snippet


#include 

auto f = [](auto value) {
constexpr auto i = value;
return i;
  };

void foo()
{
   f(std::integral_constant{});
}



is rejected by G++ starting from 8.1.0. It works on GCC7, GCC6 and Clang.

[Bug c++/88128] G++ should implement CWG 330

[ostash at ostash dot kiev.ua]

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

--- Comment #3 from Viktor Ostashevskyi  ---
I see that std::span implementation was proposed in
https://gcc.gnu.org/ml/libstdc++/2019-08/msg00068.html.

Was this bug fixed for implenting it?

Is it possible to make std::span from std::vector?

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[ostash at ostash dot kiev.ua]

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

--- Comment #17 from Viktor Ostashevskyi  ---
Ok, got following today with GCC 9.2 with "-O2 -fno-inline -flto=20":

ld.bfd: /tmp/tests.oKru4z.ltrans32.ltrans.o: in function
`std::__shared_ptr::operator=(std::__shared_ptr&&)':
c++/9.2.0/bits/shared_ptr_base.h:1265: undefined reference to
`std::__shared_ptr::__shared_ptr(std::__shared_ptr&&)'

Code base is huge, so it is hard to minimize test case. Even not sure whether
LTO or libstdc++ is guilty.

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[ostash at ostash dot kiev.ua]

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

--- Comment #15 from Viktor Ostashevskyi  ---
(In reply to Jonathan Wakely from comment #14)
> I can reproduce the link failure. For some reason Clang requires that
> constructor at -O1, but not at any other optimization level.

It will require it at any -O level with fno-inline.

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[ostash at ostash dot kiev.ua]

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

--- Comment #13 from Viktor Ostashevskyi  ---
(In reply to Jonathan Wakely from comment #12)
> I didn't export that because nothing should need it. Nothing in libstdc++
> derives from __shared_ptr<_Dir> and nothing in user code is allowed to refer
> to that type, because it's an implementation detail.
> 
> The explicit instantiation tells Clang not to emit that constructor, but it
> shouldn't cause it to depend on that constructor.

Well, Clang emits call to C2 version somehow. Should it be reported as a but to
Clang?

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[ostash at ostash dot kiev.ua]

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

--- Comment #11 from Viktor Ostashevskyi  ---
I assume that problem comes from explicit instantiation:

extern template class __shared_ptr;

which was added in c8fb3443911413cc88f316305fc6b7bf4861ccaa.

It prevent Clang in emitting "C2" version of constructors on its own.

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #10 from Viktor Ostashevskyi  ---
What about "base object constructors" (mangled with C2)?

For simple case like:

---
#include 
#include 

int main(int argc, char** argv)
{
  for (const auto& dirElem : std::filesystem::directory_iterator(argv[1]))
std::cout << dirElem.path().filename() << '\n';
}
---

When compiling with Clang 8 against libstdc++ from GCC 9.2.0 I got:

in function
`std::filesystem::directory_iterator::directory_iterator(std::filesystem::directory_iterator&&)':
fs.cpp:(.text._ZNSt10filesystem18directory_iteratorC2EOS0_[_ZNSt10filesystem18directory_iteratorC2EOS0_]+0x1):
undefined reference to `std::__shared_ptr::__shared_ptr(std::__shared_ptr&&)'


Checking in libstdc++.so showed that symbols are exported, but only for
complete object constructor:

_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_

Not sure why, but Clang emits call to base object constructor:

_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_


I've checked Clang8 vs libstdc++ from GCC 8.3.0 and see that it emits calls to
same base object ctor, but its definition is also emitted, so no linker error
occur.

[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible

[ostash at ostash dot kiev.ua]

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

--- Comment #11 from Viktor Ostashevskyi  ---
Cool! Thanks a lot, sad that this doesn't make to 9.2.

[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible

[ostash at ostash dot kiev.ua]

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

--- Comment #6 from Viktor Ostashevskyi  ---
(In reply to Viktor Ostashevskyi from comment #5)
> It would be nice at least document that for GCC 9.1.0 building with
> --with-default-libstdcxx-abi=gcc4-compatible is broken.
> 
> Possible workaround is to build with default parameters and change
> _GLIBCXX_USE_DUAL_ABI define to 1 in bits/c++config.h after 'make install'.

s/_GLIBCXX_USE_DUAL_ABI define to 1/_GLIBCXX_USE_CXX11_ABI define to 0/

[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible

[ostash at ostash dot kiev.ua]

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

--- Comment #5 from Viktor Ostashevskyi  ---
It would be nice at least document that for GCC 9.1.0 building with
--with-default-libstdcxx-abi=gcc4-compatible is broken.

Possible workaround is to build with default parameters and change
_GLIBCXX_USE_DUAL_ABI define to 1 in bits/c++config.h after 'make install'.

[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible

[ostash at ostash dot kiev.ua]

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

--- Comment #4 from Viktor Ostashevskyi  ---
Bisected to:

commit c6e37a9f5734bfe731b042993f77cb41b5a566c5
Author: redi 
Date:   Sun Jan 6 22:34:29 2019 +

PR libstdc++/86756 add std::filesystem::path to libstdc++.so

Move the C++17 std::filesystem::path definitions from the libstdc++fs.a
archive to the main libstdc++ library. The path classes do not depend on
any OS functions, so can be defined unconditionally on all targets
(rather than depending on --enable-libstdcxx-filesystem-ts). The tests
should pass on all targets too.  
 ...
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@267615
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible

[ostash at ostash dot kiev.ua]

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

--- Comment #3 from Viktor Ostashevskyi  ---
(In reply to Jonathan Wakely from comment #2)
> I haven't checked a build with that option for ages, so I can easily believe
> I've broken it. I'll take a look tomorrow.

It worked well in GCC 8.2.0 at least.

[Bug libstdc++/90361] New: Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible

[ostash at ostash dot kiev.ua]

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

Bug ID: 90361
   Summary: Undefined symbols in libstdc++ when building with
--with-default-libstdcxx-abi=gcc4-compatible
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

Hello,

When build gcc-9.1.0 with --with-default-libstdc xx-abi=gcc4-compatible
resulting libstdc++.so.6.0.26 contains following undefined symbols:

 U std::__cxx11::basic_string,
std::allocator >::operator std::basic_string_view >() const
 U std::__cxx11::basic_string,
std::allocator >::__sv_wrapper::__sv_wrapper(std::basic_string_view >)
 U std::__cxx11::basic_string,
std::allocator >::_S_to_string_view(std::basic_string_view >)
 U std::__cxx11::basic_string,
std::allocator >::data()
 U std::__cxx11::basic_string,
std::allocator >::basic_string(std::__cxx11::basic_string, std::allocator >::__sv_wrapper,
std::allocator const&)
 U std::__cxx11::basic_string, std::allocator >::data()

As result even minimal 'int main() { return 0; }' C++ program can't be linked.

[Bug c++/88128] G++ should implement CWG 330

[ostash at ostash dot kiev.ua]

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

--- Comment #2 from Viktor Ostashevskyi  ---
Actually, even current C++17 unique_ptr::reset for array objects is defined in
terms of pointer to array convertibility ([unique.ptr.runtime.modifiers]).

[Bug c++/88128] New: G++ should implement CWG 330

[ostash at ostash dot kiev.ua]

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

Bug ID: 88128
   Summary: G++ should implement CWG 330
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

GCC rejects following code:


int* (*xx)[];
const int* const(*yy)[];
yy = xx;


while Clang started accepting since 7.0 when they implemented CWG 330.

Without this it is very hard to implement std::span, as its constructors
availability are defined in terms of pointer to array convertibility (see
[span.cons]).

[Bug libstdc++/87809] [8/9 Regression] Can't create empty std::optional>

[ostash at ostash dot kiev.ua]

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

--- Comment #7 from Viktor Ostashevskyi  ---
I confirm that fix works on real codebase with GCC9.

[Bug libstdc++/87809] New: Can't create empty std::optional>

[ostash at ostash dot kiev.ua]

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

Bug ID: 87809
   Summary: Can't create empty std::optional>
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

Hello,

Following code snippet:

#include 
#include 

class Storage;

template 
class MyAlloc
{
public:
  using value_type = T;

  value_type* allocate(size_t n);  
  void deallocate(value_type* p, size_t n);

  MyAlloc(Storage& storage) noexcept;
};

void test()
{
   std::optional>> opt;
}

compiles with GCC8, but fails with GCC9 trunk:

In file included from
/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/utility:68,

 from
/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/optional:36,

 from :1:

/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/bits/stl_vector.h:
In instantiation of 'std::_Vector_base<_Tp,
_Alloc>::_Vector_impl::_Vector_impl() [with _Tp = int; _Alloc = MyAlloc]':

/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/type_traits:925:12:
  required from 'struct std::is_constructible >
>'

/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/type_traits:2881:25:
  required from 'constexpr const bool std::is_constructible_v > >'

/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/optional:715:66:  
required by substitution of 'template >, _Args&&
...>, bool>::type  > constexpr std::_Optional_base >, false, false>::_Optional_base(std::in_place_t, _Args&& ...)
[with _Args = {}; typename std::enable_if >, _Args&& ...>, bool>::type  = ]'

:20:50:   required from here

/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/bits/stl_vector.h:128:17:
error: no matching function for call to 'MyAlloc::MyAlloc()'

  128 |  _Vector_impl() _GLIBCXX_NOEXCEPT_IF( noexcept(_Tp_alloc_type()) )

  | ^~~~

:15:3: note: candidate: 'MyAlloc::MyAlloc(Storage&) [with T = int]'

   15 |   MyAlloc(Storage& storage) noexcept;

  |   ^~~

:15:3: note:   candidate expects 1 argument, 0 provided

:7:7: note: candidate: 'constexpr MyAlloc::MyAlloc(const
MyAlloc&)'

7 | class MyAlloc

  |   ^~~

:7:7: note:   candidate expects 1 argument, 0 provided

:7:7: note: candidate: 'constexpr
MyAlloc::MyAlloc(MyAlloc&&)'

:7:7: note:   candidate expects 1 argument, 0 provided

Compiler returned: 1

[Bug c++/83406] GCC8 can't deduce lambda return type

[ostash at ostash dot kiev.ua]

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

--- Comment #1 from Viktor Ostashevskyi  ---
gcc version 8.0.0 20171213 (experimental) (GCC)

[Bug c++/83406] New: GCC8 can't deduce lambda return type

[ostash at ostash dot kiev.ua]

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

Bug ID: 83406
   Summary: GCC8 can't deduce lambda return type
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

Following code:

-
class Foo{};

class Bar
{
public:
  const Foo& getFoo() const;
  Foo& getFoo();
};

auto getter = [](const Bar& bar) -> decltype(auto) { return bar.getFoo(); };
-

is reject with GCC8 trunk with:
error: inconsistent types 'Foo' and 'const Foo&' deduced for lambda return type
 auto getter = [](const Bar& bar) -> decltype(auto) { return bar.getFoo(); };
   ^

GCC6, GCC7 and Clang are ok with it in both C++14/C++17 modes.

[Bug c++/82579] GCC 7/8 ambiguous call to overload

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c++/82579] GCC 7/8 ambiguous call to overload

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Viktor Ostashevskyi  ---
(In reply to Jonathan Wakely from comment #1)
> This is not a GCC bug, because it's the required behaviour for C++17.
> 
> Use -fno-new-ttp-matching to disable it in C++17 (or use -fnew-ttp-matching
> to enable it in C++14 and make it ambiguous).

Huh, thanks for clearing this. Then this is a bug in Boost and maybe Clang.

[Bug c++/82579] New: GCC 7/8

[ostash at ostash dot kiev.ua]

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

Bug ID: 82579
   Summary: GCC 7/8
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

Hello,

The following code fails to compile with GCC 7/8, in C++17 mode (call to f(s)
is ambiguous):

-
template  
class C
{};

template 
void f(const C<T, U>&) {}

template  class CT>
void f(CT) {}

int main()
{
C s;
f(s);
}
-

However it compiles cleanly in C++14 mode.


This is a stripped case from boost::container::string:
https://github.com/boostorg/container/issues/58


Here
(https://groups.google.com/a/isocpp.org/d/topic/std-discussion/B1MHPRMqfFA/discussion)
we can find a suggestion that this is somehow related to CWG150 resolution by
P0522R0.

Clang accepts this code in both C++14 and C++17 mode, however they state that
CWG150 resolution "is disabled by default in all language versions" because
"the change to the standard lacks a corresponding change for template partial
ordering, resulting in ambiguity errors for reasonable and previously-valid
code" (https://clang.llvm.org/cxx_status.html#p0522).

[Bug c++/70385] Lambda capture by reference of const reference fails

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #1 from Viktor Ostashevskyi  ---
I can confirm this with:

gcc version 5.3.1 20160329 (GCC)

and 

gcc version 6.0.0 20160403 (experimental) (GCC).

It also fails with x86 gcc 6.1 (g++ (DRW-internal-build) 6.1.0) on
gcc.godbolt.org

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[ostash at ostash dot kiev.ua]

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

--- Comment #6 from Viktor Ostashevskyi  ---
I'm not sure about bug prioritizing policies, but for me it looks like this
should get P1 or documentation/release notes for GCC5 and GCC6 should state
that -fno-ellide-constructor is broken.

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[ostash at ostash dot kiev.ua]

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

--- Comment #5 from Viktor Ostashevskyi  ---
Bisected to:

commit 9c96033c877975303250d6f6156eacba52fc8b44
Author: jason 
Date:   Mon Nov 17 18:16:14 2014 +

C++14 constexpr support (minus loops and multiple returns)

gcc/
   * tree-inline.c (copy_fn): New.
   * tree-inline.h: Declare it.
gcc/cp/
   * constexpr.c (use_new_call): New macro.
   (build_data_member_initialization): Ignore non-mem-inits.
   (check_constexpr_bind_expr_vars): Remove C++14 checks.
   (constexpr_fn_retval): Likewise.
   (check_constexpr_ctor_body): Do nothing in C++14.
   (massage_constexpr_body): In C++14 only collect mem-inits.
   (get_function_named_in_call): Handle null CALL_EXPR_FN.
   (cxx_bind_parameters_in_call): Build bindings in same order as
   parameters.  Don't treat iniviref parms specially in new call mode.
   (cxx_eval_call_expression): If use_new_call, do constexpr expansion
   based on DECL_SAVED_TREE rather than the massaged constexpr body.
   Set up ctx->object from AGGR_INIT_EXPR_SLOT if we don't have one.
   (is_sub_constant_expr): Don't mess with ctx.ctor here.
   (cxx_eval_component_reference): A null element means we're mid-
   initialization.
   (cxx_eval_store_expression, cxx_eval_increment_expression): New.
   (cxx_eval_constant_expression): Handle RESULT_DECL, DECL_EXPR,
   MODIFY_EXPR, STATEMENT_LIST, BIND_EXPR, USING_STMT,
   PREINCREMENT_EXPR, POSTINCREMENT_EXPR, PREDECREMENT_EXPR,
   POSTDECREMENT_EXPR.  Don't look into DECL_INITIAL of variables in
   constexpr functions.  In new-call mode find parms in the values table.
   (potential_constant_expression_1): Handle null CALL_EXPR_FN.
   Handle STATEMENT_LIST, MODIFY_EXPR, MODOP_EXPR, IF_STMT,
   PREINCREMENT_EXPR, POSTINCREMENT_EXPR, PREDECREMENT_EXPR,
   POSTDECREMENT_EXPR, BIND_EXPR, WITH_CLEANUP_EXPR,
   CLEANUP_POINT_EXPR, MUST_NOT_THROW_EXPR, TRY_CATCH_EXPR,
   EH_SPEC_BLOCK, EXPR_STMT, DECL_EXPR, CASE_LABEL_EXPR, BREAK_STMT,
   CONTINUE_STMT, USING_STMT, IF_STMT, DO_STMT, FOR_STMT, WHILE_STMT,
   SWITCH_STMT, ASM_EXPR.
   (cxx_eval_vec_init_1): Call build_aggr_init_expr.
   (cxx_eval_indirect_ref): Don't return a CONSTRUCTOR when the
   caller wants an lvalue.
   (cxx_eval_outermost_constant_expr): Pull object out of AGGR_INIT_EXPR.
   (maybe_constant_init): Look through INIT_EXPR.
   (ensure_literal_type_for_constexpr_object): Set
   cp_function_chain->invalid_constexpr.
   * cp-tree.h (struct language_function): Add invalid_constexpr bitfield.
   * decl.c (start_decl): Set cp_function_chain->invalid_constexpr.
   (check_for_uninitialized_const_var): Likewise.
   (maybe_save_function_definition): Check it.
   * parser.c (cp_parser_jump_statement): Set
   cp_function_chain->invalid_constexpr.
   (cp_parser_asm_definition): Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@217663
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[ostash at ostash dot kiev.ua]

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

--- Comment #16 from Viktor Ostashevskyi  ---
(In reply to Jonathan Wakely from comment #15)

> That option is not the default, and is only really useful for experimenting
> to understand how C++ works (as documented at
> https://gcc.gnu.org/wiki/FAQ#copyelision) so there are very few good reasons
> to use that option in real code (except broken code).

It is very useful for building code coverage reports.

Any workarounds possible?

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[ostash at ostash dot kiev.ua]

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

--- Comment #14 from Viktor Ostashevskyi  ---
(In reply to Jakub Jelinek from comment #13)

> As for the priority, P2
> is right, we've already shipped GCC 5.[123] with this bug, so it can't be a
> release blocker, but is of course very much desirable to get fixed for GCC 6.

What about at least documenting that -fno-ellide-constructor is broken in GCC
5.[123] and GCC6 if it isn't get fixed till release?

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[ostash at ostash dot kiev.ua]

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

--- Comment #3 from Viktor Ostashevskyi  ---
Could be the same problem as in PR70145.

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[ostash at ostash dot kiev.ua]

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

--- Comment #2 from Viktor Ostashevskyi  ---
Exception occurs, because in:


regex_traits::lookup_classname(...):
{
...

static const pair __classnames[] =
  {
{"d", ctype_base::digit},
{"w", {ctype_base::alnum, _RegexMask::_S_under}},
{"s", ctype_base::space},
{"alnum", ctype_base::alnum},
{"alpha", ctype_base::alpha},
{"blank", ctype_base::blank},
{"cntrl", ctype_base::cntrl},
{"digit", ctype_base::digit},
{"graph", ctype_base::graph},
{"lower", ctype_base::lower},
{"print", ctype_base::print},
{"punct", ctype_base::punct},
{"space", ctype_base::space},
{"upper", ctype_base::upper},
{"xdigit", ctype_base::xdigit},
  };
...
}

array element for "w" class is initialized to {0, 0} with
-fno-ellide-constructors.

[Bug c++/70139] New: -fno-ellide-constructor makes static std::regex to throw

[ostash at ostash dot kiev.ua]

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

Bug ID: 70139
   Summary: -fno-ellide-constructor makes static std::regex to
throw
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

Following code:

#include 

namespace
{
  const std::regex HTTP_START_HEADER_RE("^HTTP\\/\\d.\\d\\s+(\\d+)\\s+([\\w\\t
]+)\\r\\n");
}

int main()
{
}

compiles and works perfectly with GCC 4.9 with and without
-fno-ellide-constructor.


However, with GCC 5.3.1 20160216 and with -fno-ellide-constructor it got
aborted due to exception:

terminate called after throwing an instance of 'std::regex_error'
  what():  regex_error

GDB backtrace:

(gdb) bt
#0  0x003ceb632625 in raise () from /lib64/libc.so.6
#1  0x003ceb633e05 in abort () from /lib64/libc.so.6
#2  0x77cbda2d in __gnu_cxx::__verbose_terminate_handler() () from
gcc5/lib/libstdc++.so.6
#3  0x77cbba86 in ?? () from gcc5/lib/libstdc++.so.6
#4  0x77cbbad1 in std::terminate() () from gcc5/lib/libstdc++.so.6
#5  0x77cbbce8 in __cxa_throw () from gcc5/lib/libstdc++.so.6
#6  0x77ce4635 in
std::__throw_regex_error(std::regex_constants::error_type) ()
fromgcc5/lib/libstdc++.so.6
#7  0x004085bb in
std::__detail::_BracketMatcher<std::regex_traits, false,
false>::_M_add_character_class (this=0x7fffd920, __s=..., __neg=)
at gcc5/include/c++/5.3.1/bits/regex_compiler.h:431
#8  0x0040c580 in std::__detail::_Compiler<std::regex_traits
>::_M_expression_term<false, false> (this=this@entry=0x7fffe280,
__last_char=..., __matcher=...)
at gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:507
#9  0x0040e1a2 in std::__detail::_Compiler<std::regex_traits
>::_M_insert_bracket_matcher<false, false> (this=this@entry=0x7fffe280,
__neg=)
at gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:427
#10 0x0040f796 in std::__detail::_Compiler<std::regex_traits
>::_M_bracket_expression (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:355
#11 0x00410ec6 in std::__detail::_Compiler<std::regex_traits
>::_M_atom (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:341
#12 0x004113f8 in std::__detail::_Compiler<std::regex_traits
>::_M_term (this=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:139
#13 std::__detail::_Compiler<std::regex_traits >::_M_alternative
(this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:121
#14 0x00411559 in std::__detail::_Compiler<std::regex_traits
>::_M_disjunction (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:97
#15 0x004110a6 in std::__detail::_Compiler<std::regex_traits
>::_M_atom (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:334
#16 0x004113f8 in std::__detail::_Compiler<std::regex_traits
>::_M_term (this=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:139
#17 std::__detail::_Compiler<std::regex_traits >::_M_alternative
(this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:121
#18 0x00411364 in std::__detail::_Compiler<std::regex_traits
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#19 0x00411364 in std::__detail::_Compiler<std::regex_traits
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#20 0x00411364 in std::__detail::_Compiler<std::regex_traits
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#21 0x00411364 in std::__detail::_Compiler<std::regex_traits
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#22 0x00411364 in std::__detail::_Compiler<std::regex_traits
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#23 0x00411364 in std::__detail::_Compiler<std::regex_traits
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#24 0x00411364 in std::__detail::_Compiler<std::regex_traits
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#25 0x00411364 in std::__detail::_Compiler<std::regex_traits
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#26 0x00411364 in std::__detail::_Compiler<std::regex_tr

[Bug c++/68890] New: [5.3 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2113

[ostash at ostash dot kiev.ua]

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

Bug ID: 68890
   Summary: [5.3 Regression] ICE in verify_ctor_sanity, at
cp/constexpr.c:2113
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

Following minimal case:

#include 

template 
class FixedVector : protected std::array<T, N>
{
public:
  typedef typename std::array<T, N> base;
  typedef uint8_t internal_size_type;

  constexpr FixedVector()
  : base()
  , size_(0u)
  {}

private:
  internal_size_type size_;
};

template 
class ptr
{
public:
  typedef T element_type;
  constexpr ptr(T* p = nullptr) noexcept : px_(p) {}

private:
  T* px_;
};

class ForwardDeclaredClass;

void func()
{
  FixedVector<ptr, 1> var;
}


gives me:

constexpr-ICE.cpp: In function 'void func()':
constexpr-ICE.cpp:34:45:   in constexpr expansion of 'var.FixedVector<T,
N>::FixedVector<ptr, 1ul>()'
constexpr-ICE.cpp:12:13:   in constexpr expansion of
'((FixedVector<ptr,
1ul>*)this)->FixedVector<ptr,
1ul>::.std::array<ptr, 1ul>::array()'
constexpr-ICE.cpp:34:45: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:2113
   FixedVector<ptr, 1> var;
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

on GCC 5.3.0 release:

Using built-in specs.
COLLECT_GCC=bin/g++
COLLECT_LTO_WRAPPER=/login/sg220044/53/bin/../libexec/gcc/x86_64-pc-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-5.3.0/configure --enable-bootstrap
--enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit
--disable-fixed-point --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-initfini-array --enable-languages=c,c++ --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-libstdcxx-time
--enable-libstdcxx-threads --disable-libquadmath --disable-libquadmath-support
--enable-linux-futex --enable-lto --disable-multiarch --disable-multilib
--disable-nls --enable-plugin --enable-secureplt --disable-sjlj-exceptions
--enable-threads=posix --enable-tls --enable-vtable-verify --disable-werror
--with-build-config=bootstrap-lto --with-default-libstdcxx-abi=gcc4-compatible
--with-diagnostics-color=auto --with-gnu-as --with-gnu-ld
--with-linker-hash-style=gnu --with-system-zlib --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--prefix=/atse_git/ostash/tc5
Thread model: posix
gcc version 5.3.0 (GCC)


Same code compiles silently with July snapshot:

Using built-in specs.
COLLECT_GCC=/login/sg220044/storage/tc5/bin/g++
COLLECT_LTO_WRAPPER=/atse_git/ostash/tc5/libexec/gcc/x86_64-pc-linux-gnu/5.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-5-20150728/configure --enable-bootstrap
--enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit
--disable-fixed-point --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-initfini-array --enable-languages=c,c++ --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-libstdcxx-time
--enable-libstdcxx-threads --disable-libquadmath --disable-libquadmath-support
--enable-linux-futex --enable-lto --disable-multiarch --disable-multilib
--disable-nls --enable-plugin --enable-secureplt --disable-sjlj-exceptions
--enable-threads=posix --enable-tls --enable-vtable-verify --disable-werror
--with-build-config=bootstrap-lto --with-default-libstdcxx-abi=gcc4-compatible
--with-diagnostics-color=auto --with-gnu-as --with-gnu-ld
--with-linker-hash-style=gnu --with-system-zlib --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--prefix=/atse_git/ostash/tc5
Thread model: posix
gcc version 5.2.1 20150728 (GCC)

[Bug lto/58528] lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:7478

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi ostash at ostash dot kiev.ua changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #7 from Viktor Ostashevskyi ostash at ostash dot kiev.ua ---
I managed to trigger this bug too:

lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:7478

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/atse_git/ostash/tc48/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-4.8-20140313/configure --enable-bootstrap
--enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit
--disable-fixed-point --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-initfini-array --enable-languages=c,c++ --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-libstdcxx-time
--disable-libquadmath --disable-libquadmath-support --enable-linux-futex
--enable-lto --disable-multiarch --disable-multilib --disable-nls
--enable-plugin --enable-secureplt --disable-sjlj-exceptions
--enable-threads=posix --enable-tls --with-build-config=bootstrap-lto
--with-gnu-as --with-gnu-ld --with-linker-hash-style=gnu --with-system-zlib
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu
Thread model: posix
gcc version 4.8.3 20140313 (prerelease) (GCC)

I can't provide sources unfortunately.

[Bug c++/59465] g++ allows direct-initialization of an array of class type from another array in a mem-initializer

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi ostash at ostash dot kiev.ua changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #1 from Viktor Ostashevskyi ostash at ostash dot kiev.ua ---
Another test case:

static const int my_size = 10;

class UserType
{
public:
  UserType(): f_(){}
private:
int f_;
};

#if 1
typedef UserType Array[my_size];
#else
typedef char Array[my_size];
#endif

class Foo
{
public:
  Foo(Array m) : m_(m) {};
private:
  Array m_;
};

Target: x86_64-pc-linux-gnu
gcc version 4.8.3 20140102 (prerelease)

In case when Array is char, g++ correctly states:
error: array used as initializer
   Foo(Array m) : m_(m) {};
   ^
but when Array is UserType there is no error.

clang 3.4 correctly produces an error for both cases:
error: array initializer must be an initializer list or string literal
  Foo(Array m) : m_(m) {};
  ^

or

error: array initializer must be an initializer list
  Foo(Array m) : m_(m) {};
  ^