https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118817
--- Comment #14 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:77d01927bd7c989d431035251a5c196fe39bcec9
commit r15-7498-g77d01927bd7c989d431035251a5c196fe39bcec9
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106103
--- Comment #6 from Julian Waters ---
I tried to compile a program with -Os -flto=auto again recently, on a version
of gcc that has commit 5a1ef1cfac005370d0a5a0f85798724cb2c9cf5e applied. Same
issue, gcc still crashes with an ICE while linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118857
Bug ID: 118857
Summary: __builtin_verbose_trap should be added
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118841
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105728
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97735
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94693
--- Comment #5 from Andrew Pinski ---
I think since GCC 12, this is fixed. Via ipa mod-ref. I tested all testcases
here and GCC 12+ could optimize this via `-O3 -fno-inline` and turning off DSE
(`-fno-tree-dse`), kept the around the function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47233
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102150
Andrew Pinski changed:
What|Removed |Added
CC||infinity0 at pwned dot gg
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109943
--- Comment #8 from Andrew Pinski ---
So the reason why it took into fre3 (the second fre) without
__builtin_unreachable is that we need until then as `c` is not turned into a
constant pointer until then.
The turning into a static const var hap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118832
--- Comment #7 from Li Pan ---
Thanks Jeff and Robin, that makes much sense to me.
However, I got a little confused about the vec_duplicate with
define_insn_and_split. As I learned, define_insn_and_split equals define_insn +
define_split + defi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838
Lewis Hyatt changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99878
Andrew Pinski changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118848
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118856
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #4 from A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118856
--- Comment #3 from Andrew Pinski ---
Created attachment 60486
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60486&action=edit
Semi cleaned up testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118856
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118856
--- Comment #1 from Andrew Pinski ---
This looks related to the range for temporary change for C++23.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118856
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118855
--- Comment #3 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #1)
> I'll test this properly tomorrow, but it passes the 26_numerics/bit/* tests:
That is exactly what I meant.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118855
--- Comment #2 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #0)
> That is not the problem in C++ with templates. The advantage of
> __builtin_*g is that it will be shorter to parse, fewer ops in constexpr
> evaluation.
And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118855
--- Comment #1 from Jonathan Wakely ---
I'll test this properly tomorrow, but it passes the 26_numerics/bit/* tests:
--- a/libstdc++-v3/include/std/bit
+++ b/libstdc++-v3/include/std/bit
@@ -205,6 +205,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118855
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #24 from Jeffrey A. Law ---
The first approach looks better to me. I might suggest refactoring a bit by
precomputing how many iterations of the loop there will be and using that for
the outer control, allocation and the inner for co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
Nicholas Williams changed:
What|Removed |Added
Attachment #60483|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
Nicholas Williams changed:
What|Removed |Added
Attachment #60482|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
Nicholas Williams changed:
What|Removed |Added
Attachment #60481|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #9 from Edwin Lu ---
After talking with Palmer a bit about this, it looks like there might be an
issue with regards to insn scheduler. With -fno-schedule-insns the vsetvl is
inserted after the branch instead of before https://godbolt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #23 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #22)
> pthis.msgBuf = buf;
In D, this is an array copy assignment.
I've tried lowering this to `foreach (i; 0 .. 100) msgBuf[i] = buf[i]`, but
that doesn't trigger t
rap --disable-lto --disable-libsanitizer
--disable-libstdcxx-pch --enable-languages=c,c++ --disable-libgomp
--disable-libquadmath --disable-libvtv CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0'
LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250212 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #19 from Jonathan Wakely ---
(In reply to Nicholas Williams from comment #18)
> (In reply to Jonathan Wakely from comment #17)
> >
> > You must stop accessing a global object while it's being destroyed in
> > another thread. I reall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #22 from Iain Buclaw ---
Reasonably small D code reduction.
---
struct sICE
{
void **vtbl;
char[100] msgBuf = '\0';
}
sICE* ctor(sICE* pthis)
{
char[100] buf = void;
pthis.msgBuf = buf;
return pthis;
}
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118853
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is a dup of bug 97687.
At least related to it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118853
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102150
--- Comment #8 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:aa972d027437784686dfc66180dc1b640e7dbb39
commit r15-7495-gaa972d027437784686dfc66180dc1b640e7dbb39
Author: Andrew Pinski
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102150
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:8598a84bf5ca91ddd26f3bf6f944b0235cfa06b4
commit r15-7496-g8598a84bf5ca91ddd26f3bf6f944b0235cfa06b4
Author: Andrew Pinski
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #18 from Nicholas Williams
---
(In reply to Jonathan Wakely from comment #17)
>
> You must stop accessing a global object while it's being destroyed in
> another thread. I really don't know why this needs to be repeated so many
> t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117700
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
--- Comment #8 from Thomas Koenig ---
This works:
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index fdde84db80d..eee5520ad93 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -5822,7 +5822,14 @@ gfc_ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #9 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #6)
> Libc++ is NOT a variation or fork of libstc++ but it's own implementation
> and unrelated to libstdc++. If you hit there too, 99% chances were it is a
> bug in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #17 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> "- both conflicting evaluations are atomic operations (see std::atomic), or"
>
> They're not.
N.B. std::atomic::~atomic() is not an atomic operation, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #16 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #11)
> https://en.cppreference.com/w/cpp/language/multithread#Data_races
Please read this link, carefully.
"Two expression evaluations conflict if one of them m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115219
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #15 from Jonathan Wakely ---
(In reply to Nicholas Williams from comment #13)
> (In reply to Jonathan Wakely from comment #10)
> > If you need to make copies of a shared_ptr while also modifying it, you need
> > to use std::atomic> (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #14 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Andrew Pinski from comment #6)
> > Libc++ is NOT a variation or fork of libstc++ but it's own implementation
> > and unrelated to libstdc++. If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115032
--- Comment #5 from Gaius Mulley ---
PR modula2/118703 has now been back ported onto gcc-14. Is the failure still
present on Solaris/SPARC ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #13 from Nicholas Williams
---
(In reply to Jonathan Wakely from comment #10)
> If you need to make copies of a shared_ptr while also modifying it, you need
> to use std::atomic> (or
> std::experimental::atomic_shared_ptr).
Using s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #11 from Jonathan Wakely ---
https://en.cppreference.com/w/cpp/language/multithread#Data_races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #8 from Nicholas Williams ---
(In reply to Andrew Pinski from comment #4)
> fsanitize=address just changes timing slightly to give a race condition
> between the thread and the constructor to show up.
That's what I had assumed.
(In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118703
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Gaius Mulley
:
https://gcc.gnu.org/g:209de720fb8ad491568633780c8e8c5cca8b4c33
commit r14-11303-g209de720fb8ad491568633780c8e8c5cca8b4c33
Author: Gaius Mulley
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #12 from Jonathan Wakely ---
https://en.cppreference.com/w/cpp/memory/shared_ptr is explicit about it
(emphasis mine):
All member functions (including copy constructor and copy assignment) can be
called by multiple threads on differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #10 from Jonathan Wakely ---
(In reply to Nicholas Williams from comment #8)
> Notably, the copy constructor is declared noexcept. While I know that's
> syntatically about *exceptions*, the *implication* is that it should be safe
> t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #21 from Jeffrey A. Law ---
So even though it doens't produce a fault, I think I can see this with the x86
to riscv cross.
There's just 3 calls into riscv_block_move_straight, the second triggers the
problem path.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117351
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #7 from Jonathan Wakely ---
#if ( defined(__clang__) && __clang_major__ < 17 ) || ( !defined(__clang__) &&
defined(__GNUC__) && __GNUC__ < 11 )
// C++20's osyncstream is not supported in GCC < 11 and Clang < 15. It's
"experimental" i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #6 from Andrew Pinski ---
> Apple Clang 16 (which uses some variation/fork of libstdc++ but is failing in
> the exact same way with a slightly different stack within the shared_ptr copy
> constructor).
Libc++ is NOT a variation o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806
--- Comment #4 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:0fa06d7fd7820e0d60fd8da381ec45175a675c80
commit r15-7493-g0fa06d7fd7820e0d60fd8da381ec45175a675c80
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101740
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101740
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:b0cf0429bd711c2121a7d4a920d875157f19
commit r15-7492-gb0cf0429bd711c2121a7d4a920d875157f19
Author: Marek Polacek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #5 from Andrew Pinski ---
One way of fixing this is to move _pInstance to be a static variable inside
instance function which makes the initialization dynamic and correctly ordered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118855
Bug ID: 118855
Summary: Simplify when __builtin_*g builtins are
available
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #4 from Andrew Pinski ---
fsanitize=address just changes timing slightly to give a race condition between
the thread and the constructor to show up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #2 from Nicholas Williams ---
Created attachment 60482
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60482&action=edit
runtime_output.txt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #1 from Nicholas Williams ---
Created attachment 60481
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60481&action=edit
gcc_output.txt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
Bug ID: 118854
Summary: ASAN heap-after-use in shared_ptr copy constructor
when copying a shared_ptr constructed with make_shared
Product: gcc
Version: 14.2.1
Status: UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118853
Bug ID: 118853
Summary: -fmax-errors=N does not stop parsing after the Nth
error
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #19 from Iain Buclaw ---
Thanks Stefan.
I might be able to reduce the test if the reproducer works for me too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #18 from Jeffrey A. Law ---
Ah, a dockerfile for reproduction. Love it. I can fire that up here on one of
my x86 systems as well. The BPI (native) is already building, but it's far
from a performant system.
I think the biggest qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #17 from Stefan Schulze Frielinghaus
---
Meanwhile bisect stopped at r15-508-gad22c607f3e17f
Prior that commit we have for a call riscv_block_move_straight() with length=4
that
regs = XALLOCAVEC (rtx, length / delta);
is not call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118852
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118852
Bug ID: 118852
Summary: Train run of 502.gcc_r compiled with -Ofast
-fprofile-generate -march=x86_64-v3 fails
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #15 from Stefan Schulze Frielinghaus
---
So my reproducer looks like
FROM ubuntu:plucky
RUN sed -i 's/^Types: deb$/Types: deb deb-src/' \
/etc/apt/sources.list.d/ubuntu.sources
RUN apt-get update \
&& apt-get -y upgrade \
&&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-02-12
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118785
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2803
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118851
Bug ID: 118851
Summary: _Rb_tree::_M_equal_range_tr has linear complexity
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118790
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #14 from Matthias Klose ---
there's no .i file for D, the file in question is
libphobos/libdruntime/core/exception.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838
--- Comment #2 from Luca Bacci ---
> Given this has never worked in any version of GCC, it will probably need to
> wait for GCC 16 at this point
No problem at all, thanks for the fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #13 from Jeffrey A. Law ---
Ideally if you've got the .i file and compilation arguments we ought to be able
to reproduce without the s390x involvement :-) You can hand it off and we'll
take it over.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118248
--- Comment #12 from Stefan Schulze Frielinghaus
---
Confirmed.
Function riscv_block_move_straight() is called to copy 4 bytes. bits equals 64
which means delta equals 8. This in turn renders
regs = XALLOCAVEC (rtx, length / delta - 1);
into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118832
--- Comment #6 from Robin Dapp ---
Thanks for laying it out so clearly. Helps to put things into perspective.
I believe all our insn_and_split patterns already have can_create_pseudo_p in
their condition so shouldn't match after reload. Warra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118822
Andrew Pinski changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118842
--- Comment #4 from Jonathan Wakely ---
It should be:
struct A {} [[deprecated]];
or:
__attribute__((deprecated)) struct A {};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
Sam James changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118842
--- Comment #3 from Mingyi Chen ---
Just found out that the code below does not trigger the expected warning.
```c++
struct [[deprecated]] A {};
int main() {
(void)A{};
}
```
See https://compiler-explorer.com/z/4r8hYYPPa.
Is this a c++ f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118847
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118832
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-02-12
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791
--- Comment #15 from sandra at gcc dot gnu.org ---
See also PR115076. I think the low-level implementation of "declare variant"
is all wrong, it needs to be tracked in the lexical scope by each front end
instead of attached as a global property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117790
--- Comment #5 from GCC Commits ---
The master branch has been updated by Alex Coplan :
https://gcc.gnu.org/g:cfdb961588ba318a78e995d2e2cde43130acd993
commit r15-7491-gcfdb961588ba318a78e995d2e2cde43130acd993
Author: Alex Coplan
Date: Tue N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118850
Bug ID: 118850
Summary: _Rb_tree emplace unique functions should avoid
allocating node when emplacing value_type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117991
Matthew Malcomson changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |matmal01 at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #27 from Sam James ---
I'll test with the option re-enabled to confirm but I'm sure it is. I'll only
comment/reopen if problems persist.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118488
--- Comment #8 from waffl3x ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to waffl3x from comment #6)
> >
> > Reposting from PR118791,
> >
> > (OpenMP 6.0 113:1-2)
> > variant substitution
> > The replacement of a call to a bas
1 - 100 of 175 matches
Mail list logo
