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=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=18469
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Jonathan W
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=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=97485
--- Comment #3 from Jonathan Wakely ---
Looks like a dup of PR 55394
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=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 either
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=95917
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-10-20
Status|UNCONFIR
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 C+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97512
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97512
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97517
Bug ID: 97517
Summary: _Up = 'nullptr_type' not supported by
simple_type_specifier'nullptr_type' not supported by
direct_abstract_declarator
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97517
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97518
--- Comment #2 from Jonathan Wakely ---
A related case I encounter often is:
static_assert( sizeof(T) == 4 );
if the assertion fails I would like to know what the size is, rather than just
"not 4", so I have to add something like Barry's verify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97537
--- Comment #1 from Jonathan Wakely ---
But the compiler never sees that #include, because it's guarded by the #ifndef
The -H option is not a general purpose dependency scanner, it just shows the
result of preprocessing. The documentation is cle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97537
--- Comment #2 from Jonathan Wakely ---
Oh sorry, I misread your example. The second #include "header3.h" is indeed
reached. The header is skipped due to the optimization described at
https://gcc.gnu.org/onlinedocs/cpp/Once-Only-Headers.html so t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97544
--- Comment #2 from Jonathan Wakely ---
It's right, but it's not helpful. There are other instantiations of the
template where the condition isn't always true, and users shouldn't have to
write the condition as (N != 0 && i < N) just to silence t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96742
--- Comment #4 from Jonathan Wakely ---
(In reply to William Throwe from comment #2)
> This warns if passed an array of length 0 because the for-loop condition is
> always false. Any change I can make to fix it seems to make the code worse.
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96742
--- Comment #5 from Jonathan Wakely ---
Oh and since C++17 you can do:
if constexpr (N != 0)
for (size_t i = 0; i < N; ++i) {
ret += i * x[i];
}
but it still shouldn't be necessary :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97569
--- Comment #1 from Jonathan Wakely ---
(In reply to Anders Granlund from comment #0)
> The interesting thing is that if we replace struct S with struct S {}
> both compilers agree on rejecting the program.
I don't see any struct S in the ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97572
--- Comment #1 from Jonathan Wakely ---
I think GCC is correct to reject this. any(t) is not a valid constraint.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97563
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #19 from Jonathan Wakely ---
I don't really care about test failures for non-standard configurations like
that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97574
--- Comment #1 from Jonathan Wakely ---
I think "nul" should work, but it looks like the error is in the linker,
ld.exe, not GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97569
--- Comment #3 from Jonathan Wakely ---
Ah right, so
int main()
{
struct A
{
struct B *b;
struct C {} *c;
};
using U = B;
using V = C;
}
For the `struct C {}` case that explicitly defines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97574
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97570
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97572
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #3 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97561
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97561
--- Comment #2 from Jonathan Wakely ---
Do you have a real world use case where the inheritance is actually required?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97570
--- Comment #2 from Jonathan Wakely ---
Thanks for the report. It's fixed on the development trunk now, but I will also
backport it to the release branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97562
--- Comment #1 from Jonathan Wakely ---
Dup of PR 51571 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97570
--- Comment #3 from Jonathan Wakely ---
(In reply to Matwey V. Kornilov from comment #0)
> Then gcc and libstdc++ are compiled and installed successfully without any
> further errors.
P.S. this is great news. I've been meaning to check this myse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940
--- Comment #13 from Jonathan Wakely ---
Should be fixed at g:01079b6a9236bd467b445fafaff2659840789a85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940
--- Comment #14 from Jonathan Wakely ---
P.S. if that failure only appeared recently it would be more useful to mail the
libstdc++ list than to add a comment to an old bug that hasn't been touched in
years.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97584
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
Jonathan Wakely changed:
What|Removed |Added
CC||andrea_iob at hotmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
Jonathan Wakely changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86577
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
Jonathan Wakely changed:
What|Removed |Added
CC||tonvandenheuvel at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83035
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
Jonathan Wakely changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70099
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465
--- Comment #10 from Jonathan Wakely ---
Created attachment 49449
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49449&action=edit
preprocessed source, unreduced, gzipped
Here's another example that produces this kind of warning, this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97595
Bug ID: 97595
Summary: [11 Regression] warning: writing 1 byte into a region
of size 0 [-Wstringop-overflow=]
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97595
--- Comment #2 from Jonathan Wakely ---
Reduced:
#include
template void std::basic_iostream::swap(basic_iostream&);
The preprocessed code is no smaller, but this should only generate code for the
problematic function, not the entire class and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97595
--- Comment #1 from Jonathan Wakely ---
Created attachment 49452
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49452&action=edit
preprocessed source, unreduced, gzipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95609
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95592
Jonathan Wakely changed:
What|Removed |Added
Keywords||build
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95567
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95557
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89610
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92124
Jonathan Wakely changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
Jonathan Wakely changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65114
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #3 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60630
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-10-28
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65113
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60630
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97629
Bug ID: 97629
Summary: Difference of addresses of array elements not a
constant expression
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Keywords: rejects-va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97566
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-10-29
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97632
Bug ID: 97632
Summary: unhelpful -Winit-list-lifetime warning for
default-initialized object in unevaluated context
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|11.0|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
--- Comment #6 from Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Bug ID: 97653
Summary: Incorrect long double calculation with
-mabi=ibmlongdouble
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #1 from Jonathan Wakely ---
Created attachment 49479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49479&action=edit
Assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #2 from Jonathan Wakely ---
Without -mabilongdouble the result is correct.
If configured with --with-long-double-format=ibm the result is correct with any
-mabi option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #3 from Jonathan Wakely ---
int printf(const char*, ...);
const unsigned long k = 256;
int main()
{
long double r[] = { 0.1L, 0.2L, 0.5L, 0.9L };
for (int i = 0; i < 4; ++i)
{
unsigned long j = k * r[i];
printf("%lu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94200
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958
--- Comment #9 from Jonathan Wakely ---
N.B. the calls to __builtin_ceill and __builtin_floorl also need to be changed
to avoid implicit conversions to long double.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958
--- Comment #10 from Jonathan Wakely ---
There are a few other places doing unnecessary long double arithmetic, e.g.
r11-4588-60d9f254876a00260992b2f37639ef4d82d9db8f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97654
--- Comment #2 from Jonathan Wakely ---
(In reply to devl from comment #0)
> Created attachment 49480 [details]
> Full output with -v
>
> std::filesystem::copy() with copy_options = copy_symlinks |
> overwrite_existing does not overwrite existin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97658
--- Comment #1 from Jonathan Wakely ---
The compiler is telling you your code has undefined behaviour.
If you write code that conforms to the rules of the C++ language, you won't get
that warning.
Don't change your makefiles, fix your code.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659
--- Comment #1 from Jonathan Wakely ---
This looks like a bug in the sanitizer. I assume it's triggering because the
memory returned by the allocator doesn't refer to an array, so the two
addresses are not pointing to subobjects of a single objec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #44 from Jonathan Wakely ---
It looks like mingw* has the same problem:
https://sourceforge.net/p/mingw-w64/bugs/778/
mlloc returns memory aligned to 8 bytes, GCC's stddef.h says 16 is a
fundamental alignment. Even worse, mingw's own
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659
--- Comment #5 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #3)
> That sanitizer diagnoses
> http://eel.is/c++draft/expr.add#5.3
> which still seems UB.
Not since http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97675
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97690
Bug ID: 97690
Summary: (cond ? 2 : 0) is not optimized to int(cond) << 1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97690
--- Comment #1 from Jonathan Wakely ---
It seems to be target-independent. For aarch64, -O3 and -Os both give:
f(bool):
tst w0, 255
csetw0, ne
lsl w0, w0, 1
ret
g(bool):
ubfiz w0, w0, 1, 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97690
--- Comment #2 from Jonathan Wakely ---
More generally, Clang seems to reliably turn
cond ? (2<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97658
--- Comment #4 from Jonathan Wakely ---
Nonsense. Your code is buggy, the warning tells you about it.
If you don't want to know that your code has undefined behaviour, don't enable
warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84323
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Bug 55394 depends on bug 84323, which changed state.
Bug 84323 Summary: call_once uses TLS even when once_flag is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84323
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84323
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Bug 66146 depends on bug 84323, which changed state.
Bug 84323 Summary: call_once uses TLS even when once_flag is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84323
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #33 from Jonathan Wakely ---
Fixed for linux targets, not others though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39909
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |4.4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #34 from Jonathan Wakely ---
Untested sketch of a solution for Solaris and BSDs:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557928.html
401 - 500 of 7819 matches
Mail list logo
