https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
--- Comment #8 from Jonathan Wakely ---
Good point, it looks like we get the same codegen improvement for ~T(){} even
at -O1 if we don't restrict it to trivially destructible types.
There seems to be no difference in codegen for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
--- Comment #6 from Jonathan Wakely ---
I think I prefer:
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -311,6 +311,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
if (this->_M_engaged)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112498
--- Comment #3 from Jonathan Wakely ---
Maybe we could add "is not allowed in ISO C++" or similar to the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111638
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|13.3|14.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112473
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|13.3|12.4
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112467
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110859
--- Comment #5 from Jonathan Wakely ---
Should be fixed at r14-5260-ge39b3e02c27bd7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
--- Comment #4 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #3)
> I think that is because that transformation would violate the memory model
> of C++.
Ah yes. It would be safe for another thread to read the same memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112467
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=112480
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-11-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112473
--- Comment #3 from Jonathan Wakely ---
Although you couldn't use std::pair as a NTTP until C++20 anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112473
--- Comment #2 from Jonathan Wakely ---
Ah it changed in C++20, previously it said "T shall be an integral type" so was
just UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112467
--- Comment #5 from Jonathan Wakely ---
Oh, but that's presumably true for clang, just not in this context. Ugh.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112467
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112348
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #2 from Jonathan Wakely ---
Mine.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
struct S {
[[nodiscard]] S() { }
};
void f()
{
S();
}
This correctly warns:
nod.cc: In function 'void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109882
--- Comment #10 from Jonathan Wakely ---
The fix has been committed upstream now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|14.0|13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112452
Jonathan Wakely changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
--- Comment #24 from Jonathan Wakely ---
Oh, but this would be an ABI break. When using the explicit instantiation
definitions in libstdc++.so allocations and deallocations will match because
both will come from the library. But if anything is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
Jonathan Wakely changed:
What|Removed |Added
Assignee|giovannibajo at gmail dot com |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
--- Comment #22 from Jonathan Wakely ---
This bug is still present in the COW std::string, which is still supported even
though it's not the default.
There are two problems. The first is the one reported by James Kanze, that the
string contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #8 from Jonathan Wakely ---
The aliasing doesn't happen when writing to the array, it's when reading a
char* value from an object of type unsigned char*.
If you just passed the unsigned char* to memcpy instead of *(char**) it
would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #2 from Jonathan Wakely ---
Looks like it doesn't always segfault, but the contents of the tmp buffer are
incorrect (which might segfault, or might fail to print "test!").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93971
--- Comment #12 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #11)
> I don't think it's valid to use a plain char array as storage for an object
> of another type; the "provides storage" wording in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112440
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
--- Comment #28 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #27)
> But the alignment problem still seems to be present in the COW std::string.
But I think that's covered by PR 8670, which is still open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
--- Comment #27 from Jonathan Wakely ---
(In reply to Ben Elliston from comment #26)
> This test now passes on powerpc*-linux-gnu.
I wonder how ... the "fix" got reverted, and we still use an allocator of char
to create the storage for the COW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112440
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-11-08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112439
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948
--- Comment #7 from Jonathan Wakely ---
Thanks! I briefly tried but failed to reproduce it in a reduced example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112437
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580
Jonathan Wakely changed:
What|Removed |Added
CC||jlame646 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
Bug 86172 depends on bug 112421, which changed state.
Bug 112421 Summary: GCC emits warning potential null dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112421
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112421
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
--- Comment #17 from Jonathan Wakely ---
Thanks, Ian!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409
--- Comment #3 from Jonathan Wakely ---
(In reply to Frediano Ziglio from comment #0)
> static unsigned
> cksum(const void *pkt, size_t len, unsigned int start)
> {
> const uint16_t *data = (const uint16_t *) pkt;
> unsigned sum =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110859
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110807
--- Comment #12 from Jonathan Wakely ---
I don't think _M_offset can ever be out of range, it's always set by the
library code.
Doesn't the warning come from this line, which doesn't use _M_offset anyway?
_Bit_type* __q =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112351
--- Comment #2 from Jonathan Wakely ---
Ah yes, that's a good point. Patrick's improvement affects this initialization.
It's not done for all targets though, as not all targets have linker support
for the init_priority attribute (notably,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112377
--- Comment #3 from Jonathan Wakely ---
(In reply to David Binderman from comment #0)
> I think that should be enough to implement the new warning for C++.
Certainly not. Apart from the fact that there's a lot more needed than just
making the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
Jonathan Wakely changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112269
--- Comment #9 from Jonathan Wakely ---
(In reply to Patrick Palka from comment #5)
> I can't reproduce any of these testsuite failures on trunk with x86_64
> -m32... could you provide a preprocessed source file perhaps?
The libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112373
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
Jonathan Wakely changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335
--- Comment #10 from Jonathan Wakely ---
Ah, now I understand what you've been saying about the postcondition.
Yes, but the compiler doesn't know the postcondition, it's just words in the
standard, so not visible to the optimization passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335
--- Comment #8 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #7)
> > Demo: https://godbolt.org/z/PWd96j4fz
>
> Thank you for the example, but honestly, I think I am still missing
> something.
>
> If you modify the main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314
--- Comment #4 from Jonathan Wakely ---
(In reply to Jose Dapena Paz from comment #2)
> In any case, the failing test is actually passing -1, my understanding is
> that that one should always assert no matter what we are passing as const
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314
--- Comment #7 from Jonathan Wakely ---
(In reply to Jose Dapena Paz from comment #5)
> - The length is less than the possible pointer difference (checked with
> numeric_limits).
That seems too lenient to me, because for wchar_t, char16_t and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314
--- Comment #6 from Jonathan Wakely ---
Created attachment 56494
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56494=edit
Check [ptr,end) and [ptr,ptr+n) ranges with _GLIBCXX_ASSERTIONS
With this change we could add:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112351
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107513
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> The patch for PR 96780 added -ffold-simple-inlines which works for some
> specific functions. This attribute would extend that to arbitrary functions.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112318
--- Comment #3 from Jonathan Wakely ---
As this bug points out, we probably want to warn for any uses of deprecated
entities declared in user code, whether used in system headers or in user code.
And for something like std::auto_ptr which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112318
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112315
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112315
Jonathan Wakely changed:
What|Removed |Added
See Also||https://bugzilla.redhat.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107513
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-10-31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112301
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Summary|Double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112296
--- Comment #3 from Jonathan Wakely ---
(In reply to Barry Revzin from comment #0)
> inline int direct(Span span) {
> return __builtin_constant_p(span.size());
> }
>
> inline int indirect(Span span) {
> size_t s = span.size();
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112296
--- Comment #2 from Jonathan Wakely ---
I think you mean std::is_constant_evaluated, but that doesn't check values, it
checks if the function is being evaluated as constexpr. And if-constexpr can't
be used here either, that works like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112293
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> That would be difficult, because std::remove is overloaded and another
> overload was found here (the one declared in ). Usually we only
> provide fix-it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112293
--- Comment #4 from Jonathan Wakely ---
FWIW the change in transitive includes was r14-1459-g940645cec500ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112293
--- Comment #3 from Jonathan Wakely ---
As I wrote in PR 82594, the error should say that the number of arguments is
wrong instead of the irrelevant error about converting to const char*.
I don't think a fix-it is likely here though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82594
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112293
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> This is broken in two ways, you need to include both *and*
> for this program.
Actually three ways. There is no guarantee that std::vector's iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112293
--- Comment #1 from Jonathan Wakely ---
(In reply to Petr Vaněk from comment #0)
> The issue appears to arise from internal changes in libstdc++ that now
> require the explicit inclusion of the header (this part is
> likely a bug within
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8943
Jonathan Wakely changed:
What|Removed |Added
Priority|P3 |P5
CC|gcc-bugs at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
--- Comment #1 from Jonathan Wakely ---
I'm not sure if this is a libstdc++ problem or should be component=libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112097
--- Comment #3 from Jonathan Wakely ---
I hope the Intel devs got it right :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366
--- Comment #12 from Jonathan Wakely ---
Is the engine a C++ application, or C, or something else?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366
--- Comment #10 from Jonathan Wakely ---
My best guess for what's happening in the original report is that the shared
library is being loaded into a running process which uses an older version of
libstdc++, and so the locale facets needed by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366
--- Comment #9 from Jonathan Wakely ---
If this only happens when the shared library is loaded from a closed source
application, you really need to talk to Oracle.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366
--- Comment #8 from Jonathan Wakely ---
We still don't have a complete description of the problem though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112089
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.5
--- Comment #3 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> It would need a completely new category of "memory location that you can
> read and write to but nothing else"
That was supposed to say "read and write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
--- Comment #3 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #1)
> Maybe some how libstdc++ debug mode can catch this
> https://gcc.gnu.org/onlinedocs/gcc-13.2.0/libstdc++/manual/manual/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
--- Comment #2 from Jonathan Wakely ---
(In reply to Jan Engelhardt from comment #0)
> ==55843==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xsomething
How would that even be possible? The terminating nul clearly has to be in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112097
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-10-26
|1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely ---
Good catch, thanks! I think I probably just copy the throw from one of
the locking functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111936
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111974
--- Comment #2 from Jonathan Wakely ---
(In reply to Basile Starynkevitch from comment #0)
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
^^^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111920
--- Comment #4 from Jonathan Wakely ---
N.B. this same ICE was affecting C++ too, several libstdc++ tests failed with
-std=c++20, e.g.
GLIBCXX_TESTSUITE_STDS=20 make check
RUNTESTFLAGS=conformance.exp=*/48101-2_neg.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111897
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111963
--- Comment #1 from Jonathan Wakely ---
The internal functions like __partition could just take forwarding references
to the predicates, at least for C++11 and later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65675
--- Comment #8 from Jonathan Wakely ---
libitm needs getenv, and so does libsanitizer:
/home/test/src/gcc/libsanitizer/ubsan/ubsan_flags.cpp: In function ‘const char*
__ubsan::GetFlag(const char*)’:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65675
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-10-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111936
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|13.3|12.4
--- Comment #10 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948
--- Comment #3 from Jonathan Wakely ---
This compiles OK:
namespace std::ranges
{
template
class subrange
{
private:
template
struct _Size
{ };
template
struct _Size
{ U _M_size; };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948
--- Comment #2 from Jonathan Wakely ---
(In reply to 康桓瑋 from comment #1)
> _M_size._M_size in the function body is already const.
It shouldn't be. Is that a compiler bug?
Clang compiles the same libstdc++ code without problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111936
--- Comment #8 from Jonathan Wakely ---
Run autoreconf in the libstdc++-v3 dir, but you need the right versions of
automake and autoconf. The effect of doing that would be this additional patch,
which I didn't show (because it's just a
901 - 1000 of 22425 matches
Mail list logo
