https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
--- Comment #2 from Jonathan Wakely ---
Oh, but you didn't enable any optimization at all, so who cares about the
performance?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
--- Comment #5 from Jonathan Wakely ---
I've removed some redundant code from them, but not changed the indirection
that this PR complains about. I don't plan to change that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
--- Comment #9 from Jonathan Wakely ---
The generated code hasn't changed between gcc-10 and gcc-11 though, so the
difference must be in the code used to run the benchmarks, not the code under
test.
See https://godbolt.org/z/bWeMen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98233
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
--- Comment #8 from Jonathan Wakely ---
(In reply to Oleg Zaikin from comment #6)
> When we switched from C++17-based g++ to C++20-based g++, the performance of
> the whole program decreased by about 7 %. It turned out that the main reason
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
--- Comment #9 from Jonathan Wakely ---
And calling ceilf(x) doesn't give you any certainty of single precision,
because if x is a double then it will still work, but you're now doing a
conversion from double to float.
If you already know x is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
--- Comment #8 from Jonathan Wakely ---
If you call std::ceil with a float, you get the ceil(float) overload. If you
don't call it with a float, you haven't got subtle precision anyway and calling
ceil didn't change that.
If you need ceilf you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
--- Comment #13 from Jonathan Wakely ---
(In reply to Kip Warner from comment #12)
> I didn't say STL. I said library designers which includes the standard C
> runtime.
Why a particular name is used by C is not relevant to C++. The function is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
--- Comment #11 from Jonathan Wakely ---
Nope, ceilf comes from C, which has no overloading.
C++ doesn't need separate names for ceil, ceilf and ceill, so you just have
std::ceil.
The fact std::ceilf exists at all is just for consistency with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
--- Comment #6 from Jonathan Wakely ---
As it says, you can just use std::ceil.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98436
--- Comment #6 from Jonathan Wakely ---
(In reply to Samuel Benjamin from comment #4)
> I got your point, But why is this working with 64bit and other gcc versions
> other than 7.4.0 - 32 bit ?
Undefined behaviour means anything can happen,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98370
--- Comment #6 from Jonathan Wakely ---
(In reply to Hans-Peter Nilsson from comment #4)
> JFTR, likely all "32-bit targets".
Not x86, that uses int for int32_t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98392
Bug ID: 98392
Summary: Parallel algorithms fail to enforce Mandates:
requirements
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Keywords: accepts-invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98108
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98298
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93151
--- Comment #7 from Jonathan Wakely ---
Fixed on trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46447
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300
--- Comment #10 from Jonathan Wakely ---
Be patient, people have to sleep sometimes.
And please stop CCing me on everything, this is nothing to do with me and I
can't do anything about it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98108
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #7 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98319
--- Comment #2 from Jonathan Wakely ---
Fixed on trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98108
--- Comment #9 from Jonathan Wakely ---
Right, this actually has nothing to do with threads.
The behaviour is exactly the same as if file1.cc contained this instead:
void threadfunc();
struct StaticThread {
StaticThread() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98421
Bug ID: 98421
Summary: std::span does not detect invalid range in Debug Mode
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98261
--- Comment #2 from Jonathan Wakely ---
The bug reporting guidelines tell you to try -fsanitize=undefined before
reporting a bug. That would have told you your code is wrong:
A
d.C:26:14: runtime error: member call on address 0x7ffe71274e18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #16 from Jonathan Wakely ---
includes so std::boyer_moore_searcher can use
std::vector, but it doesn't need it at all. Using std::unique_ptr would do
fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65118
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98374
Jonathan Wakely changed:
What|Removed |Added
CC|jwakely at redhat dot com |
--- Comment #4 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-11-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #10 from Jonathan Wakely ---
Reduced:
using size_t = decltype(sizeof(0));
template struct remove_reference { using type = T; };
template struct remove_reference { using type = T; };
template struct remove_reference { using type =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #8 from Jonathan Wakely ---
(In reply to Janez Zemva from comment #6)
> try -std=c++20 ?
Which is why the instructions at https://gcc.gnu.org/bugs clearly say you need
to provide the options used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #7 from Jonathan Wakely ---
N.B. your program has undefined behaviour. Specializing std::hash for standard
library types is forbidden. GCC shouldn't crash though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #7)
> N.B. your program has undefined behaviour. Specializing std::hash for
> standard library types is forbidden. GCC shouldn't crash though.
Oh, you didn't! I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759
--- Comment #12 from Jonathan Wakely ---
r11-4843 should have removed the small difference between the std and popcount
benchmarks.
I still see a small advantage to arithmetic for skylake i7-6700 CPU @ 3.40GHz
and i7-8650U CPU @ 1.90GHz though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #13 from Jonathan Wakely ---
I think it's just a dup of PR 82099.
Reduced further to only use C++14
template
struct hash
{
int operator()(T) const noexcept { return 0; }
};
template
int hash_combine(T v)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82099
Jonathan Wakely changed:
What|Removed |Added
CC||janezz55 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85468
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #15 from Jonathan Wakely ---
(In reply to Martin Liška from comment #12)
> Started to ICE with -std=c++17 since r6-3372-g378b307d0d7e789c.
That's the commit that added C++17 fold expressions, but the ICE doesn't depend
on fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97781
Bug ID: 97781
Summary: basic_stringbuf::swap is not exception safe
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194
Jonathan Wakely changed:
What|Removed |Added
CC||janezz55 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97778
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97778
--- Comment #3 from Jonathan Wakely ---
Looks like a dup of PR 64194, checking ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56842
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97785
Bug ID: 97785
Summary: const_cast shows diagnostic about Y*
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71219
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2016-05-26 00:00:00 |2020-11-10
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65943
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94057
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
--- Comment #8 from Jonathan Wakely ---
Probably changed by one of the patches for PR 94749 or PR 96161, although I
still see two reads for the first example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
--- Comment #10 from Jonathan Wakely ---
Untested patch:
--- a/libstdc++-v3/src/c++98/compatibility.cc
+++ b/libstdc++-v3/src/c++98/compatibility.cc
@@ -88,7 +88,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
--- Comment #3 from Jonathan Wakely ---
I tried to implement this by adding a macro definition to c_cpp_builtins in
gcc/c-family/c-cppbuiltin.c but failed. I think we want to inspect the
'thread_model' global variable and see if it is "single",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
--- Comment #15 from Jonathan Wakely ---
Hmm, I get the same error for a out-of-tree binutils built from today's git
sources:
GNU assembler (GNU Binutils) 2.35.50.20201112
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97814
--- Comment #3 from Jonathan Wakely ---
N.B. that's not a copy constructor, it's a move constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
--- Comment #4 from Jonathan Wakely ---
Library patch:
diff --git a/libgcc/gthr.h b/libgcc/gthr.h
index f31cf083cbe5..e6462679b362 100644
--- a/libgcc/gthr.h
+++ b/libgcc/gthr.h
@@ -147,6 +147,13 @@ see the files COPYING3 and COPYING.RUNTIME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97814
--- Comment #2 from Jonathan Wakely ---
There is no copy in C++17, it is elided, so lock(S(1)) is equivalent to lock(1)
in C++17, and that constructor exists.
GCC is correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
--- Comment #17 from Jonathan Wakely ---
Nice, with binutils HEAD my gcc-10 build continues. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #15 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #14)
> > --- a/libgcc/gthr-posix.h
> > +++ b/libgcc/gthr-posix.h
> > @@ -684,7 +684,12 @@ __gthread_equal (__gthread_t __t1, __gthread_t __t2)
> > static inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #5 from Jonathan Wakely ---
But on third thoughts, I don't know how to implement this reliably.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|redi at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #8 from Jonathan Wakely ---
I suppose I could change the static_assert message to also suggest defining
your own specialization of std::pointer_traits, which is another way to make it
work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
--- Comment #6 from Jonathan Wakely ---
I think the reduction is not a fair representation of the original code.
Obviously shifting by -1 is not OK, but the code doesn't do that ... at least
not for most targets.
The problem is specific to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
--- Comment #8 from Jonathan Wakely ---
My attempt to build msp430 fails with:
In file included from
/home/jwakely/gcc/msp430-elf/msp430-elf/include/stdint.h:13,
from /home/jwakely/src/gcc/build-16bit/gcc/include/stdint.h:9,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
Jonathan Wakely changed:
What|Removed |Added
Assignee|mpolacek at gcc dot gnu.org|redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96322
--- Comment #2 from Jonathan Wakely ---
We really need to create our own custom locales for testing, so that we don't
depend on externally defined data that keep changing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
Jonathan Wakely changed:
What|Removed |Added
See Also||https://bugs.llvm.org/show_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97815
Bug ID: 97815
Summary: QNX should use thread_file=posix instead of defining
THREAD_MODEL_SPEC
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93456
--- Comment #4 from Jonathan Wakely ---
Fixed on trunk by the patch above and a few other recent commits today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421
--- Comment #9 from Jonathan Wakely ---
(In reply to Rich Felker from comment #7)
> Indeed, the direct clock_gettime syscall stuff is just unnecessary on any
> modern system, certainly any time64 one. I read the patch briefly and I
> don't see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97844
--- Comment #3 from Jonathan Wakely ---
(In reply to Roman Lebedev from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > unsigned integer overflow DOES NOT EXIST. It is called wrapping only.
>
> > This is NOT undefined at all.
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486
--- Comment #14 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #13)
> Those are doing exactly what the Networking TS requires.
For that matter, so was our implementation of condition_variable::wait_for that
was changed for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828
--- Comment #4 from Jonathan Wakely ---
(In reply to Alexey Mission from comment #3)
> Please see also cppreference.com where this bug is also spotted:
> https://en.cppreference.com/w/Talk:cpp/algorithm/ranges/search_n
Reporting bugs in a talk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828
--- Comment #5 from Jonathan Wakely ---
Also, don't paste copyrighted code into talk pages on cppreference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94568
Jonathan Wakely changed:
What|Removed |Added
Keywords||ABI
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569
Jonathan Wakely changed:
What|Removed |Added
Blocks||77691
--- Comment #10 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93071
--- Comment #2 from Jonathan Wakely ---
These might benefit from the same improvements (compile with -std=c++20):
#include
int i(int x) {
return 31 - std::countl_zero((unsigned)x);
}
int j(int x) {
return std::bit_width((unsigned)x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91488
--- Comment #3 from Jonathan Wakely ---
(In reply to ensadc from comment #1)
> It seems that the inliner does not like the `static` specifier in
> `__constant_string_p`. This also triggers "inlining failed in call to
> always_inline" error:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93071
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92978
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94345
--- Comment #2 from Jonathan Wakely ---
Fixed for GCC 11 by b1850c617b14eedaf60b358f3b7d4707cff73b8a
I might still backport it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> Created attachment 49449 [details]
> preprocessed source, unreduced, gzipped
>
> Here's another example that produces this kind of warning, this time from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97912
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> It would be good to remove the trivially copyable requirement, and store any
> type of suitable size and alignment to fit in the buffer.
Well, we'd still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876
--- Comment #7 from Jonathan Wakely ---
g:f5d9bc8ae81abe46640477bc9e655aa093947f5f removed the dependency from
on for most targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97912
Bug ID: 97912
Summary: Get rid of location-invariant requirement in
std::function small object optimisation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97922
--- Comment #1 from Jonathan Wakely ---
Reduced:
namespace test {
inline namespace internal {
struct Type1 { };
}
}
namespace test {
struct Type1; //Type1 is actually in an inline namespace
}
template struct P { };
using Type = P;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97922
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-11-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #15 from Jonathan Wakely ---
and got unavoidably bigger in C++20 due to the extra algos
in std::ranges.
includes so is larger. We can almost certainly replace
with and for 's
purposes, it doesn't use the ranges algos.
got a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97930
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97930
--- Comment #1 from Jonathan Wakely ---
Ugh, we need that base class to make assignment operators work correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97890
--- Comment #5 from Jonathan Wakely ---
The commit log refers to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0929r2.html which was
accepted as a defect report (i.e. a fix for previous standards) in Rapperswil
2018.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97885
--- Comment #2 from Jonathan Wakely ---
The code from the godbolt link is:
#include
template
concept weak_same = std::same_as, U>;
enum struct A {
x
};
auto f(weak_same auto) {}
auto f(auto&&) {}
auto main()->int {
f(A::x);
}
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
--- Comment #9 from Jonathan Wakely ---
(In reply to s.bauroth from comment #7)
> > The type of an integer constant is the first of the corresponding list
> > in which its value can be represented.
> These kind of sentences make me think gcc's
301 - 400 of 6648 matches
Mail list logo
