[Bug libstdc++/101659] _GLIBCXX_DEBUG mode for std::optional ?

2021-07-29 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101659

--- Comment #4 from Jonathan Wakely  ---
It might be nice to add them to std::experimental::optional too though.

[Bug libstdc++/101659] _GLIBCXX_DEBUG mode for std::optional ?

2021-07-29 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101659

--- Comment #3 from Jonathan Wakely  ---
Indeed. Marc added them in r8-711.

[Bug c/101645] warn about neg of unsigned type should be added to -Wsign-conversion

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

--- Comment #5 from Jonathan Wakely  ---
(I wrote this before comment 4 was added ...)

What would the precise semantics of the suggested warning be? What kind of
expressions do you expect to warn, and which should not?

How would I suppress the warning if -x is exactly what I intended to write and
it does exactly what I expect? For example, the implementation of std::align
uses:

inline void*
align(size_t __align, size_t __size, void*& __ptr, size_t& __space) noexcept
{
  if (__space < __size)
return nullptr;
  const auto __intptr = reinterpret_cast(__ptr);
  const auto __aligned = (__intptr - 1u + __align) & -__align;
  // ...

How would I prevent -__align from warning?

[Bug libstdc++/100381] [11/12 Regression] new static_assert((std::__is_complete_or_unbounded(...)) failure from g++ 11.1.0

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

--- Comment #2 from Jonathan Wakely  ---
This is almost certainly invalid code. Implementations are not required to
enforce the complete type precondition, so "other compilers don't reject it"
doesn't mean much. If the code has undefined behaviour then it's conforming to
accept it silently, or to reject it like this.

I haven't analyzed it in detail yet though.

[Bug testsuite/101646] [12 regression] excess errors after r12-2533

2021-07-27 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101646

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
Should be fixed now.

[Bug testsuite/101646] [12 regression] excess errors after r12-2533

2021-07-27 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101646

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-07-27
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The first test is buggy, it needs to include  to use std::exchange.

The second needs to include  to use std::array.

[Bug c++/101631] gcc permits object reference to object outside of its lifetime during constant evaluation

2021-07-27 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101631

--- Comment #3 from Jonathan Wakely  ---
(In reply to fsb4000 from comment #2)
> I'm confused with "What we do not want: Bugs in releases or snapshots of GCC
> not issued by the GNU Project. Report them to whoever provided you with the
> release".

10.3.0 is an official release. 10.3.1 or some heavily patched GCC would not be.

[Bug c++/101631] gcc permits object reference to object outside of its lifetime during constant evaluation

2021-07-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101631

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-26

--- Comment #1 from Jonathan Wakely  ---
(In reply to fsb4000 from comment #0)
> (Obligatory godbolt: https://godbolt.org/z/6qG7v9eYx)

Godbolt links are not obligatory, but a testcase is. See
https://gcc.gnu.org/bugs

[Bug c++/101622] Type erasure (upcasting) in constexpr/consteval context

2021-07-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101622

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-26

--- Comment #1 from Jonathan Wakely  ---
I think the code is valid.

[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument

2021-07-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57

--- Comment #48 from Jonathan Wakely  ---
No, as previously stated, it's suspended until the Core issue is resolved and
the standard is changed.

https://wg21.link/cwg325

[Bug c++/52099] Incorrectly applying conversion when catching pointer-to-members

2021-07-25 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099

--- Comment #2 from Jonathan Wakely  ---
>From the dup:


 Eric Fiselier 2016-01-20 03:50:56 UTC

Created attachment 37399 [details]
reproducer

I don't see where [except.handle] allows such a conversion.

Comment 1 Jonathan Wakely 2017-01-13 20:36:35 UTC

We're missing a check for cv-qualifiers in
__pointer_to_member_type_info::__pointer_catch that needs to be done before we
compare the pointees. Both pointees have type void() so we need to compare the
cv-quals before that info is lost.

Comment 2 Jonathan Wakely 2017-01-13 20:49:13 UTC

Hmm, we don't seem to have the cv-quals in __flags. That's a problem.

Comment 3 Jonathan Wakely 2017-01-13 21:08:10 UTC

When compiled with clang the pointees are different, so the match fails when
comparing them.

Using Clang:

(gdb) step
__cxxabiv1::__pbase_type_info::__pointer_catch (this=0x401cc0 , thrown_type=0x401d10 ,
thr_obj=0x7fffd220, outer=0)
at
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/cxxabi.h:309
(gdb) step
std::type_info::__do_catch (this=0x401c90 ,
thr_type=0x401cf8 ) at
../../../../libstdc++-v3/libsupc++/tinfo.cc:71
(gdb) p *this
$3 = {_vptr.type_info = 0x6030b0 , __name = 0x401c89  "KFvvE"}
(gdb) p *thr_type
$4 = {_vptr.type_info = 0x6030b0 , __name = 0x401cf0  "FvvE"}
(gdb) 


But using GCC the two pointee types are the same:

(gdb) p *this
$1 = {_vptr.type_info = 0x6030e8 , __name = 0x401c50  "FvvE"}
(gdb) p *thr_type
$2 = {_vptr.type_info = 0x6030e8 , __name = 0x401c50  "FvvE"}

So it looks like the problem is in the front-end where the typeinfo object for
a pointer to cv-qualified member function has the wrong pointee type.

Comment 4 Jonathan Wakely 2017-01-13 23:05:34 UTC

My front-end debugging skills are pitiful, but I've found something suspicious.
ptm_initializer uses TYPE_PTRMEM_POINTED_TO_TYPE to get that pointee type. For
this case that expands to TYPE_PTRMEMFUNC_FN_TYPE which is a call to
cp_build_qualified_type with the qualifiers from cp_type_quals.

But cp_type_quals tries pretty hard to ensure we never get cv-quals for a
function type. For the purposes of RTTI, where we really do care about the
difference between void() and void()const, do we want the memfn quals instead?

Comment 5 Jonathan Wakely 2017-01-13 23:20:33 UTC

For the attached reproducer this condition is never true in
cp_build_qualified_type_real

  /* But preserve any function-cv-quals on a FUNCTION_TYPE.  */
  if (TREE_CODE (type) == FUNCTION_TYPE)
type_quals |= type_memfn_quals (type);

As far as I can tell this is what's supposed to put the cv-quals back onto the
function type, so we'd have a pointee of type void() const not void().

[Bug c++/66763] [6 Regression] 25_algorithms/remove/requirements/explicit_instantiation/2.cc fails on AIX

2021-07-24 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66763

--- Comment #13 from Jonathan Wakely  ---
Ha! Oops

[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min

2021-07-23 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587

--- Comment #5 from Jonathan Wakely  ---
Yes, much simpler than that! :-)

There are lots of uses of std::min and std::max with explicit template argument
lists in the Parallel Mode headers, but I have no intention of touching them,
and they need to work as C++98 so couldn't use the function above anyway.

[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min

2021-07-23 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587

--- Comment #3 from Jonathan Wakely  ---
In theory yes, but it's unlikely to be a problem in practice because the
library doesn't need to compare unsigned types with negative values. If it does
need to do that, it is either already doing so carefully and correctly, or this
helper wouldn't make things worse.

I'm not suggesting designing a general purpose replacement for std::min that
handles all the possible corner cases, I'm just suggesting a convenience
function for our own internal needs.

All the uses in  are with iterator difference
types, which had better be signed, and distance(first, last) had better be
non-negative too.


include/bits/hashtable_policy.h does:

  const auto __max_width = std::min(sizeof(size_t), 8);

This is mixing unsigned and signed, but both positive.


include/bits/locale_conv.h:

   auto __nn = std::min(this->epptr() - this->pptr(),
__n - __done);

This compares ptrdiff_t with streamsize, which are both signed (and both values
here are guaranteed to be non-negative by construction).

[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min

2021-07-23 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug target/95286] -march=native causes mt19937_64 + uniform_real_distribution generating wrong result.

2021-07-23 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95286

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Jonathan Wakely  ---
Not a bug, as explained above.

[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min

2021-07-23 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587

--- Comment #1 from Jonathan Wakely  ---
Maybe we should add this somewhere and just stop using std::min for integers:

  struct __min_fn
  {
template
  typename common_type<_Tp, _Up>::type
  operator()(_Tp __t, _Up __u) const noexcept
  { return std::min::type>(__t, __u); }
  };
  _GLIBCXX17_INLINE constexpr __min_fn __min{};

[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min

2021-07-23 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-23

[Bug analyzer/94355] support for C++ new expression

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355

--- Comment #9 from Jonathan Wakely  ---
(In reply to William Navarre from comment #8)
> It seems that `operator new` is generally not supposed to return NULL --
> std::bad_alloc() is supposed to be thrown instead. 

If an operator new overload is declared noexcept, then it can return null on
failure. If it is not noexcept then it throws bad_alloc (or something derived
from it) and must never return null.


> 
> I made that change on my build (see below). I think that treating new's
> result as never-null is probably the correct thing to do most of the time,
> but two considerations: 
> 
> 1) The case of allocating a zero-length array. 

That still can't return null. It must return a valid non-null pointer, that
cannot be derefernced.

> 2) The case that a project has replaced `operator new.` (See "global
> replacements" at https://en.cppreference.com/w/cpp/memory/new/operator_new). 
> 
> Apparently projects can replace `operator new` (see "global replacements" at
> https://en.cppreference.com/w/cpp/memory/new/operator_new). It's not clear 

Exactly the same rules apply. If the operator new function is noexcept it
returns null to indicate allocation failure, otherwise it must throw and cannot
return null, ever.

[Bug libstdc++/101034] wrong constraint in std::any's constructor

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101034

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Jonathan Wakely  ---
Fixed for 9.5 and 10.4 and 11.2

[Bug libstdc++/90415] [9 Regression] std::is_copy_constructible> is incomplete

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #18 from Jonathan Wakely  ---
Fixed for 9.5 too.

[Bug libstdc++/92156] Cannot in-place construct std::any with std::any

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156

--- Comment #7 from Jonathan Wakely  ---
Fixed for 9.5 too.

[Bug libstdc++/100982] wrong constraint in std::optional::operator=

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100982

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Jonathan Wakely  ---
Fixed for 9.5 and 10.4 and 11.2

[Bug libstdc++/89322] Use of new and -lsupc++ requires -lstdc++ on architectures without atomics

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89322
Bug 89322 depends on bug 96657, which changed state.

Bug 96657 Summary: [9 Regression] libsupc++.a missing required functions from 
src/c++98/atomicity.cc when atomic builtins are not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug libstdc++/96657] [9 Regression] libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jonathan Wakely  ---
And also fixed for 9.5

The GCC 8.x branch is closed, so it can't be fixed there.

[Bug libstdc++/101583] [12 Regression] error: use of deleted function when building gold

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101583

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Jonathan Wakely  ---
Fixed!

[Bug libstdc++/101583] [12 Regression] error: use of deleted function when building gold

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101583

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |12.0
   Last reconfirmed||2021-07-22
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
Oops, I need to call the non-default constructor of the _Enable_special_members
base in all non-default constructors of _Hashtable.

[Bug libstdc++/96657] [9 Regression] libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
Summary|[9/10 Regression]   |[9 Regression] libsupc++.a
   |libsupc++.a missing |missing required functions
   |required functions from |from src/c++98/atomicity.cc
   |src/c++98/atomicity.cc when |when atomic builtins are
   |atomic builtins are not |not supported
   |supported   |

--- Comment #9 from Jonathan Wakely  ---
Also fixed for 10.4 now

[Bug libstdc++/98842] optional's spaceship operations generates wrong code when operator== is not present

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98842

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.4

--- Comment #6 from Jonathan Wakely  ---
Fixed for 10.4 and 11.2

[Bug c++/99625] GCC does not detect narrowing in aggregate initialization

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99625

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-22
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed, this should be a -Wnarrowing warning.

[Bug libstdc++/97570] avr-gcc: error: 'void* memalign' redeclared as different kind of entity

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97570

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |8.5
 Resolution|--- |FIXED

--- Comment #8 from Jonathan Wakely  ---
.

[Bug c++/98486] Variable template specialization doesn't account for primary's constraints

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98486

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-22
 Ever confirmed|0   |1
 Blocks||67491
 Status|UNCONFIRMED |NEW


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/96183] GCC accepts "convert '' from 'void' to 'int'" at compile time

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96183

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-22
 Status|UNCONFIRMED |NEW
   Keywords|accepts-invalid |diagnostic
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The 'auto' parameter makes this a function template, and you never instantiate
the template. Compilers are not required to diagnose errors in uninstantiated
templates.

If you call it, you get the expected error:

void 
foo (auto,
int var = throw )
{}

int main()
{
  foo(1);
}


96183.C: In function ‘void foo(auto:1, int) [with auto:1 = int]’:
96183.C:3:15: error: could not convert ‘’ from ‘void’ to
‘int’
3 | int var = throw )
  |   ^
  |   |
  |   void
96183.C:8:6: note:   when instantiating default argument for call to ‘void
foo(auto:1, int) [with auto:1 = int]’
8 |   foo(1);
  |   ~~~^~~
96183.C: In function ‘int main()’:
96183.C:8:6: error: void value not ignored as it ought to be

The second error seems bogus though.


Confirming as a diagnostic bug, but it's not accepts-invalid.

[Bug libstdc++/95702] ranges::transform missing vectorization opportunity

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95702

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-07-22
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
(In reply to Pilar Latiesa from comment #0)
> +   auto __d1 = ranges::distance(__first1, __last1);
> +   auto __d2 = ranges::distance(__first2, __last2);
> +   auto __n = std::min(__d1, __d2);

This won't compile if __d1 and __d2 have different types.

But the idea is certainly worth considering.

[Bug libstdc++/94345] std::chrono overflows due to c++14 non-compliance

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94345

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Jonathan Wakely  ---
Backported as r10-9609 for GCC 10.3

[Bug libstdc++/94295] use __builtin_operator_new and __builtin_operator_delete when available

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Jonathan Wakely  ---
Done for GCC 12.

[Bug libstdc++/98518] std::array not bound checked with _GLIBCXX_ASSERTIONS

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98518

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Jonathan Wakely  ---
Fixed by r11-4854

[Bug libstdc++/101571] DestroyGuard used by the ranges::uninitialized family should use addressof()

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101571

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |10.4
 Status|NEW |ASSIGNED

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk only so far.

[Bug libstdc++/100682] Outdated manual about the debug mode using

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100682

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk for now.

[Bug c++/101015] Poor diagnostic for deprecated alias-declaration

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101015

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84360

--- Comment #3 from Jonathan Wakely  ---
namespace v2
{
  template struct blargle { };
}

namespace v1
{
  template
using blargle [[deprecated("use v2::blargle instead of v1::blargle")]]
  = v2::blargle<_Tp>;
}

v1::blargle a;


da.C:13:18: warning: 'using blargle = struct v2::blargle' is deprecated:
use v2::blargle instead of v1::blargle [-Wdeprecated-declarations]
   13 | v1::blargle a;
  |  ^
da.C:9:11: note: declared here
9 | using blargle [[deprecated("use v2::blargle instead of
v1::blargle")]]
  |   ^~~


The expanded using-declaration is especially unhelpful when it re-uses the same
name in a different namespace. It would be better to print the type including
its namespace qualification:

warning: 'v1::blargle' is deprecated: ...

Maybe related to PR 84360

[Bug c++/84360] unnecessary aka in error message

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84360

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|9.5 |---

[Bug c++/101572] Temporary object lifetime is not prolonged as required by the standard

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101572

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-22
 Ever confirmed|0   |1
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
Confirmed. Not a regression as far as I can tell.

[Bug libstdc++/101571] DestroyGuard used by the ranges::uninitialized family should use addressof()

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101571

--- Comment #2 from Jonathan Wakely  ---
We should also do this:

--- a/libstdc++-v3/testsuite/util/testsuite_iterators.h
+++ b/libstdc++-v3/testsuite/util/testsuite_iterators.h
@@ -175,10 +175,14 @@ namespace __gnu_test
 #if __cplusplus >= 201103L
 template
   void operator,(const U&) const = delete;
+
+void operator&() const = delete;
 #else
   private:
 template
   void operator,(const U&) const;
+
+void operator&() const;
 #endif
   };

@@ -288,10 +292,14 @@ namespace __gnu_test
 #if __cplusplus >= 201103L
 template
   void operator,(const U&) const = delete;
+
+void operator&() const = delete;
 #else
   private:
 template
   void operator,(const U&) const;
+
+void operator&() const;
 #endif
   };

[Bug libstdc++/101571] DestroyGuard used by the ranges::uninitialized family should use addressof()

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101571

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-22

--- Comment #1 from Jonathan Wakely  ---
Rather than add __addressof everywhere, we could change the constructor to take
a reference and take the address in the constructor:

--- a/libstdc++-v3/include/bits/ranges_uninitialized.h
+++ b/libstdc++-v3/include/bits/ranges_uninitialized.h
@@ -106,8 +106,8 @@ namespace ranges

   public:
explicit
-   _DestroyGuard(const _Iter* __iter)
- : _M_first(*__iter), _M_cur(__iter)
+   _DestroyGuard(const _Iter& __iter)
+ : _M_first(__iter), _M_cur(std::__addressof(__iter))
{ }

void
@@ -149,7 +149,7 @@ namespace ranges
  return ranges::next(__first, __last);
else
  {
-   auto __guard = __detail::_DestroyGuard(&__first);
+   auto __guard = __detail::_DestroyGuard(__first);
for (; __first != __last; ++__first)
  ::new (__detail::__voidify(*__first)) _ValueType;
__guard.release();

and so on for each use of it.

But I also have a patch to just do this everywhere:

--- a/libstdc++-v3/include/bits/ranges_uninitialized.h
+++ b/libstdc++-v3/include/bits/ranges_uninitialized.h
@@ -149,7 +149,7 @@ namespace ranges
  return ranges::next(__first, __last);
else
  {
-   auto __guard = __detail::_DestroyGuard(&__first);
+   auto __guard = __detail::_DestroyGuard(std::__addressof(__first));
for (; __first != __last; ++__first)
  ::new (__detail::__voidify(*__first)) _ValueType;
__guard.release();

[Bug libstdc++/58909] C++11's condition variables fail with static linking

2021-07-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909

--- Comment #26 from Jonathan Wakely  ---
If you create a new thread of execution then you'll get a non-weak reference to
pthread_create, which should cause libpthread.so to be linked even with
-Wl,--as-needed (and for static linking it will work if libpthread.a has a
single .o with all symbols).

If you don't actually have multiple threads in your program, then things like
condition_variable and once_flag can end up using the stubs in libc.so.6 which
are no-ops. But since you don't have multiple threads, it's probably not a
major problem. Most uses of std::once_flag would be better done with a local
static variable anyway (the exception being non-static data members of
classes).

With glibc 2.34 the problem goes away, so I'm not sure it's worth investing
much effort in libstdc++ trying to work around the problems with weak symbols.

[Bug libstdc++/100682] Outdated manual about the debug mode using

2021-07-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100682

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.3

[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call

2021-07-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566

--- Comment #8 from Jonathan Wakely  ---
(In reply to Dale Weiler from comment #5)
> This is curious, omitting `decltype(auto)` for get, as in just `auto` seems
> to work around the issue as well.
> 
> template
> constexpr auto get(T tuple) { return *tuple(Get{}); }
> 
> I'm a bit out of my element here, in that I don't understand the semantic
> differences between the two and if that behavior is correct.

auto makes it return by value, decltype(auto) returns exactly the type of the
return statement (so if it's a reference, so is the return type).

[Bug libstdc++/40380] class documentation should mention include file to use

2021-07-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380

--- Comment #6 from Jonathan Wakely  ---
My doxygen patch was merged, so we can start to use SHOW_HEADERFILE and
@headerfile to do this.

[Bug libstdc++/101542] __gnu_cxx::sequence_buffer const copy constructor is badly broken

2021-07-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101542

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #5 from Jonathan Wakely  ---
Should be fixed now.

[Bug c++/100493] Lambda default copy capture that captures "this" cannot be used in both C++17 and C++20 modes

2021-07-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug libstdc++/101542] __gnu_cxx::sequence_buffer const copy constructor is badly broken

2021-07-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101542

--- Comment #3 from Jonathan Wakely  ---
(In reply to Brooks Moses from comment #0)
> This started failing with a recent Clang change
> (https://github.com/llvm/llvm-project/commit/
> 7d2d5a3a6d7aaa40468c30250bf6b0938ef02c08), described as "Apply P1825 as
> Defect Report from C++11 up to C++20".  See
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html for the
> defect report details.  I would guess that GCC will be applying a similar
> change.

GCC 11 already implemented that, see PR 91427 and the commit
https://gcc.gnu.org/g:1722e2013f05f1f1f99379dbaa0c0df356da731f

The for that commit says:

Discussion on the CWG reflector about how to avoid breaking the PR91212
test
in the new model settled on the model of doing only a single overload
resolution, with the variable treated as an xvalue that can bind to
non-const lvalue references.  So this patch implements that approach.  The
implementation does not use the existing LOOKUP_PREFER_RVALUE flag, but
instead sets a flag on the representation of the static_cast turning the
variable into an xvalue.

which says that calling sequence_buffer(sequence_buffer&) here is intended,
which is why we didn't see any change in the ext/rope/4.cc test when GCC
implemented it.

I still think we want to make sequence_buffer move-aware, so that you get the
same behaviour for:

template T f(T x) { return x; }
template T g(T x) { return std::move(x); }

when passed a sequence_buffer.

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

2021-07-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544

--- Comment #7 from Jonathan Wakely  ---
Yes, --disable-libstdcxx-hosted will build the freestanding version of
libstdc++

[Bug libstdc++/101542] __gnu_cxx::sequence_buffer const copy constructor is badly broken

2021-07-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101542

--- Comment #2 from Jonathan Wakely  ---
This should work:

--- a/libstdc++-v3/include/ext/rope
+++ b/libstdc++-v3/include/ext/rope
@@ -203,6 +203,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::copy(__x._M_buffer, __x._M_buffer + __x._M_buf_count, _M_buffer);
   }

+  // Non-const "copy" modifies the parameter - yuck
   sequence_buffer(sequence_buffer& __x)
   {
__x.flush();
@@ -213,6 +214,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   sequence_buffer(_Sequence& __s)
   : _M_prefix(&__s), _M_buf_count(0) { }

+  // Non-const "copy" modifies the parameter - yuck
   sequence_buffer&
   operator=(sequence_buffer& __x)
   {
@@ -230,7 +232,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::copy(__x._M_buffer, __x._M_buffer + __x._M_buf_count, _M_buffer);
return *this;
   }
-  
+
+#if __cplusplus >= 201103L
+  sequence_buffer(sequence_buffer&& __x) : sequence_buffer(__x) { }
+  sequence_buffer& operator=(sequence_buffer&& __x) { return *this = __x;
}
+#endif
+
   void
   push_back(value_type __x)
   {

[Bug libstdc++/101542] __gnu_cxx::sequence_buffer const copy constructor is badly broken

2021-07-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101542

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-21
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Brooks Moses from comment #0)
> But sequence_buffer is more broken than that: it also has another
> constructor, sequence_buffer(sequence_buffer&) that has different semantics:
> it flushes the source first. So if you only ever use non-const
> sequence_buffer objects, never modify a copied-from object, and never do
> anything that would call the sequence_buffer(const sequence_buffer&)
> constructor, it will appear to work. And that's what this test was relying
> on.

This constructor is similar to how std::auto_ptr "worked" and it was the source
of numerous defect reports and problems. It was removed from the standard years
ago and replaced with something that worked.

> we don't have any code
> that uses __gnu_cxx::sequence_buffer or __gnu_cxx::rope

I doubt anybody does. It's ancient and not really maintained now.

We can probably make it move-aware though.

[Bug libstdc++/101527] The implementation of std::common_iterator::operator== seems to be wrong

2021-07-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101527

--- Comment #2 from Jonathan Wakely  ---
I find it surprising, but the CWG consensus seems to be that a friend defined
inline in the class body is "a member declaration of the befriended class".

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

2021-07-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544

--- Comment #4 from Jonathan Wakely  ---
(In reply to Andrew Stubbs from comment #3)
> C++ offloading works fine provided that there are no library calls or
> exceptions.

There's no reason std::pair, std::tuple, std::optional and types like that
shouldn't work.

Just making it possible to compile with -fno-rtti -fno-exceptions would be a
start, and would avoid the need for exception handling. Libstdc++ headers
already work fine with those options, and it should be possible to build the
library itself that way (or it's a bug that can be fixed).

> Ignoring unsupported C++ language features, for now, I don't think there's
> any reason why libstdc++ would need to be cut down. We already build the
> full libgfortran for amdgcn. System calls that make no sense on the GPU were
> implemented as stubs in Newlib (mostly returning some reasonable errno
> value), and it would be straight-forward to implement more the same way.

But it's a waste of space in the .so to build lots of symbols that use the
stubs.

There are other reasons it might be nice to be able to configure libstdc++ for
something in between a full hosted environment and a minimal freestanding one.

> I believe static constructors work (libgfortran uses some), but exception
> handling does not. I'm not sure what other exotica C++ might need?

Ideally, __cxa_atexit and __cxa_thread_atexit for static and thread-local
destructors, but we can survive without them (and have not-fully-conforming
destruction ordering).

[Bug libstdc++/94295] use __builtin_operator_new and __builtin_operator_delete when available

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #11 from Jonathan Wakely  ---
Patches posted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575675.html

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101510

--- Comment #16 from Jonathan Wakely  ---
Fixed on trunk now, I'll backport it too, but not in time for 11.2

[Bug libstdc++/94295] use __builtin_operator_new and __builtin_operator_delete when available

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295

--- Comment #9 from Jonathan Wakely  ---
Thanks

[Bug c++/93652] -Wconversion gives false warning with bitwise operations on reference types returned from function

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93652

--- Comment #3 from Jonathan Wakely  ---
Fixed by r10-7344:
c++: Handle COMPOUND_EXPRs in get_narrower and
warnings_for_convert_and_check [PR91993]

[Bug c++/38522] -Wconversion does not handle complex bitwise expressions

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38522

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #12 from Jonathan Wakely  ---
Comment 3 was fixed by r230365 "Merge C++ delayed folding branch."

Comment 9 was fixed by r10-7344:
"c++: Handle COMPOUND_EXPRs in get_narrower and warnings_for_convert_and_check
[PR91993]"

[Bug c/53277] -Wconversion cannot handle compound expressions

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277

--- Comment #19 from Jonathan Wakely  ---
For C++ the comment 15 case seems to have been fixed by r10-6527:

c++: Use constexpr to avoid wrong -Wsign-compare (PR90691).

We would like to do constexpr evaluation to avoid false positives on
warnings, but constexpr evaluation can involve function body copying that
changes DECL_UID, which breaks -fcompare-debug.  So let's remember
that we need to avoid that.

PR c++/90691
* expr.c (fold_for_warn): Call maybe_constant_value.
* constexpr.c (struct constexpr_ctx): Add uid_sensitive field.
(maybe_constant_value): Add uid_sensitive parm.
(get_fundef_copy): Don't copy if it's true.
(cxx_eval_call_expression): Don't instantiate if it's true.
(cxx_eval_outermost_constant_expr): Likewise.

But it still warns when compiled as C.

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101510

--- Comment #13 from Jonathan Wakely  ---
(In reply to Madhu from comment #11)
> I think my initial problem remains

Well your "initial problem" was talking exclusively about create_directory,
which works perfectly.

There is a problem is a **different** function, however when you report a bug
saying "A doesn't work" it's hard to know that you meant "B doesn't work".

This is why you're supposed to provide a testcase, so we don't have to guess
what you're actually trying to say.

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101510

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #12 from Jonathan Wakely  ---
This is the code from create_directories:

  file_status st = symlink_status(p, ec);
  if (is_directory(st))
return false;
  else if (ec && !status_known(st))
return false;
  else if (exists(st))
{
  if (!ec)
ec = std::make_error_code(std::errc::not_a_directory);
  return false;
}


The first line should use status not symlink_status, that's the bug.

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101510

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|WAITING

--- Comment #10 from Jonathan Wakely  ---
So then that would be a problem with create_directories, not create_directory
(which is the subject of the bug you reported).

Could you please provide an actual (complete) testcase showing the actual
problem?

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101510

--- Comment #8 from Jonathan Wakely  ---
I think you are still confused between the bool that crate_directory returns,
and the bool that you get from !ec

The bool that is returned tells you if a new directory was created.

The bool you get from !ec tells you if the directory exists (whether it was
created or already existed).

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101510

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #6 from Jonathan Wakely  ---
(In reply to Madhu from comment #5)
> It looks like I did indeed get the semantics wrong

OK, thanks for confirming.

> I was going by the usage from databasePath() in
> https://github.com/WebKit/WebKit/blob/main/Source/WebKit/NetworkProcess/
> WebStorage/LocalStorageDatabaseTracker.cpp#L142
> which calls ensureDatabaseDirectoryExists() in
> https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/sql/
> SQLiteFileSystem.cpp#L59
> which calls makeAllDirectories()
> https://github.com/WebKit/WebKit/blob/main/Source/WTF/wtf/FileSystem.cpp#L733
> 
> The check is for only on the boolean value of ec, which is wrong
> according to the spec, Thanks!

That looks correct to me. It's the same as the example as I showed above.

If ec does not have a value, it means no error occurred. That means either the
directory was created, or already exists.

> Instead of precipitately filing the bug here I should have filed it
> with WebKit.

Are you *actually* seeing incorrect behaviour, or just concluding there is a
bug by reading the code?

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863

Jonathan Wakely  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jonathan Wakely  ---
Re-fixed.

[Bug c++/101519] Improve diagnostic for template name used as base class

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101519

--- Comment #2 from Jonathan Wakely  ---
See also PR 101526 which requests another improvement to the same diagnostic,
but with a different cause.

[Bug c++/101526] New: Improve diagnostic for trailing comma in base-clause in class-head

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101526

Bug ID: 101526
   Summary: Improve diagnostic for trailing comma in base-clause
in class-head
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct A { };
struct B : A, { };


GCC correctly says:

base.C:2:15: error: expected class-name before ‘{’ token
2 | struct B : A, { };
  |   ^

It would be nice if we offered a fix-it hint to remove the trailing comma.

This can easily happen when refactoring code if you remove the last base-class
from a list of several. When each base is on its own line, the location printed
is not helpful:

struct Base_class_one { };
struct Base_class_two_with_long_name { };
struct Claas
: Base_class_one,
  Base_class_two_with_long_name,
  // Removed_base_class
{
};


base.C:7:1: error: expected class-name before ‘{’ token
7 | {
  | ^

This would be much better if it pointed to the trailing comma, and suggested
removing it.

See also PR 101519 which requests another improvement to the same diagnostic,
but with a different cause.

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101510

--- Comment #4 from Jonathan Wakely  ---
I've added tests to verify that the behaviour is correct, and those tests pass
with all versions of GCC.

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101510

--- Comment #2 from Jonathan Wakely  ---
(In reply to Madhu from comment #0)
> cppreference.com states
> 
> ```   
> bool create_directory( const std::filesystem::path& p );
> 
> Creates the directory p as if by POSIX mkdir() with a second argument of
> static_cast(std::filesystem::perms::all) (the parent directory must
> already exist). If the function fails because p resolves to an existing
> directory, no error is reported. Otherwise on failure an error is reported.
> ```
> 
> This should accomodate situations when `p' resolves to an existing directory
> when `p' it is a symbolic link.
> 
> However create_directory(p) fails when p is a symbolic link which points
> to an existing directory.
> 
> The standard usage pattern is to call mkdir(p) - and if it fails on EEXIST
> to stat(2) p - following symlinks, and check if is a directory. The pattern
> is used to ensure that `p' can be treated as a directory for further
> operations and this includes p being a symbolic link to a directory)

You can do this with create_directory. If create_directory(p) doesn't throw an
exception, then is_directory(p) is true. Or without exceptions:

  std::error_code ec;
  create_directory(p, ec);
  if (!ec)
  {
// p resolves to a directory
  }

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101510

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #1 from Jonathan Wakely  ---
(In reply to Madhu from comment #0)
> However create_directory(p) fails when p is a symbolic link which points
> to an existing directory.

No it doesn't.

It returns false to tell you that it didn't create a directory, but "no error
is reported" as required by the specification. Returning false is not reporting
an error. If create_directory(p) reports an error then it throws an exception
of type filesystem_error, see
https://en.cppreference.com/w/cpp/filesystem/create_directory#Exceptions

Are you misunderstanding the function's semantics?

[Bug c++/101524] New: Improve diagnostic for incorrect definition of namespace alias

2021-07-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101524

Bug ID: 101524
   Summary: Improve diagnostic for incorrect definition of
namespace alias
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This is an incorrect attempt to define a namespace alias:

namespace x { namespace y { } }
using z = x::y;

GCC correctly says:

alias.C:2:14: error: ‘y’ in namespace ‘x’ does not name a type
2 | using z = x::y;
  |  ^
alias.C:1:25: note: ‘x::y’ declared here
1 | namespace x { namespace y { } }
  | ^

It might be nice in this case (where a using-declaration names a namespace, not
a type) to offer a fix-it to make it a namespace alias:

note: did you mean to define a namespace alias?
2 | using z = x::y;
  | ^
  | namespace

The suggestion won't always be correct, maybe the user meant to define a
typedef for a type x::Y or x::yo and the x::y was a typo. And given how rarely
namespace aliases are used, maybe that's more likely. But maybe it's worth
doing.

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

2021-07-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101510

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2021-07-19
 Ever confirmed|0   |1

[Bug c++/101519] New: Improve diagnostic for template name used as base class

2021-07-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101519

Bug ID: 101519
   Summary: Improve diagnostic for template name used as base
class
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template struct A { };
template struct B : A { };

a.C:2:35: error: expected class-name before ‘{’ token
2 | template struct B : A { };
  |   ^

While the error is technically correct, it would be more helpful to point out
that a template argument list is expected.


Clang does not better than GCC:

a.C:2:33: error: expected class name
template struct B : A { };
^
1 error generated.

But EDG does well:

"a.C", line 2: error: argument list for class template "A" is missing
  template struct B : A { };
  ^

"a.C", line 2: error: not a class or struct name
  template struct B : A { };
  ^

2 errors detected in the compilation of "a.C".


I think the current error would be fine if it was followed by a note:

note: 'A' is a class template; add a template argument list to use it as a
base-class

[Bug libstdc++/94295] use __builtin_operator_new and __builtin_operator_delete when available

2021-07-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295

--- Comment #7 from Jonathan Wakely  ---
Richard S., is there any reason to use the built-ins for the constant
evaluation case? I assume not. Currently std::allocator does:

  [[nodiscard,__gnu__::__always_inline__]]
  constexpr _Tp*
  allocate(size_t __n)
  {
#ifdef __cpp_lib_is_constant_evaluated
if (std::is_constant_evaluated())
  return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
#endif
return __allocator_base<_Tp>::allocate(__n, 0);
  }

and my assumption is that there is no reason to change this code, because the
benefits of __builtin_operator_new are only for run-time uses.

The calls to ::operator new in __allocator_base<_Tp>::allocate can use the
built-in though e.g.

--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -97,6 +97,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { return std::__addressof(__x); }
 #endif

+#if __has_builtin(__builtin_operator_new) >= 201802L
+# define _GLIBCXX_OPERATOR_NEW __builtin_operator_new
+# define _GLIBCXX_OPERATOR_DELETE __builtin_operator_delete
+#else
+# define _GLIBCXX_OPERATOR_NEW ::operator new
+# define _GLIBCXX_OPERATOR_DELETE ::operator delete
+#endif
+
   // NB: __n is permitted to be 0.  The C++ standard says nothing
   // about what the return value is when __n == 0.
   _GLIBCXX_NODISCARD _Tp*
@@ -121,34 +129,38 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__)
  {
std::align_val_t __al = std::align_val_t(alignof(_Tp));
-   return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp), __al));
+   return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n * sizeof(_Tp),
+  __al));
  }
 #endif
-   return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
+   return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n * sizeof(_Tp)));
   }

   // __p is not permitted to be a null pointer.
   void
   deallocate(_Tp* __p, size_type __t __attribute__ ((__unused__)))
   {
+#if __cpp_sized_deallocation
+# define _GLIBCXX_SIZED_DEALLOC(p) p, __t * sizeof(_Tp)
+#else
+# define _GLIBCXX_SIZED_DEALLOC(p) p
+#endif
+
 #if __cpp_aligned_new
if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__)
  {
-   ::operator delete(__p,
-# if __cpp_sized_deallocation
- __t * sizeof(_Tp),
-# endif
- std::align_val_t(alignof(_Tp)));
+   _GLIBCXX_OPERATOR_DELETE(_GLIBCXX_SIZED_DEALLOC(__p),
+std::align_val_t(alignof(_Tp)));
return;
  }
 #endif
-   ::operator delete(__p
-#if __cpp_sized_deallocation
- , __t * sizeof(_Tp)
-#endif
-);
+   _GLIBCXX_OPERATOR_DELETE(_GLIBCXX_SIZED_DEALLOC(__p));
   }

+#undef _GLIBCXX_SIZED_DEALLOC
+#undef _GLIBCXX_OPERATOR_DELETE
+#undef _GLIBCXX_OPERATOR_NEW
+
 #if __cplusplus <= 201703L
   size_type
   max_size() const _GLIBCXX_USE_NOEXCEPT



I see no benefit to using __builtin_operator_new in
std::pmr::new_delete_resource either, because  that will usually be used
through virtual calls to std::pmr::memory_resource::do_allocate, and the actual
call to ::operator new is inside libstdc++.so, not visible to the compiler.

[Bug libstdc++/101055] [11/12 Regression] should use __has_cpp_attribute() with __ prefixed/suffixed names

2021-07-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101055

--- Comment #7 from Jonathan Wakely  ---
I think this also affects the Intel compiler, as the latest release doesn't
handle [[__no_unique_address__]].

[Bug libstdc++/101427] [11 Regression] std::get should refuse to compile if type is provided and it is duplicated in std::tuple

2021-07-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101427

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Jonathan Wakely  ---
Fixed for 11.2, thanks for the report.

[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new

2021-07-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=59894

--- Comment #9 from Jonathan Wakely  ---
I don't think this optimization should be on by default. A switch that says
"this program does not replace operator new and delete" would make it OK. That
is the subject of PR 59894.

[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new

2021-07-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480

--- Comment #8 from Jonathan Wakely  ---
But operator new is not defined in the runtime here, it's a replaceable global
allocation function. The assumption seems unsafe for replaceable functions that
users can define in their own code.

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

2021-07-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |---
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|RESOLVED|REOPENED

--- Comment #6 from Jonathan Wakely  ---
My fix causes a regression:

#include 

template 
  struct Allocator
  {
using value_type = Tp;

Allocator(int) noexcept { }

template 
  Allocator(const Allocator&) { }

Tp *allocate(std::size_t n)
{ return std::allocator().allocate(n); }

void deallocate(Tp *p, std::size_t n)
{ std::allocator().deallocate(p, n); }
  };

using Set = std::unordered_set, std::equal_to,
Allocator>;

static_assert( ! std::is_default_constructible::value, "" );

The standard doesn't require the trait to be true, but it was (because we
defined the default constructors as defaulted all the way down to the EBO
helper). With the change above, the EBO helper for an empty class does:

  _Hashtable_ebo_helper() noexcept(noexcept(_Tp())) : _Tp() { }

which is ill-formed now, not implicitly deleted.

I have a patch to make it use [[no_unique_address]], so we can default it
again.

[Bug c++/101500] [9/10/11/12 Regression] gcc accepts the code with extra curly braces

2021-07-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101500

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||10.3.0, 11.1.0, 12.0,
   ||8.1.0, 9.4.0
 CC||jason at gcc dot gnu.org
  Known to work||7.5.0
   Last reconfirmed||2021-07-19
 Ever confirmed|0   |1
Summary|gcc accepts the code with   |[9/10/11/12 Regression] gcc
   |extra curly braces  |accepts the code with extra
   ||curly braces
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
EDG v6.2 also accepts this, but Clang and MSVC don't.

GCC started to accept it at:

PR c++/85092 - C++17 ICE with unused list constructor.

* call.c (conv_binds_ref_to_prvalue): Also count ck_identity
from a TARGET_EXPR.

From-SVN: r259052


I'll confirm it as a regression, since it doesn't look like that intended to
change this case.

[Bug c++/90033] [concepts] ICE segfault evaluating a requires clause that transitively depends on itself

2021-07-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90033

--- Comment #3 from Jonathan Wakely  ---
It was fixed by the r10-3735 rewrite "Update the concepts implementation to
conform to C++20." That definitely isn't going to be backported.

[Bug c++/82833] [concepts] Out-of-line definition of nested class template errors with constraint (ICE)

2021-07-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82833

--- Comment #2 from Jonathan Wakely  ---
Looks like the ICE was fixed by the concepts rewrite in r10-3735 "Update the
concepts implementation to conform to C++20."


Valid C++20 testcase:

#include 
#include 

template 
concept CallYieldsType = requires(T t) {
  { std::invoke(A, t) } -> std::same_as;
};

template 
struct S {
  struct Z;


  template 
requires CallYieldsType
  struct N;
};

template 
template 
  requires CallYieldsType::Z>
struct S::N {
  Z (T t) {
return std::invoke(A, t);
  }
};


Bisections shows this started to be accepted with r11-3713:

c++: Set the constraints of a class type sooner [PR96229]

In the testcase below, during processing (at parse time) of Y's base
class X, convert_template_argument calls is_compatible_template_arg
to check if the template argument Y is no more constrained than the
parameter P.  But at this point we haven't yet set Y's constraints, so
get_normalized_constraints_from_decl yields NULL_TREE as the normal form
and caches this result into the normalized_map.

We set Y's constraints later in cp_parser_class_specifier_1 but the
stale normal form in the normalized_map remains.  This ultimately causes
us to miss the constraint failure for Y because according to the
cached normal form, Y is not constrained.

This patch fixes this issue by moving up the call to
associate_classtype_constraints so that we set constraints before we
start processing a class's bases.

gcc/cp/ChangeLog:

PR c++/96229
* parser.c (cp_parser_class_specifier_1): Move call to
associate_classtype_constraints from here to ...
(cp_parser_class_head): ... here.
* pt.c (is_compatible_template_arg): Correct documentation to
say "argument is _no_ more constrained than the parameter".

gcc/testsuite/ChangeLog:

PR c++/96229
* g++.dg/cpp2a/concepts-class2.C: New test.

[Bug libstdc++/101485] Calling std::equal with std::byte* does not use memcmp

2021-07-18 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93059
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-18

[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new

2021-07-18 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-18
 Ever confirmed|0   |1

[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new

2021-07-18 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||10.3.0
   Keywords||wrong-code
  Known to fail||11.1.0, 12.0
Summary|Miscompiled code involving  |[11/12 Regression]
   |operator new|Miscompiled code involving
   ||operator new
   Target Milestone|--- |11.2
 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Started with r11-4745

Add fnspecs for C++ new and delete operators

gcc/ChangeLog:

* gimple.c (gimple_call_fnspec): Handle C++ new and delete.
* gimple.h (gimple_call_from_new_or_delete): Constify parameter.

gcc/testsuite/ChangeLog:

* g++.dg/ipa/devirt-24.C: Update template.

[Bug c++/66968] Incorrect template argument shown in diagnostic

2021-07-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66968

--- Comment #7 from Jonathan Wakely  ---
To reproduce the std::tuple error above, use this code at r12-2379

#include 
std::tuple t;
auto a = std::get<1>(t);

[Bug c++/101477] Wrong location for unexpanded parameter pack in function template

2021-07-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101477

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-16
   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=51118
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug c++/101477] New: Wrong location for unexpanded parameter pack in function template

2021-07-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101477

Bug ID: 101477
   Summary: Wrong location for unexpanded parameter pack in
function template
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template
class tuple
{ };

template
tuple
get(const tuple& t)
{
  return t;
}

The error shows the wrong location:

t2.C:7:30: error: parameter packs not expanded with '...':
7 | get(const tuple&)
  |  ^
t2.C:7:30: note: 'Elements'

This case is especially confusing because the caret *almost* points to a
location where the pack *is* expanded, making it harder to spot the real
problem on the line above.

It should be:

t2.C:7:30: error: parameter packs not expanded with '...':
6 | tuple
  |   ^~~~
t2.C:7:30: note: 'Elements'

Even better would be to give a fix-it hint suggesting to add the ... after
Element, although that might be counterproductive sometimes. For example, in
this case the compiler probably won't guess where to put the ...

template
std::conjunction>
get(const tuple& t)
{
  return t;
}

The user probably wants std::conjunction...> not
std::conjunction>.

[Bug c++/66968] Incorrect template argument shown in diagnostic

2021-07-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66968

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2017-08-21 00:00:00 |2021-7-16

--- Comment #5 from Jonathan Wakely  ---
Seen with std::tuple and std::get too:

t2.C:38:16: error: use of deleted function 'typename enable_if<(i >= sizeof...
(Elements))>::type get(const tuple&) [with long unsigned int i =
1; Elements = {int}; typename enable_if<(i >= sizeof... (Elements))>::type =
void]'

It should be _Elements, but it shows _Types.

[Bug c++/55664] Missing diagnostic "dependent using declaration resolved to type without 'typename'"

2021-07-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55664

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Jonathan Wakely  ---
THe testcase is invalid, there are access errors. This fixes them, and
instantiates the template:

namespace std
{
  namespace thrust
  {
template < typename Derived >
  struct iterator_adaptor { typedef Derived base_type; };

template < typename Derived >
  struct pointer_base_base {
typedef thrust::iterator_adaptor < Derived > type;
  };

template < typename Derived >
  struct pointer_base : public pointer_base_base  :: type
  {
typedef typename pointer_base_base < Derived > :: type super_t;
using super_t::base_type;
  };

template < unsigned int DummyParameterToAvoidInstantiation >
  void mymalloc (thrust::pointer_base< void >) { };
  }
}

int main()
{
  std::thrust::pointer_base p;
  std::thrust::mymalloc<1>(p);
}

GCC still accepts this without an error. I'm not sure if the "down with
typename" changes in C++23 make it valid now anyway.

[Bug c++/53863] misleading error message for redefinitions

2021-07-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53863

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-16

--- Comment #2 from Jonathan Wakely  ---
Current trunk says this:

53863.C:2:12: error: 'a' conflicts with a previous declaration
2 | enum { a = 1 };
  |^
53863.C:1:8: note: previous declaration ' a'
1 | enum { a = 1 };
  |^

The caret on the error seems wrong, as it points to the initializer not the
enumerator. The note is correct.

[Bug c++/84895] Smarter suggestions for "private" accessor hints

2021-07-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84895

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|9.5 |---

[Bug c++/43253] improve diagnostics for invalid pseudo destructor call

2021-07-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43253

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-16

--- Comment #3 from Jonathan Wakely  ---
Now we say:

43253.C: In function 'int main()':
43253.C:4:13: error: expected identifier before 'int'
4 | x->~int();
  | ^~~

I suppose we could add a more specific diagnostic saying you can't do this.
It's not a high priority, because the code is nonsense anyway. Why would you
want to destroy an int explicitly? A pseudo-destructor call is only useful in
generic code where you don't know what the type is.

[Bug c++/15684] Pointer to member function called on incomplete type should diag

2021-07-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15684

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #17 from Jonathan Wakely  ---
This is Core DR 1340 which was moved as a DR in 2012, making the standard match
what all compilers already did.

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1340

[Bug libstdc++/101307] Variable templates for type traits—corrections

2021-07-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101307

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jonathan Wakely  ---
Fixed

[Bug c++/50462] poor diagnostics for missing parenthesis in call to method

2021-07-15 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462

--- Comment #7 from Jonathan Wakely  ---
Oh, it's the overloaded function thjat makes the difference between saying
"invalid use of non-static member function" and trying to do overload
resolution with an .


Reduced example that actually reproduces the original problem:

struct ostream { };

void operator<<(ostream, int) { }
void operator<<(ostream, void*) { }
void operator<<(ostream, char*) { }

struct V
{
int size() { return 0; };
int size() const { return 0; };
};

void print(V v)
{ ostream() << v.size; }


Which prints this with current trunk:

50462.C: In function 'void print(V)':
50462.C:14:13: error: no match for 'operator<<' (operand types are 'ostream'
and '')
   14 | { ostream() << v.size; }
  |   ~ ^~ ~~
  |   |  |
  |   ostream
50462.C:3:6: note: candidate: 'void operator<<(ostream, int)'
3 | void operator<<(ostream, int) { }
  |  ^~~~
50462.C:3:26: note:   no known conversion for argument 2 from '' to 'int'
3 | void operator<<(ostream, int) { }
  |  ^~~
50462.C:4:6: note: candidate: 'void operator<<(ostream, void*)'
4 | void operator<<(ostream, void*) { }
  |  ^~~~
50462.C:4:26: note:   no known conversion for argument 2 from '' to 'void*'
4 | void operator<<(ostream, void*) { }
  |  ^
50462.C:5:6: note: candidate: 'void operator<<(ostream, char*)'
5 | void operator<<(ostream, char*) { }
  |  ^~~~
50462.C:5:26: note:   no known conversion for argument 2 from '' to 'char*'
5 | void operator<<(ostream, char*) { }
  |  ^


I don't see why we should treat v.size any differently whether it's overloaded
or not. It's invalid either way, so we should fail similarly.

[Bug c++/101465] Poorly worded error from a call to a pointer-to-member function not wrapped in parentheses

2021-07-15 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101465

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-07-15
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
And we should issue a fix-it suggestion too.

I thought this was a dup of an existing bug, but I can't find one, so
confirmed.

  1   2   3   4   5   6   7   8   9   10   >