[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int

2019-05-26 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-05-26
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Igor Smirnov from comment #0)
> The identical problem was found for gcc versions 
> 4.8.5 (the output below is from it), 4.4.5, 4.4.7. 

All of these versions have been unsupported by the GCC project for many years.

Does the problem still exist in current releases?

[Bug libstdc++/90634] filesystem::path insane memory allocations

2019-05-26 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|9.0 |8.4

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> The correct results with 9.1.0 are:
> 
> allocating 21 bytes
> allocating 248 bytes
> about to quit. total allocated 269 bytes
> freed 248 bytes
> freed 21 bytes

Proof: https://wandbox.org/permlink/zJVe39jAZtL1p6je

[Bug libstdc++/90634] filesystem::path insane memory allocations

2019-05-26 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634

--- Comment #5 from Jonathan Wakely  ---
(In reply to baltic from comment #3)
> (In reply to Jonathan Wakely from comment #2)
>  
> > I'm not sure where the repeated 72 allocations come from, and can't check
> > the code right now, but the new code doesn't do it anyway.
> 
> It comes from std::string creation, which then is passed to path constructor.

No it doesn't, that's the 21 bytes.

With GCC 9.x the 72 bytes is sizeof(path), which comes from allocating a path.
It comes from each component of the path creating a vector during
parsing, and then if there's only one component it empties the vector again.
Those transient allocations could be avoided, so I'll change that for GCC
8.4.0, but there's nothing to do for GCC 9.x as it's already avoiding
unnecessary vector operations.

> > I think this can be considered fixed.
> 
> hardly. the gcc 9.1 is even worse in that regard, as it allocates 2kB of
> memory for the same case
> see the line:
> 
> about to quit. total allocated 2131 bytes
> 
> in here:
> https://wandbox.org/permlink/u9dEfPh1Zc5pmJ34

You should try using a real compiler and not only rely on wandbox. Maybe
there's something wrong with the wandbox compiler, but that result only happens
when using Boost (so you should take it up with Boost instead).

The correct results with 9.1.0 are:

allocating 21 bytes
allocating 248 bytes
about to quit. total allocated 269 bytes
freed 248 bytes
freed 21 bytes

(In reply to baltic from comment #4)
> besides the 269 bytes you have mentioned, is still x10 overhead for a 20
> chars string. and massively adds up, if you store a lot objects.

The overhead is linear in the number of components in the path, not the string
length. If you have a path with a single filename and no directories then the
overhead is nothing like 10x.

> for example, when i go around home folder on my machine and save all the
> found paths to vector, it takes 2.7GB, while should take ~150MB!! quite an
> overhead on a simple task, for a language which strives for efficiency.

So don't store them as filesystem::path objects then, store them as strings and
create a path as needed.

> check out clang, for example:
> https://wandbox.org/permlink/u9dEfPh1Zc5pmJ34
> it's smart enough to allocate such short strings inplace:
> about to quit. total allocated 0 bytes

GCC will also create short strings in place, but with a different limit for
what is considered "short".

GCC's implementation creates the path components eagerly, so that
path::iterator meets the requirements of a forward iterator, whereas the libc++
implementation creates them lazily during iteration, and so is not a valid
forward iterator. This fails with libc++:

https://wandbox.org/permlink/eas3ZqA2CojecrQJ

The implementations have different trade-offs. That is not a bug.

[Bug libstdc++/90634] filesystem::path insane memory allocations

2019-05-26 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
The 813 bytes seen with GCC 8.x is due to reallocations within std::vector, as
the sequence of path objects in  [begin(),end()) is populated. The new code
counts the number of components first, so there's no need to keep growing as
the path is parsed. The sequence no longer uses std::vector at all, which also
reduces sizeof(path).

I'm not sure where the repeated 72 allocations come from, and can't check the
code right now, but the new code doesn't do it anyway. I think this can be
considered fixed.

[Bug libstdc++/90634] filesystem::path insane memory allocations

2019-05-26 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634

--- Comment #1 from Jonathan Wakely  ---
The path type was rewritten for GCC 9, and now prints:

allocating 21 bytes
allocating 248 bytes
about to quit.
total allocated 269 bytes
freed 248 bytes
freed 21 bytes

The 21 bytes is for the native() string, and 248 bytes is the sequence of path
objects in the range [begin(),end()).

[Bug c++/58798] class with a class reference member generates unjustified warning

2019-05-25 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58798

--- Comment #8 from Jonathan Wakely  ---
(In reply to Szikra from comment #3)
> I have found a suggestion to hide warning about ignored attributes:
> #pragma clang diagnostic ignored "-Wignored-attributes"
> which doesn't seem to have a GCC equivalent. :(

I'm pretty sure Clang copied that feature from GCC:


https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas

[Bug libstdc++/85965] [8/9/10 Regression] G++ gives cryptic error instead of incomplete type

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

--- Comment #17 from Jonathan Wakely  ---
Author: redi
Date: Fri May 24 16:09:28 2019
New Revision: 271607

URL: https://gcc.gnu.org/viewcvs?rev=271607=gcc=rev
Log:
PR libstdc++/85965 move is_invocable assertions again

This is another attempt to reduce how often the assertions are
evaluated, so that code which doesn't try to use the function objects
doesn't need them to be invocable.

For _Rb_tree we access the _M_key_compare object directly, so can't put
the assertions in an accessor function for it. However, every invocation
of _M_key_compare is accompanied by a use of _S_key, so the assertions
can be put in there.  For _Hashtable there are member functions that are
consistently used to obtain a hash code or test for equality, so the
assertions can go in those members.

Backport from mainline
2019-05-17  Jonathan Wakely  

PR libstdc++/85965
* include/bits/hashtable.h (_Hashtable::~_Hashtable()): Remove static
assertions from the destructor.
* include/bits/hashtable_policy.h (_Hash_code_base::_M_hash_code):
Move static_assert for hash function to here.
(_Hash_table_base::_M_equals): Move static_assert for equality
predicate to here.
* include/bits/stl_tree.h (_Rb_tree::_S_key(_Const_Link_type)): Move
assertions here. Access the value directly instead of calling _S_value.
(_Rb_tree::_S_key(_Const_Base_ptr)): Do downcast and forward to
_S_key(_Const_Link_type).
* testsuite/23_containers/set/85965.cc: Check construction,
destruction, assignment and size() do not trigger the assertions.
* testsuite/23_containers/unordered_set/85965.cc: Likewise.
* testsuite/23_containers/map/48101_neg.cc: Call find and adjust
expected errors.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/set/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_map/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_set/48101_neg.cc: Likewise.

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/bits/hashtable.h
branches/gcc-9-branch/libstdc++-v3/include/bits/hashtable_policy.h
branches/gcc-9-branch/libstdc++-v3/include/bits/stl_tree.h
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/multiset/48101_neg.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/set/48101_neg.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/set/85965.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/unordered_map/48101_neg.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/unordered_multimap/48101_neg.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/unordered_multiset/48101_neg.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/unordered_set/48101_neg.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/unordered_set/85965.cc

[Bug libstdc++/90618] new test case testsuite/20_util/shared_ptr/cons/alias-rval.cc introduced in r271583 fails

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90618

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Already fixed by r271603.

Somehow a half-finished test didn't fail (or I didn't notice the failure?) and
committed it.

[Bug c++/90320] [7/8/9/10 Regression] Explicit constructor called implicitly

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90320

--- Comment #2 from Jonathan Wakely  ---
(In reply to Adam Mitz from comment #0)
> May be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87605 but
> this doesn't involve the ternary operator.

It's similar, but I don't think it's the same bug, because the example in PR
87605 was always incorrectly accepted by GCC. The one here used to be rejected
and so is a regression.

[Bug c++/90320] [7/8/9/10 Regression] Explicit constructor called implicitly

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90320

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.5.0
   Keywords||rejects-valid
   Last reconfirmed||2019-05-24
 CC||paolo at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Explicit constructor called |[7/8/9/10 Regression]
   |implicitly  |Explicit constructor called
   ||implicitly
  Known to fail||10.0, 6.5.0, 7.4.0, 8.3.0,
   ||9.1.0

--- Comment #1 from Jonathan Wakely  ---
Here's a rejects-valid testcase that Clang and EDG accept:

struct M {
  M() = default;
  template  explicit M(T&&) = delete;
};

struct V {
  V(M m);
};

M m;
V v = m;

GCC tries to use the deleted constructor template instead of the copy
constructor when initializing the parameter of V::V(M):

m.cc:11:7: error: use of deleted function ‘M::M(T&&) [with T = M&]’
 V v = m;
   ^
m.cc:3:34: note: declared here
   template  explicit M(T&&) = delete;
  ^
m.cc:7:3: note:   initializing argument 1 of ‘V::V(M)’
   V(M m);
   ^

M::M(M&) is a better match for a non-const lvalue than the implicit
M::M(const M&) copy constructor, but because it's explicit it shouldn't be
used.

GCC 5 compiled it OK (with -std=c++11) but it started to be rejected with
r225705:

PR c++/54521
* call.c (convert_like_real): Do not set LOOKUP_ONLYCONVERTING for
the second step of copy-initialization.

[Bug libstdc++/90612] std::filesystem::path crash

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90612

--- Comment #3 from Jonathan Wakely  ---
N.B. for GCC9 you don't need to use -lstdc++fs for std::filesystem, only for
std::experimental::filesystem.

[Bug libstdc++/90557] [9/10 Regression] Incorrect std::filesystem::path::operator=(std::filesystem::path const&) in gcc 9.1.0

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557

Jonathan Wakely  changed:

   What|Removed |Added

 CC||terra at gnome dot org

--- Comment #5 from Jonathan Wakely  ---
*** Bug 90612 has been marked as a duplicate of this bug. ***

[Bug libstdc++/90612] std::filesystem::path crash

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90612

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
Already fixed.

*** This bug has been marked as a duplicate of bug 90557 ***

[Bug c++/90609] [9/10 Regression] Compilation error in std::function default member initialization inside template class with defaulted constructor

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90609

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #2 from Jonathan Wakely  ---
Reduced:

template T&& declval();

template struct function
{
  template()(declval()))>
function(F) { }
};

template
struct test
{
  function f = [](T *) {};
};

struct test2
{
  test d;
  test i;
};

template void make() { new T(); }

void g ()
{
  make();
}

[Bug c++/90609] [9/10 Regression] Compilation error in std::function default member initialization inside template class with defaulted constructor

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90609

Jonathan Wakely  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org
   Target Milestone|--- |9.2

--- Comment #1 from Jonathan Wakely  ---
This is a regression caused by r268850

PR c++/87322
* pt.c (tsubst_lambda_expr): Avoid duplicate tsubsting.
Move cp_evaluated resetting before signature tsubsting.
(gen_elem_of_pack_expansion_instantiation): Separate local
specializations per index.

[Bug libstdc++/90611] Generating a bad sse instruction for 32 bit

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90611

--- Comment #6 from Jonathan Wakely  ---
Oh, I forgot that I already implemented another option in
__gnu_cxx::malloc_allocator, which is to check the alignment of the returned
memory and only fail if it isn't suitably aligned:

  pointer
  allocate(size_type __n, const void* = 0)
  {
if (__n > this->max_size())
  std::__throw_bad_alloc();

pointer __ret = 0;
#if __cpp_aligned_new
#if __cplusplus > 201402L && _GLIBCXX_HAVE_ALIGNED_ALLOC
if (alignof(_Tp) > alignof(std::max_align_t))
  {
__ret = static_cast<_Tp*>(::aligned_alloc(alignof(_Tp),
  __n * sizeof(_Tp)));
  }
#else
# define _GLIBCXX_CHECK_MALLOC_RESULT
#endif
#endif
if (!__ret)
  __ret = static_cast<_Tp*>(std::malloc(__n * sizeof(_Tp)));
if (!__ret)
  std::__throw_bad_alloc();
#ifdef _GLIBCXX_CHECK_MALLOC_RESULT
#undef _GLIBCXX_CHECK_MALLOC_RESULT
  if (reinterpret_cast(__ret) % alignof(_Tp))
{
  // Memory returned by malloc is not suitably aligned for _Tp.
  deallocate(__ret, __n);
  std::__throw_bad_alloc();
}
#endif
return __ret;
  }

This means it might work sometimes, if you get lucky with malloc's return
value.

[Bug libstdc++/90611] Generating a bad sse instruction for 32 bit

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90611

--- Comment #5 from Jonathan Wakely  ---
We could do this in std::allocator:

--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -110,6 +110,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::align_val_t __al = std::align_val_t(alignof(_Tp));
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp), __al));
  }
+#elif __cplusplus >= 201103L
+   if (alignof(_Tp) > alignof(std::max_align_t))
+ __throw_bad_alloc();
 #endif
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
   }

Which would mean std::allocator refuses to allocate memory for overaligned
types in C++11 and C++14 unless -faligned-new is enabled.

I tried issuing a warning instead:

--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -35,6 +35,7 @@
 #include 
 #if __cplusplus >= 201103L
 #include 
+#include 
 #endif

 namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
@@ -110,10 +111,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::align_val_t __al = std::align_val_t(alignof(_Tp));
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp), __al));
  }
+#elif __cplusplus >= 201103L
+   if (alignof(_Tp) > alignof(std::max_align_t))
+ __overaligned();
 #endif
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
   }

+  void __overaligned() __attribute__((__warning__("use -faligned-new to
enable support for overaligned types"))) { }
+
   // __p is not permitted to be a null pointer.
   void
   deallocate(pointer __p, size_type __t)

But that warning is suppressed unless you use -Wsystem-headers.

Alternatively:

--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -35,6 +35,7 @@
 #include 
 #if __cplusplus >= 201103L
 #include 
+#include 
 #endif

 namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
@@ -110,6 +111,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::align_val_t __al = std::align_val_t(alignof(_Tp));
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp), __al));
  }
+#elif __cplusplus >= 201103L
+   static_assert(alignof(_Tp) <= alignof(std::max_align_t),
+   "use -faligned-new to support allocation of overaligned types");
 #endif
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
   }

But none of these would help for the original reproducer, because GCC 8 doesn't
think it's overaligned, because of the disagreement between max_align_t and
malloc.

[Bug libstdc++/90611] Generating a bad sse instruction for 32 bit

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90611

--- Comment #4 from Jonathan Wakely  ---
(In reply to Aaron Greig from comment #1)
> actually it seems that vector_size(16) creates a type that is over aligned,
> the following assert fails:
> 
> static_assert(std::alignment_of::value <= alignof(max_align_t), "over
> aligned!");

That should only fail with GCC 5, not with GCC 8.

Current versions of GCC defined max_align_t to have 16-byte alignment, so your
type is not overaligned with current versions (but as I said above, the old
glibc on Ubuntu 16.04 disagrees).

[Bug libstdc++/90611] Generating a bad sse instruction for 32 bit

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90611

--- Comment #3 from Jonathan Wakely  ---
(In reply to Aaron Greig from comment #0)
> Created attachment 46403 [details]
> cpp file that triggers the bug
> 
> I am finding that when I compile the attached file, with the following
> command:
> g++-8 -m32 -std=c++11 -msse -O3 repro.cpp -o repro -Wall -Wextra
> -fno-strict-aliasing -fwrapv
> I get this output:
> repro.cpp: In function ‘int main(int, char**)’:
> repro.cpp:13:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
>  int main(int argc, char** argv) {
>   ^~~~
> repro.cpp:13:27: warning: unused parameter ‘argv’ [-Wunused-parameter]
>  int main(int argc, char** argv) {
> ~~~^~~~

You know you can just declare int main() or int main(int, char**) to have a
reproducer that doesn't give any warnings, right?

> and when I run the resulting binary on a 32-bit system I get an immediate
> segfault. This seems to be due to a movaps instruction generating a general
> protection exception (see https://www.felixcloutier.com/x86/movaps) because
> the address it is loading from isn't aligned to 16 bytes. The minimal
> command I have found to reproduce this is
> g++-8 -m32 -std=c++11 -msse -O3 repro.cpp -o repro
> the output of g++-8 --version is:
> g++-8 (Ubuntu 8.3.0-6ubuntu1~18.04) 8.3.0
> The system I run the binary on is a virtualbox VM with 32-bit Ubuntu 16.04
> installed on it. I can reproduce this bug in the same way by compiling with
> that system's installed g++, version:
> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609

There are a few issues interacting here.

1) Glibc now (since version 2.26) returns 16-byte aligned memory from malloc,
so  this Just Works with a newer glibc. But if your code needed more than
16-byte alignment it would still fail even with a newer glibc, so let's assume
you needed 32-byte alignment...

2) In C++11 and C++14 the standard library does not support overaligned types,
it only supports the alignments that malloc supports. But C++17 added extended
alignment support to the standard library, so compiling with -std=c++17 or
-std=gnu++17 should make extended alignments work. You can also enable extended
alignment support for C++11 and C++14 with the -faligned-new flag. However ...

3) GCC assumes glibc malloc always returns 16-byte aligned memory, even if you
have glibc 2.25 or older, which only returns 8-byte alignment for x86. That
means GCC thinks 16-byte is not extended, but malloc disagrees. I'm trying to
fix that, see PR 90569.

4) To workaround PR 90569 you can use the -faligned-new=8 which tells GCC that
any alignment higher than 8 should be considered an extended alignment, and so
needs special handling (which means it doesn't use malloc, so isn't affected by
old versions of malloc only returning 8-byte alignment).

In summary: With a new glibc and C++17 extended alignments just work
automatically. For older glibc and/or C++11 you can use -faligned-new=8 to make
it work.

I think there is no GCC bug here (except for PR 90569 which I'm already working
on).

[Bug c++/90609] [9/10 Regression] Compilation error in std::function default member initialization inside template class with defaulted constructor

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90609

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-24
  Known to work||8.3.1
Summary|Compilation error in|[9/10 Regression]
   |std::function default   |Compilation error in
   |member initialization   |std::function default
   |inside template class with  |member initialization
   |defaulted constructor   |inside template class with
   ||defaulted constructor
 Ever confirmed|0   |1
  Known to fail||10.0, 9.1.0

[Bug c++/69864] Fix various Wnarrowing minor issues

2019-05-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864

Jonathan Wakely  changed:

   What|Removed |Added

 CC|redi at gcc dot gnu.org|

--- Comment #14 from Jonathan Wakely  ---
Un-CCing because I'm not going to work on this.

[Bug c++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90590

--- Comment #5 from Jonathan Wakely  ---
(In reply to Marek Polacek from comment #4)
> Suppressing the warning when the enumerator comes from a system header
> should be fairly easy using in_system_header_at.

Yes, I got that working myself already.


> But for the "use reserved
> names" requirement -- should we just check whether the name of an enumerator
> starts with an '_'?

No, because "_" and "_foo" are not reserved names.

I suggest "_[_A-Z]" i.e. underscore followed by either another underscore or
uppercase letter. In practice, for libstdc++'s purposes, it might be enough to
check for just "_[_S]" but I'd have to double-check that.

[Bug libstdc++/85998] feature request: support C++17 parallel STL

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85998

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.2 |9.0

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #7)
> GCC 9.1 has been released.

With Intel's PSTL included.

[Bug libstdc++/88740] [7 Regression] libstdc++ tests no longer print assertion failure messages

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88740

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 8.4 and 7.5 too.

[Bug libstdc++/88740] [7 Regression] libstdc++ tests no longer print assertion failure messages

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88740

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 15:34:37 2019
New Revision: 271569

URL: https://gcc.gnu.org/viewcvs?rev=271569=gcc=rev
Log:
PR libstdc++/88740 Print assertion messages to stderr

Backport from mainline
2019-01-22  Jonathan Wakely  

PR libstdc++/88740
* testsuite/util/testsuite_hooks.h [stderr] (VERIFY): Use fprintf to
write to stderr instead of using printf.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/testsuite/util/testsuite_hooks.h

[Bug libstdc++/89466] [7/8 Regression] Accessing the Internet while boostrapping

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89466

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #22 from Jonathan Wakely  ---
Fixed for 8.4 and 7.5 too.

[Bug libstdc++/89466] [7/8 Regression] Accessing the Internet while boostrapping

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89466

--- Comment #21 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 15:34:42 2019
New Revision: 271570

URL: https://gcc.gnu.org/viewcvs?rev=271570=gcc=rev
Log:
PR libstdc++/89466 avoid slow xsltproc command in configure

Certain broken versions of xsltproc ignore the --nonet option and will
attempt to fetch the docbook stylesheet from the WWW when it isn't in
the local XML catalog.

This patch checks for the local stylesheet directory first, and doesn't
use xsltproc if no local stylesheets are found. Checking for the local
directory is done using xmlcatalog if available, only checking the
hardcoded list of directories if xmlcatalog fails. The right directory
for Suse is added to the hardcoded list.

This should avoid doing an xsltproc check that would need to download
the stylesheet, so no network connection is made even if a broken
xsltproc is present.

Backport from mainline
2019-02-27  Jonathan Wakely  

PR libstdc++/89466
* acinclude.m4 (GLIBCXX_CONFIGURE_DOCBOOK): Reorder check for local
stylesheet directories before check for xsltproc. Try to use
xmlcatalog to find local stylesheet directory before trying hardcoded
paths. Add path used by suse to hardcoded paths. Adjust xsltproc
check to look for the same stylesheet as doc/Makefile.am uses. Don't
use xsltproc if xmlcatalog fails to find a local stylesheet.
* configure.ac: Check for xmlcatalog.
* Makefile.in: Regenerate.
* configure: Likewise.
* doc/Makefile.in: Likewise.
* include/Makefile.in: Likewise.
* libsupc++/Makefile.in: Likewise.
* po/Makefile.in: Likewise.
* python/Makefile.in: Likewise.
* src/Makefile.in: Likewise.
* src/c++11/Makefile.in: Likewise.
* src/c++17/Makefile.in: Likewise.
* src/c++98/Makefile.in: Likewise.
* src/filesystem/Makefile.in: Likewise.
* testsuite/Makefile.in: Likewise.

Added:
branches/gcc-7-branch/libstdc++-v3/src/c++17/
branches/gcc-7-branch/libstdc++-v3/src/c++17/Makefile.in
  - copied, changed from r271569,
branches/gcc-7-branch/libstdc++-v3/src/filesystem/Makefile.in
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/Makefile.in
branches/gcc-7-branch/libstdc++-v3/acinclude.m4
branches/gcc-7-branch/libstdc++-v3/configure
branches/gcc-7-branch/libstdc++-v3/configure.ac
branches/gcc-7-branch/libstdc++-v3/doc/Makefile.in
branches/gcc-7-branch/libstdc++-v3/include/Makefile.in
branches/gcc-7-branch/libstdc++-v3/libsupc++/Makefile.in
branches/gcc-7-branch/libstdc++-v3/po/Makefile.in
branches/gcc-7-branch/libstdc++-v3/python/Makefile.in
branches/gcc-7-branch/libstdc++-v3/src/Makefile.in
branches/gcc-7-branch/libstdc++-v3/src/c++11/Makefile.in
branches/gcc-7-branch/libstdc++-v3/src/c++98/Makefile.in
branches/gcc-7-branch/libstdc++-v3/src/filesystem/Makefile.in
branches/gcc-7-branch/libstdc++-v3/testsuite/Makefile.in

[Bug libstdc++/89466] [7/8 Regression] Accessing the Internet while boostrapping

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89466

--- Comment #20 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 15:34:25 2019
New Revision: 271568

URL: https://gcc.gnu.org/viewcvs?rev=271568=gcc=rev
Log:
PR libstdc++/89466 avoid slow xsltproc command in configure

Certain broken versions of xsltproc ignore the --nonet option and will
attempt to fetch the docbook stylesheet from the WWW when it isn't in
the local XML catalog.

This patch checks for the local stylesheet directory first, and doesn't
use xsltproc if no local stylesheets are found. Checking for the local
directory is done using xmlcatalog if available, only checking the
hardcoded list of directories if xmlcatalog fails. The right directory
for Suse is added to the hardcoded list.

This should avoid doing an xsltproc check that would need to download
the stylesheet, so no network connection is made even if a broken
xsltproc is present.

Backport from mainline
2019-02-27  Jonathan Wakely  

PR libstdc++/89466
* acinclude.m4 (GLIBCXX_CONFIGURE_DOCBOOK): Reorder check for local
stylesheet directories before check for xsltproc. Try to use
xmlcatalog to find local stylesheet directory before trying hardcoded
paths. Add path used by suse to hardcoded paths. Adjust xsltproc
check to look for the same stylesheet as doc/Makefile.am uses. Don't
use xsltproc if xmlcatalog fails to find a local stylesheet.
* configure.ac: Check for xmlcatalog.
* Makefile.in: Regenerate.
* configure: Likewise.
* doc/Makefile.in: Likewise.
* include/Makefile.in: Likewise.
* libsupc++/Makefile.in: Likewise.
* po/Makefile.in: Likewise.
* python/Makefile.in: Likewise.
* src/Makefile.in: Likewise.
* src/c++11/Makefile.in: Likewise.
* src/c++17/Makefile.in: Likewise.
* src/c++98/Makefile.in: Likewise.
* src/filesystem/Makefile.in: Likewise.
* testsuite/Makefile.in: Likewise.

Added:
branches/gcc-8-branch/libstdc++-v3/src/c++17/
branches/gcc-8-branch/libstdc++-v3/src/c++17/Makefile.in
  - copied, changed from r271563,
branches/gcc-8-branch/libstdc++-v3/src/filesystem/Makefile.in
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/Makefile.in
branches/gcc-8-branch/libstdc++-v3/acinclude.m4
branches/gcc-8-branch/libstdc++-v3/configure
branches/gcc-8-branch/libstdc++-v3/configure.ac
branches/gcc-8-branch/libstdc++-v3/doc/Makefile.in
branches/gcc-8-branch/libstdc++-v3/include/Makefile.in
branches/gcc-8-branch/libstdc++-v3/libsupc++/Makefile.in
branches/gcc-8-branch/libstdc++-v3/po/Makefile.in
branches/gcc-8-branch/libstdc++-v3/python/Makefile.in
branches/gcc-8-branch/libstdc++-v3/src/Makefile.in
branches/gcc-8-branch/libstdc++-v3/src/c++11/Makefile.in
branches/gcc-8-branch/libstdc++-v3/src/c++98/Makefile.in
branches/gcc-8-branch/libstdc++-v3/src/filesystem/Makefile.in
branches/gcc-8-branch/libstdc++-v3/testsuite/Makefile.in

[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90598

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Target Milestone|--- |9.2
Summary|Return type of explicit |[9/10 Regression] Return
   |destructor call wrong   |type of explicit destructor
   ||call wrong

--- Comment #1 from Jonathan Wakely  ---
The regression was caused by r259772

PR c++/61982 - dead stores to destroyed objects.

gcc/cp/
* call.c (build_trivial_dtor_call): New, assigns a clobber.
(build_over_call, build_special_member_call): Use it.
* cp-tree.h: Declare it.
* init.c (build_delete): Remove trivial path.
gcc/
* gimplify.c (gimplify_modify_expr): Simplify complex lvalue on LHS
of clobber.

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for 7.5 and 8.4 as well.

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 15:08:58 2019
New Revision: 271565

URL: https://gcc.gnu.org/viewcvs?rev=271565=gcc=rev
Log:
PR libstdc++/90220 Fix any_cast for non-object types

Backport from mainline
2019-04-24  Jonathan Wakely  

PR libstdc++/90220 (partial)
* include/std/any (any_cast(any*), any_cast(const any*)): Do
not attempt ill-formed static_cast to pointers to non-object types.
* testsuite/20_util/any/misc/any_cast.cc: Test std::any_cast with
function types.

Backport from mainline
2019-04-24  Jonathan Wakely  

PR libstdc++/90220
* include/std/any (__any_caster): Use remove_cv_t instead of decay_t.
Avoid a runtime check for types that can never be stored in std::any.
* testsuite/20_util/any/misc/any_cast.cc: Test std::any_cast with
array types.

Backport from mainline
2019-05-23  Jonathan Wakely  

PR libstdc++/90220
* include/experimental/any (__any_caster): Constrain to only be
callable for object types. Use remove_cv_t instead of decay_t.
If the type decays or isn't copy constructible, compare the manager
function to a dummy specialization.
(__any_caster): Add overload constrained for non-object types.
(any::_Manager_internal<_Op>): Add dummy specialization.
* testsuite/experimental/any/misc/any_cast.cc: Test function types
and array types.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/experimental/any
branches/gcc-7-branch/libstdc++-v3/include/std/any
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/any/misc/any_cast.cc

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 14:49:15 2019
New Revision: 271561

URL: https://gcc.gnu.org/viewcvs?rev=271561=gcc=rev
Log:
PR libstdc++/90220 Fix any_cast for non-object types

Backport from mainline
2019-04-24  Jonathan Wakely  

PR libstdc++/90220 (partial)
* include/std/any (any_cast(any*), any_cast(const any*)): Do
not attempt ill-formed static_cast to pointers to non-object types.
* testsuite/20_util/any/misc/any_cast.cc: Test std::any_cast with
function types.

Backport from mainline
2019-04-24  Jonathan Wakely  

PR libstdc++/90220
* include/std/any (__any_caster): Use remove_cv_t instead of decay_t.
Avoid a runtime check for types that can never be stored in std::any.
* testsuite/20_util/any/misc/any_cast.cc: Test std::any_cast with
array types.

Backport from mainline
2019-05-23  Jonathan Wakely  

PR libstdc++/90220
* include/experimental/any (__any_caster): Constrain to only be
callable for object types. Use remove_cv_t instead of decay_t.
If the type decays or isn't copy constructible, compare the manager
function to a dummy specialization.
(__any_caster): Add overload constrained for non-object types.
(any::_Manager_internal<_Op>): Add dummy specialization.
* testsuite/experimental/any/misc/any_cast.cc: Test function types
and array types.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/experimental/any
branches/gcc-8-branch/libstdc++-v3/include/std/any
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/experimental/any/misc/any_cast.cc

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569

--- Comment #9 from Jonathan Wakely  ---
(In reply to Florian Weimer from comment #8)
> The problem is that popular mallocs do not care about ABI and return
> unaligned pointers for allocations smaller than the max_align_t alignment. 
> As a result, __float128 support with 16-byte alignment would end up with a
> potentially rather short list of supported targets (including targets which
> have a 16-byte-aligned long double already).

Understood.

> I also found this for the first time:
> 
>   
> 
> So if the standard moves to the weak guarantee, GCC probably shouldn't make
> assumptions in the other direction.

Yes, I already fixed libstdc++ to not assume the strong-alignment reading, see
r265068.

But this PR isn't about the alignment of allocations where the size is smaller
than alignof(max_align_t). What makes my life difficult is that some mallocs
(including glibc up to 2.25) do not respect GCC's new alignof(max_align_t) even
for large allocations. I understand why, but it's just annoying that GCC
changed max_align_t to be misleading. If the underlying malloc doesn't agree,
making max_align_t lie isn't very helpful.

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 14:18:13 2019
New Revision: 271558

URL: https://gcc.gnu.org/viewcvs?rev=271558=gcc=rev
Log:
PR libstdc++/90220 fix experimental::any_cast for non-object types

This corresponds to the fixes done for std::any_cast, but has to be done
without if-constexpr. The dummy specialization of _Manager_internal<_Op>
is used to avoid instantiating the real _Manager_internal::_S_manage
function just to compare its address.

Backport from mainline
2019-05-23  Jonathan Wakely  

PR libstdc++/90220
* include/experimental/any (__any_caster): Constrain to only be
callable for object types. Use remove_cv_t instead of decay_t.
If the type decays or isn't copy constructible, compare the manager
function to a dummy specialization.
(__any_caster): Add overload constrained for non-object types.
(any::_Manager_internal<_Op>): Add dummy specialization.
* testsuite/experimental/any/misc/any_cast.cc: Test function types
and array types.

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/experimental/any
   
branches/gcc-9-branch/libstdc++-v3/testsuite/experimental/any/misc/any_cast.cc

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 13:39:06 2019
New Revision: 271556

URL: https://gcc.gnu.org/viewcvs?rev=271556=gcc=rev
Log:
PR libstdc++/90220 fix experimental::any_cast for non-object types

This corresponds to the fixes done for std::any_cast, but has to be done
without if-constexpr. The dummy specialization of _Manager_internal<_Op>
is used to avoid instantiating the real _Manager_internal::_S_manage
function just to compare its address.

PR libstdc++/90220
* include/experimental/any (__any_caster): Constrain to only be
callable for object types. Use remove_cv_t instead of decay_t.
If the type decays or isn't copy constructible, compare the manager
function to a dummy specialization.
(__any_caster): Add overload constrained for non-object types.
(any::_Manager_internal<_Op>): Add dummy specialization.
* testsuite/experimental/any/misc/any_cast.cc: Test function types
and array types.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/any
trunk/libstdc++-v3/testsuite/experimental/any/misc/any_cast.cc

[Bug c++/90592] Documentation: Missing word (or wrong parenthesization) in "Function Names as Strings"

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90592

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
Version|unknown |10.0
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #3 from Jonathan Wakely  ---
Fixed, thanks.

[Bug c++/90592] Documentation: Missing word (or wrong parenthesization) in "Function Names as Strings"

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90592

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 11:47:30 2019
New Revision: 271554

URL: https://gcc.gnu.org/viewcvs?rev=271554=gcc=rev
Log:
PR c++/90592 add missing word "scope" to __func__ docs

PR c++/90592
* doc/extend.texi (Function Names): Add missing word.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi

[Bug c++/90592] Documentation: Missing word (or wrong parenthesization) in "Function Names as Strings"

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90592

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
 Ever confirmed|0   |1

[Bug c++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90590

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
  Component|libstdc++   |c++
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Jonathan Wakely  ---
In theory we could do this to avoid the warning:

--- a/libstdc++-v3/include/bits/ios_base.h
+++ b/libstdc++-v3/include/bits/ios_base.h
@@ -189,13 +189,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   operator^=(_Ios_Iostate& __a, _Ios_Iostate __b)
   { return __a = __a ^ __b; }

+  enum _Ios_Seekdir_range
+{
+  _S_ios_seekdir_beg_ = 0,
+  _S_ios_seekdir_end = 1L << 16
+};

-  enum _Ios_Seekdir 
+  enum _Ios_Seekdir : __underlying_type(_Ios_Seekdir_range)
 { 
   _S_beg = 0,
   _S_cur = _GLIBCXX_STDIO_SEEK_CUR,
-  _S_end = _GLIBCXX_STDIO_SEEK_END,
-  _S_ios_seekdir_end = 1L << 16 
+  _S_end = _GLIBCXX_STDIO_SEEK_END
 };


But giving the enum a fixed underlying type changes its semantics, as now any
value of the underlying type is a valid value of the enumeration type.

As I said in the Clang bug, I think a better approach would be to suppress the
warning for enumerators that are defined in system headers and that use
reserved names.

So I'm changing this to a compiler enhancement request, to suppress this
warning for cases like this.

[Bug libstdc++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90590

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> This is not a libstdc++ bug, we're allowed to define whatever enumerators we
> want as long as they use reserved names.

Which is almost exactly what I said in the Clang bug you linked to. Nice to
know I'm consistent.

[Bug libstdc++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90590

--- Comment #1 from Jonathan Wakely  ---
This is not a libstdc++ bug, we're allowed to define whatever enumerators we
want as long as they use reserved names.

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90584

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|MOVED   |INVALID

--- Comment #3 from Jonathan Wakely  ---
Putting "[gdb]" in the bug summary suggests you're trying to report a GDB bug,
which doesn't belong here.

You're trying to put a breakpoint on a line with no code, which won't work. Try
breaking on line 12.

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569

--- Comment #7 from Jonathan Wakely  ---
The glibc change was https://sourceware.org/bugzilla/show_bug.cgi?id=21120 and
is present from version 2.26

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90584

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Jonathan Wakely  ---
GDB is a separate project with its own bugzilla, see
https://sourceware.org/bugzilla

[Bug c++/90415] [10 Regression] std::is_copy_constructible> is incomplete

2019-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||8.3.0, 9.1.1
   Keywords||rejects-valid
   Last reconfirmed||2019-05-23
  Component|libstdc++   |c++
 CC|jason at redhat dot com|jason at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|std::is_copy_constructible< |[10 Regression]
   |std::tuple> is|std::is_copy_constructible<
   |incomplete  |std::tuple> is
   ||incomplete
  Known to fail||10.0

--- Comment #4 from Jonathan Wakely  ---
Thanks for the bisection.

Changing component to c++ for now, although it's possible a fix is needed in
the library.

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569

--- Comment #6 from Jonathan Wakely  ---
This bug also affects 32-bit GNU/Linux with older versions of glibc.

[Bug libstdc++/90557] [9/10 Regression] Incorrect std::filesystem::path::operator=(std::filesystem::path const&) in gcc 9.1.0

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for GCC 9.2 and trunk. Thanks for the report.

[Bug libstdc++/90557] [9/10 Regression] Incorrect std::filesystem::path::operator=(std::filesystem::path const&) in gcc 9.1.0

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed May 22 22:36:21 2019
New Revision: 271528

URL: https://gcc.gnu.org/viewcvs?rev=271528=gcc=rev
Log:
PR libstdc++/90557 fix path assignment that alters source

Backport from mainline
2019-05-22  Jonathan Wakely  

PR libstdc++/90557
* src/c++17/fs_path.cc (path::_List::operator=(const _List&)): Fix
reversed arguments to uninitialized_copy_n.
* testsuite/27_io/filesystem/path/assign/copy.cc: Check that source
is unchanged by copy assignment.
* testsuite/util/testsuite_fs.h (compare_paths): Use std::equal to
compare path components.

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/src/c++17/fs_path.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/path/assign/copy.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/util/testsuite_fs.h

[Bug libstdc++/90557] [9/10 Regression] Incorrect std::filesystem::path::operator=(std::filesystem::path const&) in gcc 9.1.0

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Wed May 22 22:14:34 2019
New Revision: 271527

URL: https://gcc.gnu.org/viewcvs?rev=271527=gcc=rev
Log:
PR libstdc++/90557 fix path assignment that alters source

PR libstdc++/90557
* src/c++17/fs_path.cc (path::_List::operator=(const _List&)): Fix
reversed arguments to uninitialized_copy_n.
* testsuite/27_io/filesystem/path/assign/copy.cc: Check that source
is unchanged by copy assignment.
* testsuite/util/testsuite_fs.h (compare_paths): Use std::equal to
compare path components.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++17/fs_path.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/assign/copy.cc
trunk/libstdc++-v3/testsuite/util/testsuite_fs.h

[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug libstdc++/90557] [9/10 Regression] Incorrect std::filesystem::path::operator=(std::filesystem::path const&) in gcc 9.1.0

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||8.3.0
   Target Milestone|--- |9.2
Summary|Incorrect   |[9/10 Regression] Incorrect
   |std::filesystem::path::oper |std::filesystem::path::oper
   |ator=(std::filesystem::path |ator=(std::filesystem::path
   |const&) in gcc 9.1.0|const&) in gcc 9.1.0
  Known to fail||10.0, 9.1.0

[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691

--- Comment #39 from Jonathan Wakely  ---
(In reply to dave.anglin from comment #37)
> I believe I changed the glibc value because of the pthread mutex issue.

Aha.

> MALLOC_ABI_ALIGNMENT is defined in pa32-linux.h as follows:
> #define MALLOC_ABI_ALIGNMENT 128
> 
> So, the defines are now consistent on linux.  The only remaining problem is
> 64-bit hpux where the actual
> malloc alignment is 8 bytes.  The resource_adapter.cc test still fails on

I've just committed a change to the resource_adaptor implementation, but I
don't expect it to change the FAIL for hpux yet. I hope the FAILs are fixed for
Solaris now though, and if so then we make the special case apply to 64-bit
hpux too, like so (are these the right macros to check for?):

diff --git a/libstdc++-v3/include/experimental/memory_resource
b/libstdc++-v3/include/experimental/memory_resource
index dde3753fab7..dd6f3099a78 100644
--- a/libstdc++-v3/include/experimental/memory_resource
+++ b/libstdc++-v3/include/experimental/memory_resource
@@ -413,7 +413,8 @@ namespace pmr {
   do_allocate(size_t __bytes, size_t __alignment) override
   {
// Cannot use max_align_t on 32-bit Solaris x86, see PR libstdc++/77691
-#if ! (defined __sun__ && defined __i386__)
+#if ! (defined __sun__ && defined __i386__) \
+   && ! (defined __hpux && defined _LP64)
if (__alignment == alignof(max_align_t))
  return _M_allocate(__bytes);
 #endif
@@ -439,7 +440,8 @@ namespace pmr {
   do_deallocate(void* __ptr, size_t __bytes, size_t __alignment) noexcept
   override
   {
-#if ! (defined __sun__ && defined __i386__)
+#if ! (defined __sun__ && defined __i386__) \
+   && ! (defined __hpux && defined _LP64)
if (__alignment == alignof(max_align_t))
  return (void) _M_deallocate(__ptr, __bytes);
 #endif
diff --git
a/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
b/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
index 7dcb408f3f7..d4353ff6464 100644
---
a/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
+++
b/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
@@ -23,7 +23,8 @@
 #include 
 #include 

-#if defined __sun__ && defined __i386__
+#if (defined __sun__ && defined __i386__) \
+   || (defined __hpux && defined _LP64)
 // See PR libstdc++/77691
 # define BAD_MAX_ALIGN_T 1
 #endif




> it.  Maybe I should change BIGGEST_ALIGNMENT
> and MALLOC_ABI_ALIGNMENT to match the malloc implementation?

I think that makes sense (although it won't change anything until we make the
suggestion from PR 90569 as well, so I'll do that this week).

[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691

--- Comment #38 from Jonathan Wakely  ---
Author: redi
Date: Wed May 22 20:29:39 2019
New Revision: 271522

URL: https://gcc.gnu.org/viewcvs?rev=271522=gcc=rev
Log:
PR libstdc++/77691 fix resource_adaptor failures due to max_align_t bugs

Remove the hardcoded whitelist of allocators expected to return memory
aligned to alignof(max_align_t), because that doesn't work when the
platform's malloc() and GCC's max_align_t do not agree what the largest
fundamental alignment is. It's also sub-optimal for user-defined
allocators that return memory suitable for any fundamental alignment.

Instead use a hardcoded list of alignments that are definitely supported
by the platform malloc, and use a copy of the allocator rebound to a POD
type with the requested alignment. Only allocate an oversized
buffer to use with std::align for alignments larger than any of the
hardcoded values.

For 32-bit Solaris x86 do not include alignof(max_align_t) in the
hardcoded values.

PR libstdc++/77691
* include/experimental/memory_resource: Add system header pragma.
(__resource_adaptor_common::__guaranteed_alignment): Remove.
(__resource_adaptor_common::_Types)
(__resource_adaptor_common::__new_list)
(__resource_adaptor_common::_New_list)
(__resource_adaptor_common::_Alignments)
(__resource_adaptor_common::_Fund_align_types): New utilities for
creating a list of types with fundamental alignments.
(__resource_adaptor_imp::do_allocate): Call new _M_allocate function.
(__resource_adaptor_imp::do_deallocate): Call new _M_deallocate
function.
(__resource_adaptor_imp::_M_allocate): New function that first tries
to use an allocator rebound to a type with a fundamental alignment.
(__resource_adaptor_imp::_M_deallocate): Likewise for deallocation.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Adjust expected allocation sizes.
* testsuite/experimental/memory_resource/resource_adaptor.cc: Remove
xfail.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/memory_resource
   
trunk/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
   
trunk/libstdc++-v3/testsuite/experimental/memory_resource/resource_adaptor.cc

[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691

--- Comment #36 from Jonathan Wakely  ---
Interesting. Yes, definitely similar ideas. It looks like it was solved
differently though, as config/pa/pa.h has

#define MALLOC_ABI_ALIGNMENT (TARGET_64BIT ? 128 : 64)

which should get used by the aligned new code, even without my suggested change
in PR 90569.

As an aside, the comment on MALLOC_ABI_ALIGNMENT says "The glibc implementation
currently provides 8-byte alignment." But glibc malloc was changed to 16-byte
alignment a couple of years ago.

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> Rainer, the change to gcc/cp/init.c would allow you to do:
> 
> #define MALLOC_ABI_ALIGNMENT 8

Oops, it's in bits not bytes, so that should be

#define MALLOC_ABI_ALIGNMENT 64

[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691

--- Comment #34 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #33)
> The correct fix is to adjust the value of __STDCPP_DEFAULT_NEW_ALIGNMENT__
> on targets where malloc doesn't agree with GCC's alignof(max_align_t).

That only helps for C++17 and later though :-(

The  header is defined for C++14.

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569

--- Comment #4 from Jonathan Wakely  ---
Rainer, the change to gcc/cp/init.c would allow you to do:

#define MALLOC_ABI_ALIGNMENT 8

in gcc/config/i386/sol2.h and that would cause std::allocator to know that it
can't rely on malloc for 16-byte alignment.

Although that would only help for C++17, because otherwise __cpp_aligned_new
isn't defined ... drat.

It's better than nothing though.

Does that seem acceptable for your target?

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-22
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
I thought we could workaround this in libstdc++ like so:

diff --git a/libstdc++-v3/libsupc++/Makefile.am
b/libstdc++-v3/libsupc++/Makefile.am
index eec7b953514..a50a9848461 100644
--- a/libstdc++-v3/libsupc++/Makefile.am
+++ b/libstdc++-v3/libsupc++/Makefile.am
@@ -129,6 +129,8 @@ cp-demangle.o: cp-demangle.c


 # Use special rules for the C++17 sources so that the proper flags are passed.
+new_op.lo: new_op.cc
+   $(LTCXXCOMPILE) -std=gnu++1z -c $<
 new_opa.lo: new_opa.cc
$(LTCXXCOMPILE) -std=gnu++1z -c $<
 new_opant.lo: new_opant.cc
diff --git a/libstdc++-v3/libsupc++/Makefile.in
b/libstdc++-v3/libsupc++/Makefile.in
index 5d8ac5ca0ba..0e3cbff0055 100644
--- a/libstdc++-v3/libsupc++/Makefile.in
+++ b/libstdc++-v3/libsupc++/Makefile.in
@@ -956,6 +956,8 @@ cp-demangle.o: cp-demangle.c
$(C_COMPILE) -DIN_GLIBCPP_V3 -Wno-error -c $<

 # Use special rules for the C++17 sources so that the proper flags are passed.
+new_op.lo: new_op.cc
+   $(LTCXXCOMPILE) -std=gnu++1z -c $<
 new_opa.lo: new_opa.cc
$(LTCXXCOMPILE) -std=gnu++1z -c $<
 new_opant.lo: new_opant.cc
diff --git a/libstdc++-v3/libsupc++/new_op.cc
b/libstdc++-v3/libsupc++/new_op.cc
index 863530b7564..203c57d9171 100644
--- a/libstdc++-v3/libsupc++/new_op.cc
+++ b/libstdc++-v3/libsupc++/new_op.cc
@@ -27,6 +27,9 @@
 #include 
 #include 
 #include "new"
+#if defined __sun__ || defined __i386__
+# include 
+#endif

 using std::new_handler;
 using std::bad_alloc;
@@ -41,6 +44,14 @@ extern "C" void *malloc (std::size_t);
 _GLIBCXX_WEAK_DEFINITION void *
 operator new (std::size_t sz) _GLIBCXX_THROW (std::bad_alloc)
 {
+#if defined __sun__ || defined __i386__
+  if (sz >= alignof(std::max_align_t))
+{
+  std::align_val_t al{alignof(std::max_align_t)};
+  return ::operator new(sz, al);
+}
+#endif
+
   void *p;

   /* malloc (0) is unpredictable; avoid it.  */



This would force operator new to use aligned_alloc instead of malloc for
allocations that might be for objects large enough to require greater alignment
than malloc guarantees. But since Solaris 11 doesn't appear to define
aligned_alloc, this would use the fallback implementation in
libsupc++/new_opa.cc which is much less efficient than plain malloc.

[Bug bootstrap/90543] Build failure on MINGW for gcc-9.1.0

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90543

--- Comment #6 from Jonathan Wakely  ---
Neither uintptr_t nor PRIxPTR (nor long long nor uint64_t) is part of C++98,
which GCC still requires. I do see existing uses of intptr_t and uintptr_t in
gcc/cp/*.c though.

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569

--- Comment #1 from Jonathan Wakely  ---
(I'm starting to think that __float128 support should have been disabled on
targets where it requires greater alignment than malloc guarantees, instead of
making GCC's max_align_t lie).

[Bug c++/90569] New: __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569

Bug ID: 90569
   Summary: __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for
i386-pc-solaris2.11
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11

The default value for __STDCPP_DEFAULT_NEW_ALIGNMENT__ is alignof(max_align_t),
but GCC's max_align_t does not agree with the OS on i386-pc-solaris2.*, see PR
77691. This means that operator new(size_t) does not necessarily meet the
guarantee that __STDCPP_DEFAULT_NEW_ALIGNMENT__ is supposed to provide.

It looks like changing MALLOC_ABI_ALIGNMENT for the target should work, except
for this in gcc/cp/init.c:

/* Return the alignment we expect malloc to guarantee.  This should just be
   MALLOC_ABI_ALIGNMENT, but that macro defaults to only BITS_PER_WORD for some
   reason, so don't let the threshold be smaller than max_align_t_align.  */

unsigned
malloc_alignment ()
{
  return MAX (max_align_t_align(), MALLOC_ABI_ALIGNMENT);
}

Shouldn't we trust the target if it has overridden the default? e.g.

/* Return the alignment we expect malloc to guarantee.  This should just be
   MALLOC_ABI_ALIGNMENT, but that macro defaults to only BITS_PER_WORD for some
   reason.  If MALLOC_ABI_ALIGNMENT has been changed from the default, use it.
   Otherwise don't let the threshold be smaller than max_align_t_align.  */

unsigned
malloc_alignment ()
{
  if (MALLOC_ABI_ALIGNMENT != BITS_PER_WORD)
return MALLOC_ABI_ALIGNMENT;
  return MAX (max_align_t_align(), MALLOC_ABI_ALIGNMENT);
}

[Bug c++/86288] Recognize __gnu and/or __gnu__ as attribute-namespace

2019-05-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86288

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for 8.3 and 9.1

[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs

2019-05-21 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691

--- Comment #33 from Jonathan Wakely  ---
I've been working on this again, and I think that the resource_adaptor type is
the wrong place to fix the malloc alignment problem.

The correct fix is to adjust the value of __STDCPP_DEFAULT_NEW_ALIGNMENT__ on
targets where malloc doesn't agree with GCC's alignof(max_align_t). Otherwise
even if I make resource_adaptor work for those targets, this test will still
fail:

#include 
#include 
#include 
#include 

template
  inline bool aligned(void* p)
  { return (reinterpret_cast(p) % alignof(T)) == 0; }

int
main()
{
  using test_type = std::max_align_t; // largest fundamental alignment
  std::allocator a;
  for (int i = 0; i < 10; ++i)
  {
test_type* p1 = a.allocate(1);
VERIFY( aligned(p1) );
test_type* p2 = a.allocate(20);
VERIFY( aligned(p2) );
a.deallocate(p1, 1);
a.deallocate(p2, 20);
  }
}

If we make std::allocator work then the tests for resource_adaptor
will also work, at least on Solaris.

[Bug libstdc++/90557] Incorrect std::filesystem::path::operator=(std::filesystem::path const&) in gcc 9.1.0

2019-05-21 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90557

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-21
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Arnaud Desitter from comment #0)
> However, the defect comes from
> fs_path.cc:281
> 
> std::uninitialized_copy_n(to + oldsize, newsize - oldsize,
>   from + oldsize);
> should be:
> std::uninitialized_copy_n(from + oldsize, newsize - oldsize,
>   to + oldsize);

Yikes, thanks.

[Bug libstdc++/90252] PSTL test failures

2019-05-21 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90252

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue May 21 13:50:41 2019
New Revision: 271466

URL: https://gcc.gnu.org/viewcvs?rev=271466=gcc=rev
Log:
PR libstdc++/90252 fix effective-target check for TBB

PR libstdc++/90252
* testsuite/lib/libstdc++.exp (check_effective_target_tbb-backend):
Use "additional_flags" to pass -ltbb to v3_target_compile command.
Use check_v3_target_prop_cached to cache the result of the test.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/lib/libstdc++.exp

[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691

--- Comment #32 from Jonathan Wakely  ---
*** Bug 89732 has been marked as a duplicate of this bug. ***

[Bug libstdc++/89732] FAIL: experimental/memory_resource/new_delete_resource.cc execution test

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89732

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
I'm closing this, since the patch that caused it isn't actually committed.

*** This bug has been marked as a duplicate of bug 77691 ***

[Bug libstdc++/90542] Build with --enable-libstdcxx-debug fails on Solaris due to symbol conflicts

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90542

--- Comment #2 from Jonathan Wakely  ---
It looks like the std::e[a-q]* pattern can simply be removed.

[Bug libstdc++/90542] Build with --enable-libstdcxx-debug fails on Solaris due to symbol conflicts

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90542

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-20
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I haven't confirmed it, but I suspect this is a regression, because these
symbols are new in 9.1.0

[Bug libstdc++/90542] New: Build with --enable-libstdcxx-debug fails on Solaris due to symbol conflicts

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90542

Bug ID: 90542
   Summary: Build with --enable-libstdcxx-debug fails on Solaris
due to symbol conflicts
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: ro at gcc dot gnu.org
  Target Milestone: ---

/bin/sh ../../libtool --tag CXX   --mode=link
/export/home/jwakely/build/./gcc/xgcc -shared-libgcc
-B/export/home/jwakely/build/./gcc -nostdinc++
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src/.libs
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs
-B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/bin/
-B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/lib/ -isystem
/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/include -isystem
/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/sys-include  
-fno-checking-std=gnu++98 -fPIC -DPIC -fno-implicit-templates  -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi=2  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=libstdc++.la  -o
libstdc++.la -version-info 6:26:0 -Wl,-M,libstdc++-symbols.ver-sun -lm -rpath
/export/home/jwakely/gcc/9.1.0/lib/debug compatibility.lo
compatibility-debug_list.lo compatibility-debug_list-2.lo 
compatibility-c++0x.lo compatibility-atomic-c++0x.lo
compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo
-lrt ../../libsupc++/libsupc++convenience.la
../../src/debug/c++98/libc++98convenience.la
../../src/debug/c++11/libc++11convenience.la
../../src/debug/c++17/libc++17convenience.la 
libtool: link:  /export/home/jwakely/build/./gcc/xgcc -shared-libgcc
-B/export/home/jwakely/build/./gcc -nostdinc++
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src/.libs
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs
-B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/bin/
-B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/lib/ -isystem
/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/include -isystem
/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/sys-include  
-fno-checking -shared -nostdlib  /usr/lib/crti.o
/export/home/jwakely/build/./gcc/crtbegin.o  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o
.libs/compatibility-condvar.o  -Wl,-z -Wl,allextract
../../libsupc++/.libs/libsupc++convenience.a
../../src/debug/c++98/.libs/libc++98convenience.a
../../src/debug/c++11/.libs/libc++11convenience.a
../../src/debug/c++17/.libs/libc++17convenience.a -Wl,-z -Wl,defaultextract 
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -lm
-lrt -L/export/home/jwakely/build/./gcc -lgcc_s -lc -lgcc_s -lc
/export/home/jwakely/build/./gcc/crtend.o /usr/lib/crtn.o  -Wl,-M
-Wl,libstdc++-symbols.ver-sun   -Wl,-h -Wl,libstdc++.so.6 -o
.libs/libstdc++.so.6.0.26
ld: fatal: libstdc++-symbols.ver-sun: 5381: symbol
'std::enable_if > const&, std::basic_string_view > >,
std::__not_ > const*, std::__cxx11::basic_string, std::allocator > const*> >,
std::__not_ > const&, char const*> > >::value,
std::__cxx11::basic_string, std::allocator
>&>::type std::__cxx11::basic_string,
std::allocator >::append > >(std::basic_string_view
> const&)': symbol version conflict
ld: fatal: libstdc++-symbols.ver-sun: 5382: symbol
'std::enable_if > const&, std::basic_string_view > >,
std::__not_ > const*, std::__cxx11::basic_string, std::allocator > const*> >,
std::__not_ > const&, char const*> > >::value,
std::__cxx11::basic_string, std::allocator
>&>::type std::__cxx11::basic_string,
std::allocator >::append > >(std::basic_string_view
> const&)': symbol version conflict
ld: fatal: libstdc++-symbols.ver-sun: 5399: symbol
'std::enable_if > const&, std::basic_string_view > >,
std::__not_ > const*, std::__cxx11::basic_string, std::allocator > const*> >,
std::__not_ > const&, char const*> > >::value,
std::__cxx11::basic_string, std::allocator
>&>::type std::__cxx11::basic_string,
std::allocator >::assign > >(std::basic_string_view
> const&)': symbol version conflict
ld: fatal: libstdc++-symbols.ver-sun: 5400: symbol
'std::ena

[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
And on the branches too, for 8.4 and 9.2.

[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Mon May 20 13:04:39 2019
New Revision: 271418

URL: https://gcc.gnu.org/viewcvs?rev=271418=gcc=rev
Log:
PR c++/90532 Ensure __is_constructible(T[]) is false

An array of an unknown bound is an incomplete type, so no object of such
a type can be constructed. This means __is_constructible should always
be false for an array of unknown bound.

This patch also changes the std::is_default_constructible trait to use
std::is_constructible, which now gives the right answer for arrays of
unknown bound.

gcc/cp:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* method.c (is_xible_helper): Return error_mark_node for construction
of an array of unknown bound.

gcc/testsuite:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* g++.dg/ext/90532.C: New test.

libstdc++-v3:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* include/std/type_traits (__do_is_default_constructible_impl)
(__is_default_constructible_atom, __is_default_constructible_safe):
Remove.
(is_default_constructible): Use is_constructible.
* testsuite/20_util/is_constructible/value.cc: Check int[] case.
* testsuite/20_util/is_default_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_default_constructible/value.cc:
Likewise.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/ext/90532.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/method.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/std/type_traits
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_constructible/value.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_default_constructible/value.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_trivially_default_constructible/value.cc

[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Mon May 20 13:02:10 2019
New Revision: 271417

URL: https://gcc.gnu.org/viewcvs?rev=271417=gcc=rev
Log:
PR c++/90532 Ensure __is_constructible(T[]) is false

An array of an unknown bound is an incomplete type, so no object of such
a type can be constructed. This means __is_constructible should always
be false for an array of unknown bound.

This patch also changes the std::is_default_constructible trait to use
std::is_constructible, which now gives the right answer for arrays of
unknown bound.

gcc/cp:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* method.c (is_xible_helper): Return error_mark_node for construction
of an array of unknown bound.

gcc/testsuite:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* g++.dg/ext/90532.C: New test.

libstdc++-v3:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* include/std/type_traits (__do_is_default_constructible_impl)
(__is_default_constructible_atom, __is_default_constructible_safe):
Remove.
(is_default_constructible): Use is_constructible.
* testsuite/20_util/is_constructible/value.cc: Check int[] case.
* testsuite/20_util/is_default_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_default_constructible/value.cc:
Likewise.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/ext/90532.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/method.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/std/type_traits
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_constructible/value.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_default_constructible/value.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_trivially_default_constructible/value.cc

[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #12 from Jonathan Wakely  ---
Yes.

[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532

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

[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Mon May 20 11:32:51 2019
New Revision: 271412

URL: https://gcc.gnu.org/viewcvs?rev=271412=gcc=rev
Log:
PR c++/90532 Ensure __is_constructible(T[]) is false

An array of an unknown bound is an incomplete type, so no object of such
a type can be constructed. This means __is_constructible should always
be false for an array of unknown bound.

This patch also changes the std::is_default_constructible trait to use
std::is_constructible, which now gives the right answer for arrays of
unknown bound.

gcc/cp:

PR c++/90532 Ensure __is_constructible(T[]) is false
* method.c (is_xible_helper): Return error_mark_node for construction
of an array of unknown bound.

gcc/testsuite:

PR c++/90532 Ensure __is_constructible(T[]) is false
* g++.dg/ext/90532.C: New test.

libstdc++-v3:

PR c++/90532 Ensure __is_constructible(T[]) is false
* include/std/type_traits (__do_is_default_constructible_impl)
(__is_default_constructible_atom, __is_default_constructible_safe):
Remove.
(is_default_constructible): Use is_constructible.
* testsuite/20_util/is_constructible/value.cc: Check int[] case.
* testsuite/20_util/is_default_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_default_constructible/value.cc:
Likewise.

Added:
trunk/gcc/testsuite/g++.dg/ext/90532.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/is_constructible/value.cc
trunk/libstdc++-v3/testsuite/20_util/is_default_constructible/value.cc
trunk/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_default_constructible/value.cc

[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Jonathan Wakely  ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01226.html

[Bug c++/90540] New: Improve diagnostic for forming array of abstract class type

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90540

Bug ID: 90540
   Summary: Improve diagnostic for forming array of abstract class
type
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct ABC {
  virtual void f() = 0;
};
template struct X { };
X x;

Gives the error:

abc.cc:5:6: error: array of abstract class type 'ABC'
X x;
 ^
abc.cc:2:16: note: unimplemented pure virtual method 'f' in 'ABC'
  virtual void f() = 0;
   ^
1 error generated.

This isn't very helpful, because there's no attempt to allocate any object of
type ABC. It would be better to say something like arrays of abstract class
types are not valid types (although I don't see where the standard says you
can't even refer to them in this context).

Clang says:

abc.cc:5:6: error: array of abstract class type 'ABC'
X x;
 ^
abc.cc:2:16: note: unimplemented pure virtual method 'f' in 'ABC'
  virtual void f() = 0;
   ^
1 error generated.

Which is slightly better, but it doesn't actually say what's *wrong* with an
array of abstract class type.

EDG wins here:

"abc.cc", line 5: error: array of abstract class "ABC" is not allowed:
function "ABC::f" is a pure virtual function
  X x;
   ^

1 error detected in the compilation of "abc.cc".

[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||7.4.0
   Target Milestone|--- |8.4
Summary|is_constructible_v   |[8/9/10 Regression]
   |and |is_constructible_v
   |is_default_constructible_v< |and
   |int[]> should agree |is_default_constructible_v<
   ||int[]> should agree
  Known to fail||10.0, 8.1.0, 8.3.0, 9.1.0

--- Comment #3 from Jonathan Wakely  ---
This is a regression due to the addition of the __is_constructible built-in.
Before we had that, this correct test passed:

#include 

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

static_assert( !std:: is_trivially_constructible::value, "");
static_assert( !std::is_trivially_default_constructible::value, "");

Now three out of four assertions fail, because they use the built-in.

I'm testing this fix:

--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1201,6 +1201,8 @@ is_xible_helper (enum tree_code code, tree to, tree from,
bool trivial)
 expr = assignable_expr (to, from);
   else if (trivial && from && TREE_CHAIN (from))
 return error_mark_node; // only 0- and 1-argument ctors can be trivial
+  else if (TREE_CODE(to) == ARRAY_TYPE && !TYPE_DOMAIN (to))
+return error_mark_node; // can't construct an array of unknown bound
   else
 expr = constructible_expr (to, from);
   return expr;

[Bug c++/90532] is_constructible_v and is_default_constructible_v should agree

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
I am testing a patch to fix __is_constructible.

[Bug c++/90532] is_constructible_v and is_default_constructible_v should agree

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-20
 CC||ville at gcc dot gnu.org
  Component|libstdc++   |c++
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This is also a compiler bug. The only one of the four traits to give the right
answer is the one implemented purely in the library. The other three use the
__is_constructible or __is_trivially_constructible built-ins, which are wrong
for this case.

std::is_default_constructible should probably be using the built-in too, even
though that would make it wrong (but consistently so, and it would be right
after the built-in gets fixed).

[Bug c/57201] --save-temps shows correct warning about macro in system-header (Wsystem-header)

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201

--- Comment #15 from Jonathan Wakely  ---
PR 60100 seems to be the opposite case, where a warning disappears when
-save-temps is used. Related, but maybe not a dup.

Anyway, here's another example where -save-temps (or preprocessing and
compiling separately) makes a warning disappear, from
https://gcc.gnu.org/ml/gcc-help/2019-05/msg00073.html


#include 
int main()
{
return NULL;
}

g++ -Wconversion-null w.cc
w.cc: In function ‘int main()’:
w.cc:4:8: warning: converting to non-pointer type ‘int’ from NULL
[-Wconversion-null]
 return NULL;
^~~~

g++ -Wconversion-null w.cc -save-temps
[no warnings]

g++ -Wconversion-null w.cc -save-temps -Wsystem-headers
w.cc: In function ‘int main()’:
w.cc:4:7: warning: converting to non-pointer type ‘int’ from NULL
[-Wconversion-null]
 return NULL;
   ^~

g++ -E w.cc -o w.ii && g++ -Wconversion-null w.ii
[no warnings]

g++ -E w.cc -o w.ii && g++ -Wconversion-null w.ii -Wsystem-headers
w.cc: In function ‘int main()’:
w.cc:4:7: warning: converting to non-pointer type ‘int’ from NULL
[-Wconversion-null]
 return NULL;
   ^~


So by default we warn, but when using -save-temps (or preprocessing and
compiling separately) the warning is suppressed because GCC thinks it's from a
system header.

Our diagnostics related to macros in system headers are so broken.

[Bug c++/77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null

2019-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77513

--- Comment #9 from Jonathan Wakely  ---
(In reply to Ville Voutilainen from comment #7)
> "The macro NULL is an implementation-defined null pointer constant.", says
> the C++ standard draft.

So it does, maybe I was misremembering something from an older C++0x draft.

Either way, 0 is still a valid definition of NULL, and I suspect that defining
NULL as nullptr would break a lot of code (albeit bad code that is misusing
NULL).

[Bug c++/85679] [DR2094] __is_trivially_copyable returns false with volatile scalar type

2019-05-19 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85679

Jonathan Wakely  changed:

   What|Removed |Added

 CC||alisdairm at me dot com

--- Comment #2 from Jonathan Wakely  ---
*** Bug 90531 has been marked as a duplicate of this bug. ***

[Bug c++/90531] is_trivailly_copyable_v should be 'true'

2019-05-19 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90531

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
.

*** This bug has been marked as a duplicate of bug 85679 ***

[Bug c++/90531] is_trivailly_copyable_v should be 'true'

2019-05-19 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90531

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-19
  Component|libstdc++   |c++
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yes this is a compiler issue. We might already have a bug about it. I haven't
bothered pushing for the intrinsic to change, because the standard will
probably change the rule again as soon as we catch up. A take of woe indeed.

[Bug testsuite/90520] [10 regression] libstdc++-xmethods/unique_ptr.cc triggers python failure starting with r271158

2019-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90520

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed. I do most of my testing on gcc112 in the compile farm, but it doesn't
run the xmethod.exp tests so I didn't notice this.

I should install a newer gdb with xmethod support on that machine.

[Bug testsuite/90520] [10 regression] libstdc++-xmethods/unique_ptr.cc triggers python failure starting with r271158

2019-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90520

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Fri May 17 23:08:00 2019
New Revision: 271363

URL: https://gcc.gnu.org/viewcvs?rev=271363=gcc=rev
Log:
PR libstdc++/90520 adjust Xmethod for recent unique_ptr changes

PR libstdc++/90520
* python/libstdcxx/v6/printers.py (UniquePointerPrinter.__init__):
Raise exception if unique_ptr tuple member has unknown structure.
* python/libstdcxx/v6/xmethods.py (UniquePtrGetWorker.__call__):
Adjust worker to support new __uniq_ptr_data base class. Do not
assume field called _M_head_impl is the first tuple element.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
trunk/libstdc++-v3/python/libstdcxx/v6/xmethods.py

[Bug c++/90521] error: names the constructor, not the type

2019-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90521

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
The code is just wrong and should be fixed by removing "::basic_string".

I don't see that wrong code in the upstream gdal code, so it looks like
somebody introduced it to your copy of gdal.

[Bug testsuite/90520] [10 regression] libstdc++-xmethods/unique_ptr.cc triggers python failure starting with r271158

2019-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90520

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-17
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug libstdc++/90246] std::bad_variant_access messages are not useful

2019-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90246

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.2 |10.0

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk.

[Bug libstdc++/90246] std::bad_variant_access messages are not useful

2019-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90246

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri May 17 14:36:37 2019
New Revision: 271326

URL: https://gcc.gnu.org/viewcvs?rev=271326=gcc=rev
Log:
PR libstdc++/90246 Improve text of std::variant exceptions and assertions

PR libstdc++/90246
* include/std/variant (holds_alternative, get, get_if): Improve
static assertion messages.
(bad_variant_access::bad_variant_access()): Change default message.
(__throw_bad_variant_access(bool)): New overload.
(get): Use new overload.
(visit, visit): Improve exception message.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug libstdc++/85965] [8/9/10 Regression] G++ gives cryptic error instead of incomplete type

2019-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

--- Comment #16 from Jonathan Wakely  ---
Author: redi
Date: Fri May 17 14:13:32 2019
New Revision: 271323

URL: https://gcc.gnu.org/viewcvs?rev=271323=gcc=rev
Log:
PR libstdc++/85965 move is_invocable assertions again

This is another attempt to reduce how often the assertions are
evaluated, so that code which doesn't try to use the function objects
doesn't need them to be invocable.

For _Rb_tree we access the _M_key_compare object directly, so can't put
the assertions in an accessor function for it. However, every invocation
of _M_key_compare is accompanied by a use of _S_key, so the assertions
can be put in there.  For _Hashtable there are member functions that are
consistently used to obtain a hash code or test for equality, so the
assertions can go in those members.

PR libstdc++/85965
* include/bits/hashtable.h (_Hashtable::~_Hashtable()): Remove static
assertions from the destructor.
* include/bits/hashtable_policy.h (_Hash_code_base::_M_hash_code):
Move static_assert for hash function to here.
(_Hash_table_base::_M_equals): Move static_assert for equality
predicate to here.
* include/bits/stl_tree.h (_Rb_tree::_S_value(_Const_Link_type)):
Remove.
(_Rb_tree::_S_key(_Const_Link_type)): Move assertions here. Access
the value directly instead of calling _S_value.
(_Rb_tree::_S_value(_Const_Base_ptr)): Remove.
(_Rb_tree::_S_key(_Const_Base_ptr)): Do downcast and forward to
_S_key(_Const_Link_type).
* testsuite/23_containers/set/85965.cc: Check construction,
destruction, assignment and size() do not trigger the assertions.
* testsuite/23_containers/unordered_set/85965.cc: Likewise.
* testsuite/23_containers/map/48101_neg.cc: Call find and adjust
expected errors.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/set/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_map/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_set/48101_neg.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h
trunk/libstdc++-v3/include/bits/hashtable_policy.h
trunk/libstdc++-v3/include/bits/stl_tree.h
trunk/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/multiset/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/set/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/set/85965.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/48101_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/85965.cc

[Bug c++/90516] Strange behaviour of code if function no return value and code embraced by try..catch with opt flags

2019-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90516

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to matszpk from comment #0)
> I encountered that bug when I trying to test some program that have bug: a
> missing return in loading file function that code was embraced by
> try...catch. Due to this bug and enabled optimization's flags program aborts
> due to double free of the memory and it was strange behaviour of this
> function.

Because the program has a bug and its behaviour is undefined.

> Later, I wrote sample program that load some string from file and doing
> nothing this same bug (missing return) with code embraced by try..catch. If
> program was compiled with optimizations flags (-O3) then and if file was
> exist and then program print out exception in by statement in catch clause
> (just run clause) with like: 'Exception at loading: basic_ios::clear:
> iostream error'.

The program has undefined behaviour.

The only return statement in the function is the one in the catch block, so it
looks like GCC is deciding to run that code unconditionally, because there's no
other valid way to return from the function.

You should pay attention to the warning and fix the code.

[Bug libstdc++/90299] std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently

2019-05-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90299

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Thu May 16 23:09:51 2019
New Revision: 271302

URL: https://gcc.gnu.org/viewcvs?rev=271302=gcc=rev
Log:
PR libstdc++/90299 make filesystem::absolute overloads consistent

In this implementation it is an error to pass the empty path to absolute,
because the empty path doesn't represent any file in the filesystem so
the function cannot meet its postcondition.

Currently the absolute(const path&, error_code&) overload reports an
error for the empty path, but using errc::no_such_file_or_directory, and
the other overload does not report an error. This patch makes them
consistntly report an errc::invalid_argument error for the empty path.

Backport from mainline
2019-05-04  Jonathan Wakely  

PR libstdc++/90299
* src/filesystem/std-ops.cc (absolute(const path&)): Report an error
if the argument is an empty path.
(absolute(const path&, error_code&)): Use invalid_argument as error
code instead of no_such_file_or_directory.
* testsuite/27_io/filesystem/operations/absolute.cc: Check handling
of non-existent paths and empty paths with both overloads of absolute.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/src/filesystem/std-ops.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/operations/absolute.cc

[Bug libstdc++/90299] std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently

2019-05-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90299

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for GCC 8.4 and 9.2

[Bug libstdc++/90299] std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently

2019-05-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90299

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Thu May 16 23:00:26 2019
New Revision: 271301

URL: https://gcc.gnu.org/viewcvs?rev=271301=gcc=rev
Log:
PR libstdc++/90299 make filesystem::absolute overloads consistent

In this implementation it is an error to pass the empty path to absolute,
because the empty path doesn't represent any file in the filesystem so
the function cannot meet its postcondition.

Currently the absolute(const path&, error_code&) overload reports an
error for the empty path, but using errc::no_such_file_or_directory, and
the other overload does not report an error. This patch makes them
consistntly report an errc::invalid_argument error for the empty path.

Backport from mainline
2019-05-04  Jonathan Wakely  

PR libstdc++/90299
* src/c++17/fs_ops.cc (absolute(const path&)): Report an error if the
argument is an empty path.
(absolute(const path&, error_code&)): Use invalid_argument as error
code instead of no_such_file_or_directory.
* testsuite/27_io/filesystem/operations/absolute.cc: Check handling
of non-existent paths and empty paths with both overloads of absolute.

Backport from mainline
2019-05-16  Jonathan Wakely  

* src/c++17/fs_ops.cc (absolute(const path&, error_code&))
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Remove bogus assertion.

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/src/c++17/fs_ops.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/operations/absolute.cc

[Bug libstdc++/90509] failing typing std::transform with policies on std::insert_iterator

2019-05-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90509

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Yes, and the overload that takes an exeution policy requires forward iterators
for the input range and the output range.

It doesn't matter if you use the sequential policy or not.

[Bug libstdc++/90509] failing typing std::transform with policies on std::insert_iterator

2019-05-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90509

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The parallel version of std::transform requires forward iterators, so this is
not a bug.

https://en.cppreference.com/w/cpp/algorithm/transform

[Bug libstdc++/90046] [9 Regression] fails to build a epiphany-elf cross toolchain with C++ enabled

2019-05-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90046

Jonathan Wakely  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #5 from Jonathan Wakely  ---
*** Bug 88789 has been marked as a duplicate of this bug. ***

  1   2   3   4   5   6   7   8   9   10   >