https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118683
--- Comment #3 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:5d001fa122bf04cfd0611ff7723969a0421b3094
commit r15-7262-g5d001fa122bf04cfd0611ff7723969a0421b3094
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118187
--- Comment #2 from Hubert Tong ---
(In reply to Patrick Palka from comment #1)
> The ttp's constraints can depend on outer template parameters, which I think
> prevents us from being able to check its constraints before instantiation in
> gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #438 from Oleg Endo ---
Could be relevant
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673346.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672694.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-Janua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118687
--- Comment #6 from Jeffrey A. Law ---
I think invalid for GCC. Not sure how binutils will respond to a request to
do a lot of constant synthesis. And even if binutils handles it it's probably
a bad thing to do anyway -- think about the impac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118687
--- Comment #5 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #2)
> Basically what I am saying this should be filed in gas rather than in GCC.
Yeah understood but is this really the right thing to do - to re-implement all
the con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118688
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-01-29
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118687
--- Comment #4 from Andrew Pinski ---
Plus this seems like just a bug in the riscv llvm backend to accept this ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118687
--- Comment #3 from Andrew Pinski ---
Plus shouldn't this be filed over to
https://github.com/riscv/riscv-isa-manual/issues for the assembler macro?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118688
Bug ID: 118688
Summary: patch splitting should happen when it is known only
path is hot
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118687
--- Comment #2 from Andrew Pinski ---
Basically what I am saying this should be filed in gas rather than in GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118687
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-01-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118687
Bug ID: 118687
Summary: RISC-V extensions for inline asm code (vs. llvm)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
--- Comment #17 from Andrew Pinski ---
Note many if not all modern branch predictors and figure out patterns for 256
wise. So increasing it to 1000 forces the branch predictor not to be predict
which way the branch is taken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Component|tree-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #34 from Thiago Macieira ---
H.J. fixed this a few years ago. It requires the -mno-direct-extern-access
flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673
Jason Merrill changed:
What|Removed |Added
Summary|[14/15 regression] LLVM's |[14 regression] LLVM's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
Jason Merrill changed:
What|Removed |Added
Summary|[14/15 Regression] GCC |[14 Regression] GCC rejects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 118285, which changed state.
Bug 118285 Summary: [14 Regression] GCC rejects some constexpr std::string
usages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
Jason Merrill changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 118285, which changed state.
Bug 118285 Summary: [14/15 Regression] GCC rejects some constexpr std::string
usages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:c3b0b98b3ba57840ab2cfbc9d44d001c1e9167bf
commit r15-7260-gc3b0b98b3ba57840ab2cfbc9d44d001c1e9167bf
Author: Jason Merrill
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115614
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2025-01-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117778
--- Comment #3 from Marek Polacek ---
The following should run fine but we issue an error since
r12-5860-g6a071b2d40a107:
commit 6a071b2d40a1078b4029c2b77ef29ffca4e7050c
Author: Marek Polacek
Date: Thu Nov 25 09:08:03 2021 -0500
c++: Ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118187
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280
--- Comment #12 from Michael Eager ---
If you have a patch, please send it to gcc-patc...@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118340
--- Comment #5 from Patrick Palka ---
FWIW disabling the block containing the cp_fully_fold calls breaks
g++.dg/cpp0x/warn-ovl2.C and g++.dg/warn/multiple-overflow-warn-3.C,
unsurprisingly.
We can't leverage the fold_cache here because cp_fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118683
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
--- Comment #11 from Krister Walfridsson ---
FWIW, this also happens on RISC-V. You can observe it by compiling the
following function with "-O3 -march=rv64gcv"
float
test (float x, float *ptr, int n)
{
for (int i = 0; i < n; ++i)
x = __b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
--- Comment #15 from Andrew Pinski ---
So one thing interesting is for x86_64 GCC does not produce a conditional move.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
--- Comment #14 from Andrew Pinski ---
Created attachment 60312
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60312&action=edit
Fix for the -O3 case
This is the fix for the -O3 regression. I should note that x86_64 didn't have a
regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
--- Comment #13 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #12)
> Created attachment 60310 [details]
> Original benchmark
>
> Just uploading the standalone benchmark without any changes to the constant
> formation.
> Note Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860
Jeffrey A. Law changed:
What|Removed |Added
Assignee|konstantinos.eleftheriou@vr |law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118683
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Last reconfirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685
kargls at comcast dot net changed:
What|Removed |Added
CC||gerald at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118683
--- Comment #1 from anlauf at gcc dot gnu.org ---
Created attachment 60311
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60311&action=edit
Patch
Confirmed.
Running f951 under gdb, it appears that the fix for pr117774, which dealt
with in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
--- Comment #12 from Andrew Pinski ---
Created attachment 60310
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60310&action=edit
Original benchmark
Just uploading the standalone benchmark without any changes to the constant
formation.
Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396
--- Comment #19 from Carlos Galvez ---
I can confirm that recent versions of trunk fixed the problem described in this
thread, thank you so much!
> Sounds like another regression?
I need to run more tests to confirm. It is a very huge file, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118681
--- Comment #4 from Diego Ramirez ---
I think the way to fix this is finding the the first pool block size `B` such
as `B >= size` and `B & (alignment - 1) == 0` (or in other words `gcd(B,
alignment) == alignment)`).
The starting point in `pool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117202
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118533
Sam James changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685
--- Comment #1 from Dimitry Andric ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674663.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117202
Richard Sandiford changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118538
--- Comment #19 from Andrew Pinski ---
I was wrong, it is only static linking where the issue I had saw was an issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118538
--- Comment #18 from Andrew Pinski ---
Actually I think I know what this is.
Ubuntu defaults to PIE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106880
Patrick Palka changed:
What|Removed |Added
Assignee|ppalka at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117202
--- Comment #5 from Richard Sandiford ---
FWIW, gcc.target/riscv/rvv/autovec/struct/mask_struct_store_run-3.c seems to
produce similar VEC_PERM_EXPRs for SVE, but it works there.
The idea is that we're unpacking one vector of [16,16] chars into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118642
Richard Earnshaw changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #3 from Ri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
--- Comment #5 from Jakub Jelinek ---
The extra VAR_DECLs whose addresses are recorded in the initializers are
created in
#0 make_node (code=VAR_DECL) at ../../gcc/tree.cc:1244
#1 0x01609ce1 in build_decl (loc=4611686018427387913, code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118642
--- Comment #2 from GCC Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:0204dcf930b5093d0811a007b7f47aa42e55e787
commit r15-7258-g0204dcf930b5093d0811a007b7f47aa42e55e787
Author: Richard Earnshaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
--- Comment #4 from Jakub Jelinek ---
With minor tweaks to that:
--- pr118285-3.C2025-01-28 16:30:15.798692471 +0100
+++ pr118285-5.C2025-01-28 16:46:09.572904490 +0100
@@ -6,21 +6,21 @@ template struct initializer
}
struct A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118675
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118684
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118684
--- Comment #5 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:54bdeca3c6214485d15454df30183a56ad3e473b
commit r15-7257-g54bdeca3c6214485d15454df30183a56ad3e473b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117202
--- Comment #4 from Richard Biener ---
Created attachment 60309
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60309&action=edit
refreshed patch
I picked this from a branch where it was updated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
Palmer Dabbelt changed:
What|Removed |Added
CC||palmer at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118675
--- Comment #1 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:b4bd06774ced72d5f0059ec55022840ad3f37fa4
commit r15-7255-gb4bd06774ced72d5f0059ec55022840ad3f37fa4
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570
--- Comment #9 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #2)
> I think this is a duplicate of PR106379 . At the VRP2 stage I see:
>
>[local count: 1073741824]:
> if (c_6(D) == s_7(D))
> goto ; [34.00%]
> els
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118626
--- Comment #9 from Patrick Palka ---
A valid reduced testcase:
template struct _Nth_type;
template
struct variant {
template static constexpr long __accepted_index = 0;
template using __to_type = _Nth_type<_Np>;
template using __accepte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118626
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396
--- Comment #18 from Patrick Palka ---
(In reply to Carlos Galvez from comment #17)
> (FYI I'm trying to test this but now I get out-of-memory errors when trying
> to compile a single .cpp file, will test with a newer patch in case it got
> fixe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #14 from Vladimir Makarov ---
(In reply to Richard Biener from comment #12)
> Re-confirmed.
>
> +FAIL: gcc.target/i386/force-indirect-call-2.c scan-assembler-times
> (?:call|jmp)[ \\t]+\\*% 3
> +FAIL: gcc.target/i386/pr91384.c scan-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:98b2009b8768f8790dff9edbe00742bcdf2b7482
commit r15-7254-g98b2009b8768f8790dff9edbe00742bcdf2b7482
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 117270, which changed state.
Bug 117270 Summary: [15 Regression] 9% exec time slowdown of 538.imagick_r on
aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117855
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117855
--- Comment #10 from GCC Commits ---
The releases/gcc-14 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:c061ad5a36ba0c07d3d9d82a85aebb887def759d
commit r14-11256-gc061ad5a36ba0c07d3d9d82a85aebb887def759d
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114277
--- Comment #10 from Jeffrey A. Law ---
So on the RISC-V specific side of this we will need a bit of work and all
things that would help address some of the weaknesses in utilization of the
zicond extension.
First, for the comparison in the con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117855
--- Comment #9 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:ea578dd251eaf6304b0c95acc107f9a4d63bee8f
commit r15-7253-gea578dd251eaf6304b0c95acc107f9a4d63bee8f
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91198
--- Comment #7 from Richard Biener ---
The first issue to address is
t.c:4:20: note: Analyze phi: j_26 = PHI
t.c:4:20: missed: reduction used in loop.
t.c:4:20: missed: Unknown def-use cycle pattern.
and then
t.c:4:20: note: mark rele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #14 from Iain Buclaw ---
The compiler itself doesn't depend on the phobos standard library part of
libphobos, only druntime. User applications would use Phobos however.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118629
--- Comment #7 from Jakub Jelinek ---
For
template
struct S {
char s[N];
};
const char *z;
auto foo() -> S {
z = __func__;
return {};
}
int bar() {
return sizeof (foo ());
}
both gcc and clang warn about it, but I think it shouldn't war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118684
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112859
--- Comment #7 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:3ccbc8c9d182c380e396631b2b5a683de4fddba9
commit r15-7252-g3ccbc8c9d182c380e396631b2b5a683de4fddba9
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118684
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118684
--- Comment #3 from Richard Biener ---
(In reply to Andreas Schwab from comment #1)
> Does that also happen if you remove the undefined behaviour?
The code generation still happens when I make it conditionally executed. It's
the "easiest" case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118629
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118686
--- Comment #1 from David Malcolm ---
Of course, we shouldn't be generating malformed data, but that can be a
separate bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118686
Bug ID: 118686
Summary: Poor error message for ill-formed UTF-8 sequence
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118684
--- Comment #1 from Andreas Schwab ---
Does that also happen if you remove the undefined behaviour?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118629
--- Comment #5 from Jakub Jelinek ---
Of course, __PRETTY_FUNCTION__ isn't in the standard, so we can do whatever we
want, but __func__ is said to be implicitly defined in function parameter
scope, so at least __func__ in the late return type sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685
Bug ID: 118685
Summary: FreeBSD static executables segfault due to libgcc
missing crtbeginT.o
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424
Richard Biener changed:
What|Removed |Added
Known to work||15.0
Summary|[12/13/14/15 r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118684
Bug ID: 118684
Summary: wrong alignment for stack temporary created during RTL
expansion
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
--- Comment #13 from GCC Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:01339d29b7663d85eea6145eac2b1ad1da428c11
commit r15-7250-g01339d29b7663d85eea6145eac2b1ad1da428c11
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #7 from Martin Jambor ---
(In reply to Martin Jambor from comment #4)
> [...] Unfortunately when I
> then looked at SLP vectorization when all IPA-VR propagations were
> allowed again, this particular case was not there (but there we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118629
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424
--- Comment #13 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f1e776ce58ae4a6ae67886adb4ae806598e2c7ef
commit r15-7249-gf1e776ce58ae4a6ae67886adb4ae806598e2c7ef
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #13 from Brecht Sanders ---
I understand that would give me a gdc with runtime and no libphobos.
What is needed to make that usable as a compiler?
Do I need to build libphobos spearately or from a different source?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108367
--- Comment #7 from Sam James ---
(In reply to Andrew Pinski from comment #6)
> I can't reproduce this starting in GCC 14.1.0. From the looks of it, it was
> a patch to loop ch which "fixes" the ICE but that would mean this has gone
> latent; ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118681
--- Comment #3 from Andrew Pinski ---
synchronized_pool_resource::do_allocate has the similar code but with a lock
for the pool case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118681
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118681
--- Comment #1 from Andrew Pinski ---
Created attachment 60307
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60307&action=edit
testcase from godbolt
Next time attach the testcase instead of just linking godbolt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #12 from Iain Buclaw ---
(In reply to Brecht Sanders from comment #11)
> Apparently MinGW-w64 dosn't like extern char** environ;
>
> To avoid this issue for now I commented out the following in
> gcc/cp/module.cc:
> extern char **
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110901
--- Comment #8 from GCC Commits ---
The releases/gcc-13 branch has been updated by Tamar Christina
:
https://gcc.gnu.org/g:57a9595f05efe2839a39e711c6cf3ce21ca1ff33
commit r13-9352-g57a9595f05efe2839a39e711c6cf3ce21ca1ff33
Author: Tamar Christi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
--- Comment #13 from GCC Commits ---
The releases/gcc-13 branch has been updated by Tamar Christina
:
https://gcc.gnu.org/g:eb45b829bb3fb658aa34a340264dee9755d34e69
commit r13-9351-geb45b829bb3fb658aa34a340264dee9755d34e69
Author: Tamar Christ
1 - 100 of 117 matches
Mail list logo