[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc

2021-12-27 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Patrick Palka  ---
Fixed for GCC 12.

[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc

2021-12-27 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:916ec36d0a3ef3fe44c1657746922a5f18b60326

commit r12-6124-g916ec36d0a3ef3fe44c1657746922a5f18b60326
Author: Patrick Palka 
Date:   Mon Dec 27 10:01:42 2021 -0500

c++: Add testcase for SFINAE w/ p[N] and incomplete type [PR101239]

The r12-6123 fix for SFINAE with p+N and incomplete type also fixed
the analogous issue with p[N].

PR c++/101239

gcc/testsuite/ChangeLog:

* g++.dg/template/sfinae32a.C: New test.

[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc

2021-12-13 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239

--- Comment #5 from Andrew Pinski  ---
(In reply to Arthur O'Dwyer from comment #4)
> The problem seems to be something about over-eager hard-erroring on pointer
> arithmetic with incomplete types, because GCC also rejects this valid code:

I split that issue out into PR 103700 which I think is unrelated to the array
size of 0 issue listed here.

[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc

2021-12-13 Thread arthur.j.odwyer at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #4 from Arthur O'Dwyer  ---
I believe I just hit this as well. Here's a C++20 reproducer:

auto f(auto a) -> decltype(a+1) { return a+1; }
struct Incomplete *p;
auto b = f(p);

The problem seems to be something about over-eager hard-erroring on pointer
arithmetic with incomplete types, because GCC also rejects this valid code:

auto f(auto a) requires requires { a+1; } { return a+1; }
auto f(auto a) { return a; }
struct Incomplete *p;
auto b = f(p);

(Should call the unconstrained overload; but GCC hard-errors instead.)

[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc

2021-10-01 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||24663

--- Comment #3 from Andrew Pinski  ---
I suspect the real issue is with zero sized arrays which we had problems with
before; PR 24663 .


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24663
[Bug 24663] Template instantiation generating a zero-sized array doesn't fail

[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc

2021-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:b7a89c041aa1d67654f1ba7b2839e221c3e14748

commit r12-1844-gb7a89c041aa1d67654f1ba7b2839e221c3e14748
Author: Jonathan Wakely 
Date:   Mon Jun 28 12:59:19 2021 +0100

libstdc++: Allow unique_ptr::operator[] [PR 101236]

PR libstdc++/101236 shows that LLVM depends on being able to use
unique_ptr::operator[] when T is incomplete. This is undefined, but
previously worked with libstdc++. When I added the conditional noexcept
to that operator we started to diagnose the incomplete type.

This change restores support for that case, by making the noexcept
condition check that the type is complete before checking whether
indexing on the pointer can throw.  A workaround for PR c++/101239 is
needed to avoid a bogus error where G++ fails to do SFINAE on the
ill-formed p[n] expression and gets an ICE. Instead of checking that the
p[n] expression is valid in the trailing-return-type, we only check that
the element_type is complete.

libstdc++-v3/ChangeLog:

PR libstdc++/101236
* include/bits/unique_ptr.h (unique_ptr::operator[]):
Fail gracefully if element_type is incomplete.
* testsuite/20_util/unique_ptr/cons/incomplete.cc: Clarify that
the standard doesn't require this test to work for array types.
* testsuite/20_util/unique_ptr/lwg2762.cc: Check that incomplete
types can be used with array specialization.
* testsuite/20_util/unique_ptr/101236.cc: New test.

[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc

2021-06-28 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-28

--- Comment #1 from Jonathan Wakely  ---
This slight variation using noexcept in the trailing-return-type was
rejects-valid in 4.7 but is ice-on-valid-code from 4.8 onwards (with the same
ICE):

template
struct Blerk
{
  template
static constexpr auto
type(Ptr p = Ptr(), int n = 0)
-> decltype(noexcept(p[n]))
{ return false; }

  template
static constexpr int
type(...)
{ return 1; }

  decltype(type()) f() const;
};

struct S;
extern Blerk p;
auto s = p.f();
struct S { };