https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115440
--- Comment #2 from Jonathan Wakely ---
People certainly do write --std, I see it all the time. I don't like it though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|13.3|12.4
--- Comment #19 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114367
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #11 from Jonathan Wakely ---
This changes the loop to always run if the input is non-empty, and so return
partial if the destination is empty.
--- a/libstdc++-v3/config/locale/gnu/codecvt_members.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #10 from Jonathan Wakely ---
Whereas the GNU locale has that check inside a loop, which is never entered
when the destination buffer is zero sized, i.e. __to == __to_end
if (__from_next < __from_end && __ret == ok)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #9 from Jonathan Wakely ---
(In reply to Kristian Spangsege from comment #7)
> Curiously, this bug does not occur when using the Cygwin or MinGW versions
> of GCC. In these cases, the result is `partial` as it should be. I assume
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #8 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59246
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 87403
Target Milestone: ---
We warn about undefined calls to pure virtual functions from constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115433
--- Comment #2 from Jonathan Wakely ---
I haven't noticed this myself because my ~/.dejagnurc contains:
if { [info exists v3-use-std-list] } {
# v3-dg-runtest supports running tests with multiple -std options.
set v3_std_list { 98 11 14 17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115433
--- Comment #1 from Jonathan Wakely ---
What's the baseline for comparisons, the 13.x releases?
We could make this change for release branches, so that C++20 and C++23 tests
are not also run for C++26:
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420
--- Comment #6 from Jonathan Wakely ---
We could even do:
/home/jwakely/gcc/15/include/c++/15.0.0/bits/hashtable.h:78:58: error: static
assertion failed: std::hash specialization is disabled; maybe the correct
header has not been included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420
--- Comment #5 from Jonathan Wakely ---
And if _Check_hash_requirements is defined at namespace scope not inside
_Hashtable then the first location is much easier to read:
/home/jwakely/gcc/15/include/c++/15.0.0/bits/hashtable.h: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115429
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-06-11
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421
--- Comment #15 from Jonathan Wakely ---
(In reply to Liviu Ionescu from comment #12)
> Isn't it possible to fix libstdc++ in order to run static multi-threaded
> apps on older systems too?
Just link all of libpthread.a as Andrew said.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421
--- Comment #14 from Jonathan Wakely ---
This is just a dup of PR 58909
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115402
--- Comment #6 from Jonathan Wakely ---
There is a paper being written to address both those issues, but it hasn't been
published yet. It should be P3323 when it's ready.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410
--- Comment #8 from Jonathan Wakely ---
(In reply to user202729 from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > They can be different due to the way shared libraries work.
>
> Ah, too bad.
>
> Is it safe to at least assume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115402
--- Comment #5 from Jonathan Wakely ---
And https://cplusplus.github.io/LWG/issue4069 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115399
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-06-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115391
--- Comment #6 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #3)
> Also you can use `--depth=1` to speed up the checkout if you don't need the
> full history.
Or partial clones, which avoid the problems of truncated history
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115391
--- Comment #1 from Jonathan Wakely ---
You really shouldn't ever need to start again, you can just do:
git fetch origin && git reset --hard origin/master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115368
--- Comment #3 from Jonathan Wakely ---
Please send patch to the gcc-patches mailing list rather than attaching them
here.
https://gcc.gnu.org/contribute.html#patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949
--- Comment #21 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #20)
> It's nonsense to suggest that only maintainers can make such changes to the
> docs, since it's clear and obvious that GCC does not provide everything the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949
--- Comment #20 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #19)
> It may be quite difficult to improve the docs without the first step from
> the maintainers to make the sensible default clear enough. Anyway, whether
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115371
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758
Jonathan Wakely changed:
What|Removed |Added
CC||kamil_tym at wp dot pl
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115241
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
Jonathan Wakely changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115357
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115358
--- Comment #3 from Jonathan Wakely ---
*** Bug 115357 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
--- Comment #8 from Jonathan Wakely ---
Yes, but it's only a missed-optimization bug so there are much higher
priorities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115335
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.2
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #11 from Jonathan Wakely ---
If a program really does need to ensure a particular TU assumes new can modify
global memory (e.g. in the TU defining operator new, which makes use of some
data structure) then that TU should probably be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #10 from Jonathan Wakely ---
But replacing operator new is a global property of the program. It seems to me
that any translation unit claiming that operator new is sane must imply that
it's sane globally.
It doesn't make sense for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115335
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-06-04
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #52 from Jonathan Wakely ---
(In reply to Christopher Nerz from comment #45)
> This is a critical bug which renders gcc unusable for safety relevant
> systems using expected/variant or simple ipc.
I don't think your example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #51 from Jonathan Wakely ---
(In reply to Richard Biener from comment #48)
> (In reply to Christopher Nerz from comment #47)
> > But shouldn't both give the same value?
>
> I'm not sure what the standard says to this. Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115269
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.5
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
Jonathan Wakely changed:
What|Removed |Added
CC||martin at martin dot st
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> I would argue that the root cause is that Clang does not conform to the
> platform ABI for mingw-w64, which requires __GXX_TYPEINFO_EQUALITY_INLINE=0
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
--- Comment #9 from Jonathan Wakely ---
Right, for Clang we need:
--- a/libstdc++-v3/libsupc++/typeinfo
+++ b/libstdc++-v3/libsupc++/typeinfo
@@ -73,7 +73,7 @@ namespace __cxxabiv1
// By default follow the old inline rules to avoid ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
--- Comment #7 from Jonathan Wakely ---
This is the fix I'm suggesting:
--- a/libstdc++-v3/libsupc++/typeinfo
+++ b/libstdc++-v3/libsupc++/typeinfo
@@ -188,6 +188,9 @@ namespace std
#endif
#if __GXX_TYPEINFO_EQUALITY_INLINE || __cplusplus >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
--- Comment #6 from Jonathan Wakely ---
(In reply to Peter Damianov from comment #5)
> #include
> int main() { return typeid(0) == typeid(0); }
>
> The following reproduces for me, although strangely only with -std=c++23 and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258
--- Comment #7 from Jonathan Wakely ---
The patch needs a little refactoring to share code with std::stacktrace, but it
will be fixed soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #35 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #31)
> Bisection points to r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363 for
> that remaining FAIL as well (and it isn't fixed by the new patch).
>
> It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #10 from Jonathan Wakely ---
When deciding whether a key already exists in the hash set we use these
overloads:
template
static __conditional_t<
__and_<__is_nothrow_invocable<_Hash&, const key_type&>,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #9 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #7)
> I am suspecting it was
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=2c43f5ec9db163696de8691eb529df06c4999bcc which caused the issue.
Ah no, I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #8 from Jonathan Wakely ---
Or r12-6272-ge3ef832a9e8d6a
I think the testcase is invalid. The unordered_set uses
std::equal_to to decide if a key already exists in the container,
and that just uses operator== which is not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852
--- Comment #5 from Jonathan Wakely ---
Bug 114600 comment 10 has a std module implementation attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115269
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641
--- Comment #11 from Jonathan Wakely ---
Dave, does this fix it for hppa-linux-gnu too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #7 from Jonathan Wakely ---
Thanks for the patch, but patch review happens on the mailing list, not in
bugzilla. Please repost to gcc-patches as documented in the submission
guidelines, thanks.
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
1 - 100 of 22443 matches
Mail list logo
