https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
--- Comment #1 from Jonathan Wakely ---
As already noted at
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652571.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611
--- Comment #11 from Jonathan Wakely ---
The fix is in 13.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025
--- Comment #13 from Jonathan Wakely ---
(In reply to Alan Coopersmith from comment #11)
> While Solaris 11.3 support has been dropped from gcc now, Jonathan Perkins
> from pkgsrc found that just removing the definition of __STDC_VERSION__
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115196
--- Comment #4 from Jonathan Wakely ---
(In reply to Halalaluyafail3 from comment #0)
> This note doesn't seem to be very helpful, it mentions adding an extra
> '#include' when one is already present. A better error message here
> would be to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115196
--- Comment #3 from Jonathan Wakely ---
You seem to imply it's a general problem, but I think it's specific to
sd::to_address, and that's already fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115099
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |redi at gcc dot gnu.org
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940
--- Comment #8 from Jonathan Wakely ---
We have the same problem in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79384
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102774
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2022-05-18 00:00:00 |2024-5-21
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115173
--- Comment #2 from Jonathan Wakely ---
Further reduced:
struct string { string(int) { } };
void j() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115173
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-05-21
Keywords|
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800
--- Comment #8 from Jonathan Wakely ---
(In reply to Amatul Adeeba from comment #6)
> I mean even after trying the typo that is mentioned above, the error still
> occurs.
No it doesn't, it gives the correct error:
107800.cc: In function 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115160
--- Comment #5 from Jonathan Wakely ---
Specifically, std::vector::iterator::operator++(int) is "just a
function", so the compiler doesn't "know" that it modifies the iterator every
time it's called. To the compiler, the code looks like:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115163
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-05-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111230
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119
Jonathan Wakely changed:
What|Removed |Added
CC||pilarlatiesa at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115134
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Target Milestone|--- |14.2
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template
struct iter
{
void operator++(int) {
auto tmp = *this;
++this;
return tmp;
}
};
This has a typo, it should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119
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=115119
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-05-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104426
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115015
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115015
Jonathan Wakely changed:
What|Removed |Added
Summary|libstdc++ build with|[14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115063
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
--- Comment #7 from Jonathan Wakely ---
Fixed for 13.3 and 14.1 so far, I still plan to backport this to gcc-12 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> + using _ValT = typename iterator_traits<_InputIterator>::value_type;
> + if constexpr (is_same_v<_ValT, _Tp>)
> + if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040
--- Comment #5 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #4)
> Then this is partly a dup of bug 88545
Yes, that would manually transform the find_epi8 case into a memchr call, but
Clang doesn't need a manual transform in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
Jonathan Wakely changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
Bug 86172 depends on bug 115067, which changed state.
Bug 115067 Summary: Bogus -O2 -Wnull-dereference for istreambuf_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115067
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580
Jonathan Wakely changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115067
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
--- Comment #8 from Jonathan Wakely ---
Hmm, you could be right. It looks like the printf in Apple libc doesn't print
"-nan" even when not converting from float to double.
According to
|--- |13.3
Keywords||rejects-valid
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Last reconfirmed||2024-05-13
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115059
--- Comment #1 from Jonathan Wakely ---
I don't want to change anything in libstdc++ here. Either std::is_convertible
should be sufficient to check "convertible to" constraints, or "convertible to"
should exclude these kind of games.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #20 from Jonathan Wakely ---
(In reply to Jan Hubicka from comment #19)
> Similar argument can IMO be used for eliding unused memory allocations. It
> is kind of up to std::vector implementation on how many
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037
--- Comment #6 from Jonathan Wakely ---
Yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
--- Comment #6 from Jonathan Wakely ---
(In reply to Joseph S. Myers from comment #2)
> If a conversion from float to double (for passing in variable arguments)
> occurs at runtime on RISC-V, that will produce a positive-signed NaN (that's
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95659
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90857
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|14.2|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #12 from Jonathan Wakely ---
There's nothing fake about them, they are definitely inline functions as far as
the language rules. But in some cases we don't want the compiler to use that
fact as an optimisation hint.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940
--- Comment #6 from Jonathan Wakely ---
What would be needed to work without it? It looks like the allocation would
have to be larger so the size could be stored as a cookie at the start of the
allocated block?
Tangentially, could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482
--- Comment #8 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #6)
> Another reason this warning might be wanted: name mangling and demangling of
> global constructors has been buggy for awhile now; see bug 54254
Looks like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940
--- Comment #3 from Jonathan Wakely ---
P.S. what's optional is whether the compiler chooses to use that overload or
not. But its presence is required for conformance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704
--- Comment #10 from Jonathan Wakely ---
(In reply to Boris Kolpackov from comment #5)
> For anyone interested, here is the workaround we came up with:
>
> // A data race happens in the libstdc++ (as of GCC 7.2) implementation of the
> //
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114934
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-05-03
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #9 from Jonathan Wakely ---
There's a related data race in std::basic_ios::fill() because of these mutable
members:
mutable char_type _M_fill;
mutable bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-05-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
Jonathan Wakely changed:
What|Removed |Added
Known to work||13.2.1, 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606
Jonathan Wakely changed:
What|Removed |Added
Known to work||13.2.1, 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #18 from Jonathan Wakely ---
So maybe:
diff --git a/libstdc++-v3/include/bits/atomic_base.h
b/libstdc++-v3/include/bits/atomic_base.h
index aa7374bb252..662cff39df5 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #17 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #15)
> --- a/libstdc++-v3/include/std/atomic
> +++ b/libstdc++-v3/include/std/atomic
> @@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #16 from Jonathan Wakely ---
Alternatively, we could skip all the padding cope in compare_exchange for
C++11, since that was a C++20 change and not a DR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #15 from Jonathan Wakely ---
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
constexpr atomic(_Tp __i) noexcept : _M_i(__i)
{
-#if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #14 from Jonathan Wakely ---
Because a constexpr function can't have an if statement in C++11.
But maybe we should just clear padding unconditionally for C++11.
||https://gcc.gnu.org/piperma
||il/gcc-patches/2024-May/650
||419.html
Keywords||patch
Assignee|unassigned at gcc dot gnu.org |redi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Jonathan Wakely changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> Dup of Bug 102257, which might be what CWG 2586 says should happen, sadly.
Oops 2856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
--- Comment #2 from Jonathan Wakely ---
Only after the atomic wait/notify refactoring patches have landed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862
--- Comment #3 from Jonathan Wakely ---
I've opened https://cplusplus.github.io/LWG/issue4084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
--- Comment #1 from Jonathan Wakely ---
Standalone testcase:
struct nullopt_t {
enum class Hidden { Token };
explicit constexpr nullopt_t(Hidden) noexcept { }
};
struct in_place_t {
explicit constexpr in_place_t() = default;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80977
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-04-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862
--- Comment #2 from Jonathan Wakely ---
Libc++ has tests for "INF" (although only for long double, not float or
double), so it's apparently not accidental. The relevant code is:
if (floatfield == ios_base::fixed) {
if (uppercase)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863
--- Comment #2 from Jonathan Wakely ---
Maybe we could also make _M_localize more efficient for finite values by not
even attempting to use grouping for scientific format.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863
--- Comment #1 from Jonathan Wakely ---
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -1734,7 +1734,7 @@ namespace __format
}
#endif
- if (_M_spec._M_localized)
+ if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862
--- Comment #1 from Jonathan Wakely ---
Actually I think we're doing exactly what the standard requires:
ios_base::fmtflags __fltfield = __flags & ios_base::floatfield;
...
// [22.2.2.2.2] Table 58
if (__fltfield ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
at gcc dot gnu.org |redi at gcc dot gnu.org
Last reconfirmed||2024-04-26
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753
--- Comment #4 from Jonathan Wakely ---
Maybe I've misunderstood you, but the feature test macros for C++11 features
should definitely be defined for C++11.
They're not "system-specific" or "GCC-specific".
Just because they weren't in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114838
--- Comment #1 from Jonathan Wakely ---
It's guarded with _GLIBCXX_HAS_GTHREADS which is defined by configure when
__GTHREADS_CXX0X is defined by , which for gthr-win32.h means:
#if _WIN32_WINNT >= 0x0600
#define __GTHREAD_HAS_COND 1
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
Jonathan Wakely changed:
What|Removed |Added
Attachment #58015|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
Jonathan Wakely changed:
What|Removed |Added
Attachment #58014|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #7)
> Created attachment 58014 [details]
> Make std::pair relocatable and simplify __relocate_a
>
> Does this help?
Oh hang on, that patch is wrong. I'll fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #7 from Jonathan Wakely ---
Created attachment 58014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58014=edit
Make std::pair relocatable and simplify __relocate_a
Does this help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #5 from Jonathan Wakely ---
If the problem is simply that the __restrict qualifiers are not present because
we go through the generic function taking iterators, then we can just add:
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #4 from Jonathan Wakely ---
(In reply to Jan Hubicka from comment #2)
> --- a/libstdc++-v3/include/bits/stl_uninitialized.h
> +++ b/libstdc++-v3/include/bits/stl_uninitialized.h
> @@ -1130,7 +1130,58 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #3 from Jonathan Wakely ---
(In reply to Jan Hubicka from comment #2)
> This seems to do the trick, but for some reason I get memmove
What's the second overload for, and why does it depend on _GLIBCXX_HOSTED?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #1 from Jonathan Wakely ---
Using memcpy on any std::pair is undefined behaviour because it's not trivially
copyable.
That's not because it has a copy constructor, its copy constructor is defaulted
and so trivial if the data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99934
Jonathan Wakely changed:
What|Removed |Added
CC||pshevchuk at pshevchuk dot com
---
1 - 100 of 22389 matches
Mail list logo
