https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109150
--- Comment #9 from Jonathan Wakely ---
Fixed on trunk for now, but I think this should be backported because the
current code on the branches is non-conforming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #17 from Jonathan Wakely ---
And this one is needed before that patch series:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655267.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115575
--- Comment #1 from Jonathan Wakely ---
It fails on x86_64-pc-linux-gnu too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
Jonathan Wakely changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109150
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
--- Comment #16 from Jonathan Wakely ---
Two patches posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655274.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655273.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110900
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|12.5|12.4
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105440
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|12.5|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|12.5|---
--- Comment #18 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115522
Jonathan Wakely changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109150
--- Comment #6 from Jonathan Wakely ---
(In reply to Arthur O'Dwyer from comment #4)
> The if-condition will have trouble *for now* with `Leopard`-like types
What trouble? I don't care if there's some confusing deleted assignment, I care
that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109150
--- Comment #5 from Jonathan Wakely ---
I don't think we're on the same page at all.
I'm intending to use the trait to mean that the assignment is known to call no
operation that is not trivial, as defined in the standard today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109150
--- Comment #3 from Jonathan Wakely ---
I think we can use this condition:
const bool __load_outside_loop =
#if __has_builtin(__is_trivially_constructible) \
&& __has_builtin(__is_trivially_assignable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109150
--- Comment #2 from Jonathan Wakely ---
Another example of how the optimization is non-conforming, as I just
rediscovered:
#include
#include
struct X {
int i = 0;
X& operator=(int ii)
{
i = ii + 1;
return *this;
}
};
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88935
--- Comment #13 from Jonathan Wakely ---
std::random_shuffle was removed from the C++ standard years ago, precisely
because it uses low quality randomness. So it's not a high priority to fix
something that is no longer even in the standard,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #14 from Jonathan Wakely ---
I assume clang doesn't have __is_arithmetic, __is_scalar and __is_void
built-ins yet, because also defines class templates
with those names.
At least __are_same, __is_integer and __is_floating don't
at gcc dot gnu.org |redi at gcc dot gnu.org
Status|NEW |ASSIGNED
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85723
--- Comment #3 from Jonathan Wakely ---
And again, causing PR 115522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115522
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115514
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115514
--- Comment #2 from Jonathan Wakely ---
The constraint on reverse_iterator::operator->() checks it for an lvalue, which
suggests nobody considered (or cared) about annoying iterators that do
something different for lvalues and rvalues.
I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115514
--- Comment #1 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #0)
> (Another difference is it only applies the resolution for C++17 onward.)
C++20 onward, I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115522
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
>static_assert(is_constructible_v<_Tp, _Tp&>);
>if constexpr (is_constructible_v<_Tp, _Tp&>)
> {
> - if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115522
--- Comment #3 from Jonathan Wakely ---
That shouldn't be needed, because a trivial class has to have a trivial default
constructor.
The problem is that we default-initialize the array, which requires the const
members to be initialized.
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #15 from Jonathan Wakely ---
Oops, that's definitely not intended! Good catch, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #11 from Jonathan Wakely ---
Although that class template has been there for years, so if any library like
abseil was using the built-in, they're already have the problem that libstdc++
now has.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #10 from Jonathan Wakely ---
The only foolproof fix would be to rename the __is_pointer class template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #9 from Jonathan Wakely ---
Changing libstdc++ order of includes won't help abseil. If their use of
__is_pointer still comes after any standard header has included
cpp_type_traits.h, the identifier will be "poisoned" by the class
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #6 from Jonathan Wakely ---
(In reply to Mital Ashok from comment #4)
> Forcing it to be an expression in the first place does let it compile:
>
> template
> struct is_pointer : ts(__is_pointer(_Tp))> {};
Ah nice, we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #5 from Jonathan Wakely ---
I suppose we can just include at the top of
, we could even make that conditional on __clang__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
--- Comment #15 from Jonathan Wakely ---
No, this only helps for mingw-g++. Only the change from comment 7 has been
committed. As noted in comment 9, the incorrect macro definition for clang
still causes problems. We either need to work around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115481
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115480
--- Comment #6 from Jonathan Wakely ---
(In reply to Louis Dionne from comment #0)
> we thought we'd point it out in case it
> was considered an ABI break introduced ~2 years ago.
Thanks! It looks like this changed the ABI in C++20 mode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
--- Comment #8 from Jonathan Wakely ---
(In reply to Paolo Carlini from comment #2)
> Basing on posts to the LWG reflector + private converstation, it seems
> likely that the standard is moving to the behavior which is currently
> implemented by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115482
Jonathan Wakely changed:
What|Removed |Added
Keywords||build
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115482
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-06-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
--- Comment #5 from Jonathan Wakely ---
For output, the requirement to set failbit was present since C++98, not added
by a DR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> The requirement to set failbit came from
> https://cplusplus.github.io/LWG/issue211 and certainly seems consistent with
> other input operations, which set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
--- Comment #7 from Jonathan Wakely ---
I think we can just do this in __ostream_insert:
--- a/libstdc++-v3/include/bits/ostream_insert.h
+++ b/libstdc++-v3/include/bits/ostream_insert.h
@@ -103,6 +103,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
--- Comment #6 from Jonathan Wakely ---
It looks like we've been setting badbit in ostream::_M_write(const charT*,
streamsize) since it was added in r0-47606-g8d0a564bba54f7
That function was used to replace the similar code in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #3 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38678
--- Comment #6 from Jonathan Wakely ---
MSVC and libc++ both behave the same as libstdc++, calling rdbuf()->sgetn():
https://github.com/microsoft/STL/blob/e36ee6c2b9bc6f5b1f70776c18cf5d3a93a69798/stl/inc/istream#L522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13823
--- Comment #14 from Jonathan Wakely ---
(In reply to Dan Evison from comment #0)
> This seems to a problem with the default allocator, since running the
> program
> with GLIBCPP_FORCE_NEW set, removes the problem, and dramatically speeds up
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24537
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641
--- Comment #18 from Jonathan Wakely ---
Nice - thank you both. I think we can close this.
libstdc++_libbacktrace.a does exist on the gcc-13 branch, but isn't enabled by
default so you probably aren't seeing these FAILs there.
If anybody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113376
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
URL|
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
URL||https://gcc.gnu.org/piperma
||il/gcc-patches/2024-June/65
||4410.html
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
Jonathan Wakely changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115399
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||13.3.0
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Target Milestone|--- |14.2
Summary|Confusing notes when using |[14/15 Regression]
|C++17 parallel algorithms |Confusing notes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113376
--- Comment #6 from Jonathan Wakely ---
(In reply to Pilar Latiesa from comment #3)
> It seems that what is missing is a corresponding change in the macro
> definition logic. It should have been changed to:
>
> // Check the user-defined macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113376
--- Comment #5 from Jonathan Wakely ---
I think
https://github.com/llvm/llvm-project/commit/3b9a1bb1af90db9472340ef2122d3855eb9ba3fc#r142768040
is the real cause of the problem. They wanted to avoid -Wundef errors, so
changed all the macro
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
1 - 100 of 22507 matches
Mail list logo
