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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114806
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114806
--- Comment #1 from Jonathan Wakely ---
*** Bug 114805 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114805
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #10 from Jonathan Wakely ---
N.B. If you're going to do any more profiling + optimizing of std::vector,
please do it with -std=gnu++20 so that everything is constexpr. Otherwise
you're only testing C++17 which is the last version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #9 from Jonathan Wakely ---
Another solution is just to use __builtin_expect or [[likely]] or [[unlikely]]
at the call site. That wouldn't need any compiler changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #7 from Jonathan Wakely ---
I think we might want to add __attribute__((cold)) to std::vector functions
that are now implicitly inline due to the addition of `constexpr`. We probably
don't want to use noinline as that's too strong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114770
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
ty: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
int main()
{
(void) std::chrono::locate_zone("Asia/Chungking");
}
With the latest tzdata (version 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114758
--- Comment #2 from Jonathan Wakely ---
It's just yet another occurrence of false positive -Wstringop-overflow
warnings, it has nothing to do with vector being special.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> With __val = 9223372036854775808LL __sign = -1LL
Oops, that should be __val = 9223372036854775808ULL and __sign = -1
i.e.
int main()
{
unsigned long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585
--- Comment #4 from Jonathan Wakely ---
Created attachment 57961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57961=edit
Add --enable-clocale=ieee_1003.1-2008
This is an initial prototype of a new clocale model.
The wide string info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #13 from Jonathan Wakely ---
-fexcess-precision does affect constants.
With -fexcess-precision=standard, assignments and casts discard excess
precision which may otherwise be present in arithmetic expressions and
constants. With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742
--- Comment #2 from Jonathan Wakely ---
Mathias noted that still fails with -mcpu=power7
Checking for _ARCH_PWR8 or __POWER8_VECTOR__ instead works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> Separately, it would be good to provide a libintl-based implementation of
> std::messages, for targets where that's not part of glibc.
Although the POSIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740
--- Comment #1 from Jonathan Wakely ---
See the first item at https://gcc.gnu.org/gcc-13/changes.html#cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> N.B. messages_base::catalog is required to be a typedef for int, although
> there is an open issue which would allow intptr_t to be used instead:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585
--- Comment #2 from Jonathan Wakely ---
Separately, it would be good to provide a libintl-based implementation of
std::messages, for targets where that's not part of glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749
Bug 106749 depends on bug 113386, which changed state.
Bug 113386 Summary: [C++23] std::pair comparison operators should be
transparent, but are not in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
1 - 100 of 22363 matches
Mail list logo
