https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118846
Bug ID: 118846
Summary: [modules] Unbound template arguments considered
TU-local
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87728
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118832
Li Pan changed:
What|Removed |Added
CC||pan2.li at intel dot com
--- Comment #1 from L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
Andrew Pinski changed:
What|Removed |Added
Attachment #60472|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118843
--- Comment #5 from chenglulu ---
(In reply to Xi Ruoyao from comment #4)
> (In reply to chenglulu from comment #3)
>
> > I tried to make some changes, and the test went smoothly without any issues.
> > for (int i = 0; i < N_EVO_FEATURES; i++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
--- Comment #1 from Andrew Pinski ---
Created attachment 60470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60470&action=edit
Reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
Andrew Pinski changed:
What|Removed |Added
Attachment #60471|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
Andrew Pinski changed:
What|Removed |Added
Attachment #60470|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-02-12
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118843
--- Comment #4 from Xi Ruoyao ---
(In reply to chenglulu from comment #3)
> I tried to make some changes, and the test went smoothly without any issues.
> for (int i = 0; i < N_EVO_FEATURES; i++)
> {
> builtin_undef (la_evo_macro_na
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118843
--- Comment #3 from chenglulu ---
(In reply to Xi Ruoyao from comment #2)
> We have
>
> if (TARGET_HARD_FLOAT && ISA_HAS_FRECIPE)
> builtin_define ("__loongarch_frecipe");
>
> where the logic seems correct. But __loongarch_frecipe is al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118843
--- Comment #2 from Xi Ruoyao ---
We have
if (TARGET_HARD_FLOAT && ISA_HAS_FRECIPE)
builtin_define ("__loongarch_frecipe");
where the logic seems correct. But __loongarch_frecipe is also in
la_evo_macro_name and it can get defined by:
bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250211 (experimental)
4abac2ffdb071ca9337e4f31fa79cd38df1ac7c3 (Gentoo 15.0. p, commit
1240e2dfcd8257243dfbe473fc934fa18482b91b)
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 118826, which changed state.
Bug 118826 Summary: segmentation fault compiling a module fragment containing
an exported struct with a default virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115007
Nathaniel Shead changed:
What|Removed |Added
CC||rarrum at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118826
Nathaniel Shead changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org
Res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102150
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102150
--- Comment #6 from Andrew Pinski ---
Created attachment 60468
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60468&action=edit
The second patch; RTL loop invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102150
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> Created attachment 60465 [details]
> Path for the ifcvt case
>
> Note this patch does NOT change the definition of trapping but it does fix a
> costing issue th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118720
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/jeaiii/i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118720
--- Comment #10 from Daniel Green ---
Created attachment 60467
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60467&action=edit
Second testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118720
--- Comment #9 from Daniel Green ---
Sorry for bringing this up again, but here is a comment by the guy who
originally created the code (full thread here
https://github.com/jeaiii/itoa/issues/17#issuecomment-2652085888) and another
example (http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118844
Bug ID: 118844
Summary: Link failure caused by crtbeginS.o
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118843
chenglulu changed:
What|Removed |Added
Target||loongarch64*-*-*
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118843
Bug ID: 118843
Summary: The predefined macro `__loongarch_frecipe` is still
defined when using `-mfpu=none`
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118601
Jin Ma changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118601
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Ma Jin :
https://gcc.gnu.org/g:580f571be6ce80aa71fb80e7b16e01824f088229
commit r15-7489-g580f571be6ce80aa71fb80e7b16e01824f088229
Author: Jin Ma
Date: Tue Feb 11 21:28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85640
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 88596, which changed state.
Bug 88596 Summary: [12/13/14/15 Regression] ICE: Maximum number of LRA
assignment passes is achieved (30)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:2605daa6b896aed15dead194462725874f332c0a
commit r15-7485-g2605daa6b896aed15dead194462725874f332c0a
Author: Yangyu Chen
Date: Tue Feb 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118826
--- Comment #2 from Luke ---
Created attachment 60466
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60466&action=edit
Simpler Repro Layout
Attached a simpler (still standalone) repro for the problem that doesn't
require xmake.
Simply ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118842
Bug ID: 118842
Summary: `std::result_of` and `std::result_of_t` should be
removed in C++20
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115932
--- Comment #4 from Hans-Peter Nilsson ---
FWIW, I'm waiting on an improvement on the committed hook (perhaps another
hook), as it seems widely agreed not to be a solution, before I revisit this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284
Hans-Peter Nilsson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #22 from Nicholas Williams
---
(In reply to Jonathan Wakely from comment #20)
> Because the constructors for globals in the libstdc++.so shared library are
> run before the ones in your program. This happens when the shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284
--- Comment #16 from Hans-Peter Nilsson ---
(In reply to Richard Biener from comment #15)
> Is this resolved now?
(Referring to this PR, not the reorg.c bug, I presume)
I *think* so. Rainer?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478
--- Comment #11 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:71f6540fc54036cc8f71db497cc22816f794549a
commit r15-7483-g71f6540fc54036cc8f71db497cc22816f794549a
Author: Jeff Law
Date: Tue Feb 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838
Lewis Hyatt changed:
What|Removed |Added
Last reconfirmed||2025-02-11
Version|14.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102150
--- Comment #4 from Andrew Pinski ---
Created attachment 60465
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60465&action=edit
Path for the ifcvt case
Note this patch does NOT change the definition of trapping but it does fix a
costing i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47253
--- Comment #17 from H.J. Lu ---
My current patches are at
https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/condjmp/master?ref_type=heads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #25 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:0d2a5f3cb715fd95f1fa4a13b5d67c7eea28f178
commit r15-7481-g0d2a5f3cb715fd95f1fa4a13b5d67c7eea28f178
Author: Jason Merrill
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107637
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:0d2a5f3cb715fd95f1fa4a13b5d67c7eea28f178
commit r15-7481-g0d2a5f3cb715fd95f1fa4a13b5d67c7eea28f178
Author: Jason Merrill
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102150
--- Comment #3 from Andrew Pinski ---
Just a little history here.
Before r0-27963-g22aa60a1e04832 (in GCC 3.0.0), no inline-asm was considered a
trapping. That changed it such that volatile inline-asm and old style
inline-asm was trapping.
Now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102150
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118841
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118841
--- Comment #2 from Jonathan Wakely ---
Maybe like this:
--- a/libstdc++-v3/include/bits/random.tcc
+++ b/libstdc++-v3/include/bits/random.tcc
@@ -3351,12 +3351,17 @@ namespace __detail
static_assert(std::is_floating_point<_RealType>::va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118841
--- Comment #1 from Jonathan Wakely ---
It's not about the range, it's the precision within the range. But I think it
can be changed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118841
Bug ID: 118841
Summary: please do not use long double in generate_canonical
when the range is small enough
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118825
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118825
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:bd52571d713749f1a4cf0f58ca4922dbc42b5752
commit r12-10950-gbd52571d713749f1a4cf0f58ca4922dbc42b5752
Author: H.J. Lu
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118825
--- Comment #4 from GCC Commits ---
The releases/gcc-14 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:5f47dc6e9aa82e1c00ed030cb9469cd84df8691d
commit r14-11301-g5f47dc6e9aa82e1c00ed030cb9469cd84df8691d
Author: H.J. Lu
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118825
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:0a1c9d03309ff1e507f7ea347fe8cc12bf669296
commit r13-9371-g0a1c9d03309ff1e507f7ea347fe8cc12bf669296
Author: H.J. Lu
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84796
--- Comment #9 from Patrick Palka ---
I suppose one way to make this work is to eagerly expand pack expansions in
member template parameter lists when instantiating a class template.
Consequently we'd now reject the below testcase due to conflic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96909
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #3)
> (In reply to Thomas Koenig from comment #2)
> > Works on master now, I suspect as a result of Andre's recent work.
> >
> > Can we close this?
>
> Yes. With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96909
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117430
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #4)
> Now the question is, do we tweak the existing handling of this or leave it
> alone. I think this is an example where allowing non standard stuff can b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96909
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97123
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Last reconf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117430
--- Comment #4 from Jerry DeLisle ---
If I had just scrolled down in resolve.cc a few more hunks, eye roll:
$ gfc -pedantic zorig.f90
zorig.f90:45:32:
45 | write(*,*) "B:", self%cptr
|1
Warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96909
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711
--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #8)
> (In reply to Tobias Burnus from comment #6)
> > Patch for PR40276 and this PR:
> > http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html (approved).
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96909
Thomas Koenig changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84918
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #10 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118061
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118080
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94170
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711
Thomas Koenig changed:
What|Removed |Added
Keywords||needs-stdcheck
--- Comment #8 from Thoma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118831
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
--- Comment #15 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #14)
> However (and as shown in Comment #11) the flags register is far from UNUSED
> (let alone DEAD), because it is used in i3. So, the proposed solution is to
> simply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
--- Comment #14 from Uroš Bizjak ---
Untested patch:
--cut here--
diff --git a/gcc/combine.cc b/gcc/combine.cc
index 3beeb514b81..99cd64ada1f 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -14559,7 +14559,8 @@ distribute_notes (rtx notes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118826
--- Comment #1 from Luke ---
For reference, this same code compiles on on both msvc and clang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118840
Bug ID: 118840
Summary: RISC-V: current rv64gcv testsuite failures as of
r15-7464-g30a3a557a54
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118839
Bug ID: 118839
Summary: [OpenMP] Missing diagnostic when the variant is the
same as the base name
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: acce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #21 from Jonathan Wakely ---
https://maskray.me/blog/2021-11-07-init-ctors-init-array covers it in as clear
a way as I've seen.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #20 from Jonathan Wakely ---
Because the constructors for globals in the libstdc++.so shared library are run
before the ones in your program. This happens when the shared library is loaded
into the process.
When you link to libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
--- Comment #16 from Luca Bacci ---
Hi FeRD,
Following your suggestion I have opened a dedicated ticket:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838
Thanks,
Luca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838
Bug ID: 118838
Summary: _Pragma diagnostic ignored inside macro
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118827
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118834
--- Comment #3 from Andrew Pinski ---
I have not looked fully but
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667976.html might to a
patch to solve this. I also suspect it is too late to get into GCC 15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118834
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-02-11
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118836
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118102
--- Comment #18 from ganime ---
i found my issue, when i profile first with -O2 and than prof-use with -Ofast,
i receive compile error.
when i compile in profiling run with -Ofast and compile again with prof-use
-Ofast compile running well.
sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118340
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #15 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:4abac2ffdb071ca9337e4f31fa79cd38df1ac7c3
commit r15-7476-g4abac2ffdb071ca9337e4f31fa79cd38df1ac7c3
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118746
--- Comment #3 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:4abac2ffdb071ca9337e4f31fa79cd38df1ac7c3
commit r15-7476-g4abac2ffdb071ca9337e4f31fa79cd38df1ac7c3
Author: Martin Jambor
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
--- Comment #15 from FeRD ---
(In reply to Luca Bacci from comment #14)
> Hello, I have the same issue with the C frontend:
>
> test-gcc.c:
> --
> #define PRAGMA_FENV_ACCESS_ON \
> _Pragma ("GCC diagnostic push") \
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118827
Palmer Dabbelt changed:
What|Removed |Added
CC||palmer at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #19 from Nicholas Williams
---
'm having a hard time wrapping my head around why static vs dynamic would cause
this bug to reveal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #18 from Nicholas Williams
---
(In reply to Jonathan Wakely from comment #17)
> (In reply to Nicholas Williams from comment #1)
> > Created attachment 60438 [details]
> > gcc -v output from buggy RHEL/GCC14
>
> The reason this does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118306
Simon Martin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118304
Simon Martin changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|mpolacek at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118304
--- Comment #6 from GCC Commits ---
The master branch has been updated by Simon Martin :
https://gcc.gnu.org/g:c74e7f651a014d59631361bcc9be05d797928c5c
commit r15-7475-gc74e7f651a014d59631361bcc9be05d797928c5c
Author: Simon Martin
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118306
--- Comment #3 from GCC Commits ---
The master branch has been updated by Simon Martin :
https://gcc.gnu.org/g:c74e7f651a014d59631361bcc9be05d797928c5c
commit r15-7475-gc74e7f651a014d59631361bcc9be05d797928c5c
Author: Simon Martin
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
--- Comment #10 from Peter Damianov ---
Currently binutils does not install windres into the "tooldir" where gcc
typically seems to be searching, which is likely why the behavior Pali was
observing was happening.
in binutils/Makefile.in simply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118790
--- Comment #25 from Richard Biener ---
(In reply to Jakub Jelinek from comment #24)
> So
> --- gcc/tree-ssa-live.cc.jj 2025-01-02 11:23:05.915664859 +0100
> +++ gcc/tree-ssa-live.cc 2025-02-11 14:44:33.940178150 +0100
> @@ -369,9 +369,17
1 - 100 of 177 matches
Mail list logo
