https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
--- Comment #11 from Viktor Ostashevskyi ---
(In reply to Jonathan Wakely from comment #10)
> This one's much harder to fix:
>
> #include
>
> template
> struct Alloc
> {
> using value_type = T;
>
> Alloc(int) { }
>
> template Alloc(co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
--- Comment #9 from Viktor Ostashevskyi ---
(In reply to Jonathan Wakely from comment #8)
> Calling swap unqualified performs ADL, which has to find all the associated
> namespaces and associated classes. To do that it has to complete all the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
--- Comment #7 from Viktor Ostashevskyi ---
I'm still wondering why for std::hash, the T type is checked for anything.
It shouldn't matter what T is, as we're hashing T*...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
--- Comment #3 from Viktor Ostashevskyi ---
Additional information: everything works fine both for GCC12 and Clang if swap
call is fully qualified, i.e.:
std::swap(h1, h2);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
--- Comment #1 from Viktor Ostashevskyi ---
Issue is visible with -std=c++20, works fine for -std=c++17 (for both GCC12 and
Clang).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
--- Comment #2 from Viktor Ostashevskyi ---
Compiler exporer link: https://godbolt.org/z/cPqsKq6nM
bstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
For the following code snippet:
---
#include
#include
class Storage;
template
class MyAllocator
{
public:
using value_type = T;
using pointer = T*;
MyAllocator(Stora
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662
--- Comment #2 from Viktor Ostashevskyi ---
Adding --param=ranger-recompute-depth=1 or --param=ranger-recompute-depth=2
also fixes the issue. Higher values behave wrongly.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Hello,
For the following snippet compiled with "-O3 -std=c++20"
---
#include
#include
#include
#include
struct Fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110075
--- Comment #6 from Viktor Ostashevskyi ---
(In reply to Marek Polacek from comment #5)
> Yes, because we'd have to analyze the body of the function to see that it
> does not return one of the parameters, which often we can't do.
>
> There will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110075
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93998
--- Comment #3 from Viktor Ostashevskyi ---
Bisected to:
ee1de08d4d22648cf3168caa60e283135755da85 is the first bad commit
commit ee1de08d4d22648cf3168caa60e283135755da85
Author: Jakub Jelinek
Date: Tue Dec 3 20:27:47 2019 +0100
re PR c++
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Hello,
Following code
#define LIKELY(x) __builtin_expect(!!(x), 1)
class Code
{
public:
constexpr bool operator==(Code rhs) const noexcept { return value_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #96 from Viktor Ostashevskyi ---
Honestly, I don't see how your compiler flags could help. cost-model=cheap
is default, data-alignment doesn't change incoming stack alignment.
ср, 15 січ. 2020, 14:31 користувач mahatma at eu dot by <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #94 from Viktor Ostashevskyi ---
(In reply to Florian Weimer from comment #93)
> (In reply to Viktor Ostashevskyi from comment #92)
> > I've tried to run some old binaries yesterday (StarOffice 5.1, get it from
> > archive.org) and hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Hello,
Following snippet
#include
auto f = [](auto value) {
constexpr auto i = value;
return i;
};
void foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88128
--- Comment #3 from Viktor Ostashevskyi ---
I see that std::span implementation was proposed in
https://gcc.gnu.org/ml/libstdc++/2019-08/msg00068.html.
Was this bug fixed for implenting it?
Is it possible to make std::span from std::vector?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067
--- Comment #17 from Viktor Ostashevskyi ---
Ok, got following today with GCC 9.2 with "-O2 -fno-inline -flto=20":
ld.bfd: /tmp/tests.oKru4z.ltrans32.ltrans.o: in function
`std::__shared_ptr::operator=(std::__shared_ptr&&)':
c++/9.2.0/bits/share
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067
--- Comment #15 from Viktor Ostashevskyi ---
(In reply to Jonathan Wakely from comment #14)
> I can reproduce the link failure. For some reason Clang requires that
> constructor at -O1, but not at any other optimization level.
It will require it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067
--- Comment #13 from Viktor Ostashevskyi ---
(In reply to Jonathan Wakely from comment #12)
> I didn't export that because nothing should need it. Nothing in libstdc++
> derives from __shared_ptr<_Dir> and nothing in user code is allowed to refer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067
--- Comment #11 from Viktor Ostashevskyi ---
I assume that problem comes from explicit instantiation:
extern template class __shared_ptr;
which was added in c8fb3443911413cc88f316305fc6b7bf4861ccaa.
It prevent Clang in emitting "C2" version of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361
--- Comment #11 from Viktor Ostashevskyi ---
Cool! Thanks a lot, sad that this doesn't make to 9.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361
--- Comment #6 from Viktor Ostashevskyi ---
(In reply to Viktor Ostashevskyi from comment #5)
> It would be nice at least document that for GCC 9.1.0 building with
> --with-default-libstdcxx-abi=gcc4-compatible is broken.
>
> Possible workaround
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361
--- Comment #5 from Viktor Ostashevskyi ---
It would be nice at least document that for GCC 9.1.0 building with
--with-default-libstdcxx-abi=gcc4-compatible is broken.
Possible workaround is to build with default parameters and change
_GLIBCXX_U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361
--- Comment #4 from Viktor Ostashevskyi ---
Bisected to:
commit c6e37a9f5734bfe731b042993f77cb41b5a566c5
Author: redi
Date: Sun Jan 6 22:34:29 2019 +
PR libstdc++/86756 add std::filesystem::path to libstdc++.so
Move the C++17 st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361
--- Comment #3 from Viktor Ostashevskyi ---
(In reply to Jonathan Wakely from comment #2)
> I haven't checked a build with that option for ages, so I can easily believe
> I've broken it. I'll take a look tomorrow.
It worked well in GCC 8.2.0 at
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Hello,
When build gcc-9.1.0 with --with-default-libstdc xx-abi=gcc4-compatible
resulting libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88128
--- Comment #2 from Viktor Ostashevskyi ---
Actually, even current C++17 unique_ptr::reset for array objects is defined in
terms of pointer to array convertibility ([unique.ptr.runtime.modifiers]).
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
GCC rejects following code:
int* (*xx)[];
const int* const(*yy)[];
yy = xx;
while Clang started accepting since 7.0 when they implemented CWG 330.
Without this it is very hard to implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87809
--- Comment #7 from Viktor Ostashevskyi ---
I confirm that fix works on real codebase with GCC9.
libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Hello,
Following code snippet:
#include
#include
class Storage;
template
class MyAlloc
{
public:
using value_type = T;
value_type* allocate(size_t n);
void de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83406
--- Comment #1 from Viktor Ostashevskyi ---
gcc version 8.0.0 20171213 (experimental) (GCC)
nt: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Following code:
-
class Foo{};
class Bar
{
public:
const Foo& getFoo() const;
Foo& getFoo();
};
auto getter = [](const Bar& bar) -> decltype(auto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82579
Viktor Ostashevskyi changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82579
Viktor Ostashevskyi changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Hello,
The following code fails to compile with GCC 7/8, in C++17 mode (call to f(s)
is ambiguous):
-
template
class C
{};
template
void f(const C&) {}
temp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70385
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
--- Comment #6 from Viktor Ostashevskyi ---
I'm not sure about bug prioritizing policies, but for me it looks like this
should get P1 or documentation/release notes for GCC5 and GCC6 should state
that -fno-ellide-constructor is broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
--- Comment #5 from Viktor Ostashevskyi ---
Bisected to:
commit 9c96033c877975303250d6f6156eacba52fc8b44
Author: jason
Date: Mon Nov 17 18:16:14 2014 +
C++14 constexpr support (minus loops and multiple returns)
gcc/
* tree-inline.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
--- Comment #16 from Viktor Ostashevskyi ---
(In reply to Jonathan Wakely from comment #15)
> That option is not the default, and is only really useful for experimenting
> to understand how C++ works (as documented at
> https://gcc.gnu.org/wiki/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
--- Comment #14 from Viktor Ostashevskyi ---
(In reply to Jakub Jelinek from comment #13)
> As for the priority, P2
> is right, we've already shipped GCC 5.[123] with this bug, so it can't be a
> release blocker, but is of course very much desir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
--- Comment #3 from Viktor Ostashevskyi ---
Could be the same problem as in PR70145.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
--- Comment #2 from Viktor Ostashevskyi ---
Exception occurs, because in:
regex_traits::lookup_classname(...):
{
...
static const pair __classnames[] =
{
{"d", ctype_base::digit},
{"w", {ctype_base::alnum, _RegexMask::_S_
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Following code:
#include
namespace
{
const std::regex HTTP_START_HEADER_RE("^HTTP\\/\\d.\\d\\s+(\\d+)\\s+([\\w\\t
]+)\\r\\n");
}
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Following minimal case:
#include
template
class FixedVector : protected std::array
{
public:
typedef typename std::array base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59465
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
51 matches
Mail list logo
