https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311
--- Comment #2 from Jonathan Wakely ---
Or something like:
auto __b = [__begin, __n](size_t __i) -> _Type& {
return __begin[__i % __n];
};
auto __b32 = [__b](size_t __i) { return (uint32_t)__b(__i); };
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-10-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332
Jonathan Wakely changed:
What|Removed |Added
Target||i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70358
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86402
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-10-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584
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=82584
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311
--- Comment #5 from Jonathan Wakely ---
I don't see how manually written arithmetic with explicit % operations is going
to beat using built-in types that do that automatically.
If 64-bit arithmetic is faster than 32-bit arithmetic, I would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311
--- Comment #4 from Jonathan Wakely ---
(In reply to Kristian Spangsege from comment #3)
> bonus, the code will work on platforms that do not have std::uint32_t.
GCC doesn't work on such platforms, and other parts of libstdc++ already assume
it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97369
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97406
Bug ID: 97406
Summary: Truncated pointer-to-member type in concept
satisfaction error
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97407
Bug ID: 97407
Summary: Expanding alias template in concept satisfaction error
is undesirable
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97407
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95310
--- Comment #2 from Jonathan Wakely ---
Fixed on trunk by r11-3372-d6587211c02c4e2566c4e545c09757f3fbb7adab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97407
--- Comment #1 from Jonathan Wakely ---
Reduced:
template T&& declval;
template decltype(declval().begin()) begin_impl(R&);
template
using iter_type_impl = decltype(begin_impl(declval()));
template
struct unrelated
{
using erm =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97435
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97443
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86252
Jonathan Wakely changed:
What|Removed |Added
CC||tangyixuan at mail dot
dlut.edu.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17232
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |NEW
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70248
--- Comment #8 from Jonathan Wakely ---
In gcc/cp/typeck.c:cp_build_binary_op this warning should be an error during
constant evaluation for EQ_EXPR and NE_EXPR:
if (complain & tf_warning)
{
tree stripped_orig_op0 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56951
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70248
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-10-15
Severity|minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85474
--- Comment #2 from Jonathan Wakely ---
Is this a dup of PR 70248?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97415
--- Comment #4 from Jonathan Wakely ---
Fixed on trunk so far. I'm undecided whether it needs to be backported.
Although the comparison with null is formally unspecified, I think all the
compilers we support behave as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97415
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-10-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97446
--- Comment #2 from Jonathan Wakely ---
Just like PR 97401.
Please try to remember that diagnostics are not required for errors in
uninstantiated templates, so it's not a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18469
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90295
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90295
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=92356
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90295
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198
--- Comment #4 from Jonathan Wakely ---
This is now https://wg21.link/lwg3486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93542
--- Comment #4 from Jonathan Wakely ---
Thanks, Mike. I've added the PR number to the ChangeLog file in
g:b98d3cc5666f36bf3cbeed7cd6a23483cc5e4eca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97383
Bug ID: 97383
Summary: Consider special asing diagnostics for customization
point objects
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97383
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97401
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97465
--- Comment #2 from Jonathan Wakely ---
e.g. what kind of cross build? We're not psychic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97465
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97485
--- Comment #3 from Jonathan Wakely ---
Looks like a dup of PR 55394
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
--- Comment #11 from Jonathan Wakely ---
It's not plausible because it doesn't work for non-pthreads targets where
gthr-default.h is not gthr-posix.h
We can't use pthread_once anyway, see PR 66146, so I'm rewriting it entirely in
terms of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-10-20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
--- Comment #7 from Jonathan Wakely ---
(In reply to andysem from comment #4)
> I just think that all these hoops could be avoided if libstdc++ was a little
> more friendly in this regard. After all, there's no harm in using e.g.
> auto_ptr in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #8 from Jonathan Wakely ---
And please ping patches like
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552844.html if you don't
get a review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
--- Comment #4 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #0)
> Case:
>
> #include
> #include
N.B. this has nothing to do with . The __deref entity is in
which gets included by and all the containers
(and a few other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
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=97362
--- Comment #3 from Jonathan Wakely ---
And add __deref to the list of BADNAMES in
doc/xml/manual/appendix_contributing.xml and the
testsuite/17_intro/headers/names.cc test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
Jonathan Wakely changed:
What|Removed |Added
Summary|`__deref` in|[8/9/10/11 Regression]
|in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97369
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97369
--- Comment #2 from Jonathan Wakely ---
If that's a linker error not a run time error, then it looks like you're not
using the right GCC to link. It could be that you're compiling with GCC 6.3.0
but then using a different GCC to link, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311
--- Comment #7 from Jonathan Wakely ---
Oops, yes I can, I messed up my test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311
--- Comment #6 from Jonathan Wakely ---
I can't get the algorithm to ever produce an intermediate result that doesn't
fit in 32 bits, so I'm not sure there's actually a problem here in practice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
--- Comment #3 from Jonathan Wakely ---
The /lib/cpp error is a bit misleading, because that's the last thing it tries
to find as a C++ compiler, after exhausting g++ -std=c++11 and various other
options that fail with:
configure:19863: g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
--- Comment #5 from Jonathan Wakely ---
ld: error: unable to find library -lc
Huh, not sure what causes that one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97415
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97420
--- Comment #1 from Jonathan Wakely ---
std::find_if has existed since C++98.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97420
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97415
--- Comment #2 from Jonathan Wakely ---
Oh, it does if I spell the environment variable correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97415
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
--- Comment #7 from Jonathan Wakely ---
Despite the code being correct, I think it would be better to hoist this branch
out of the loop:
if (__k == 0)
__r2 += __s;
else if (__k <= __s)
__r2 += __kn +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97132
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97237
--- Comment #3 from Jonathan Wakely ---
(In reply to Toni Neubert from comment #0)
> The following valid code:
N.B. that's not valid at all. That's why you need to use -fpermissive to
compile it.
> But this code is valid in all versions:
No,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97237
Jonathan Wakely changed:
What|Removed |Added
Known to fail||10.2.0, 11.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97217
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421
--- Comment #6 from Jonathan Wakely ---
On second thoughts, we probably don't need to worry about
SYS_clock_gettime_time64. We only use SYS_clock_gettime syscalls on old glibc
systems where clock_gettime is in librt not libc, and those systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952
--- Comment #7 from Jonathan Wakely ---
(In reply to Eric Botcazou from comment #4)
> What about detecting the support at configure time and defining a macro
> during the compilation? Everyone has been doing this for more that 3
> decades...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97195
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952
--- Comment #9 from Jonathan Wakely ---
No, I didn't say none of them come from configure. What I meant by "checking
anything at configure time" is anything related to the properties of the
compiler that ends up including the header. Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97253
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421
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=97198
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-09-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #11 from Jonathan Wakely ---
(In reply to rguent...@suse.de from comment #8)
> On Fri, 25 Sep 2020, redi at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
> >
> > --- Comment #7 from Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #12 from Jonathan Wakely ---
(In reply to Richard Biener from comment #9)
> diff --git a/gcc/vec.h b/gcc/vec.h
> index d73d865cff2..c0e577893a3 100644
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -1546,7 +1546,12 @@ public:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #13 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> If you don't want to support assignment you can still support swapping:
>
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -1546,9 +1546,21 @@ public:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #7 from Jonathan Wakely ---
(In reply to Richard Biener from comment #4)
> That swap couldn't have worked before because auto_vec eventually contains a
> pointer into itself. So the patch has improved things from broken to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #10 from Jonathan Wakely ---
If you don't want to support assignment you can still support swapping:
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1546,9 +1546,21 @@ public:
this->m_vec = r.m_vec;
r.m_vec = NULL;
}
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #13 from Jonathan Wakely ---
(In reply to Yuxuan Shui from comment #1)
> Example:
>
> This program normally deadlocks when using linked pthread:
>
> https://godbolt.org/z/Yrza4e
>
> But it will throw recursive_init_error when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198
--- Comment #2 from Jonathan Wakely ---
Hmm. It should be false for construction from no arguments i.e.
__is_constructible(int[]).
But thanks to parenthesized aggregate init, you can actually do:
using T = int[];
T t(1);
It's still true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97211
Bug ID: 97211
Summary: __cxa_guard_acquire fails to detect recursive init in
multithreaded code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97265
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-10-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> Yes, the lambda captures a local variable by value,
Duh, sorry, I meant captures a local variables BY REFERENCE.
> and then when you invoke
> the lambda it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #1 from Jonathan Wakely ---
(In reply to m farazma from comment #0)
> ```
> #include
>
> enum ValidateFlag : int8_t {
>a = 0, b , c
> };
>
> int main(){
> bool t = static_cast(c);
> return static_cast(t);
> }
> ```
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #3 from Jonathan Wakely ---
No, the type is ValidateFlag. It has an underlying type of int8_t, but that
just means it has the same size and range of values as int8_t. It's not
actually that type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
Jonathan Wakely changed:
What|Removed |Added
CC||lesley at lesleylai dot info
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97232
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97230
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97232
--- Comment #2 from Jonathan Wakely ---
If you compile with -D_GLIBCXX_ASSERTIONS then there is a runtime check:
/home/jwakely/gcc/11/include/c++/11.0.0/bits/stl_iterator_base_funcs.h:151:
constexpr void std::__advance(_InputIterator&,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97217
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #14 from Jonathan Wakely ---
There is an LWG issue requesting clarification in the standard:
https://wg21.link/lwg3197
Option B is consistent with the interpretation of libstdc++ (and recent
versions of libc++). If Option A or C is
1 - 100 of 6539 matches
Mail list logo
