https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
--- Comment #9 from Xi Ruoyao ---
(In reply to Jerry DeLisle from comment #7)
> More importantly I dont believe it is legitimate to run fortran IO in a
> libgomp environment at all. It was and is not designed to run omp_parallel.
> The fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86270
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #13 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:83bc61c9fd6581d0a4c4ee16bdfdaeedcdd6ebcd
commit r15-7636-g83bc61c9fd6581d0a4c4ee16bdfdaeedcdd6ebcd
Author: H.J. Lu
Date: Wed Feb 19 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86270
--- Comment #18 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:94d01a884702934bc03ccedff62e2c65515c8c83
commit r15-7637-g94d01a884702934bc03ccedff62e2c65515c8c83
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
--- Comment #10 from rguenther at suse dot de ---
On Wed, 19 Feb 2025, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
>
> --- Comment #9 from Andrew Pinski ---
> The reason why it works with the C fron
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118948
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118947
Richard Biener changed:
What|Removed |Added
Keywords||alias, missed-optimization
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118946
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #12 from Miao Wang ---
(In reply to Hongtao Liu from comment #11)
> (In reply to Miao Wang from comment #10)
> > (In reply to Hongtao Liu from comment #9)
> > > >
> > > > > Because I think the operands usage is broken.
> > > >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
--- Comment #8 from chenglulu ---
(In reply to Jerry DeLisle from comment #7)
> (In reply to chenglulu from comment #1)
> > Upon debugging, it was discovered that if the '-O0' option is used to
> > compile the `find_file0` function in `libgfortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
--- Comment #4 from 康桓瑋 ---
> Our concat_view implementation is accidentally based off of an older
> revision of the paper, P2542R7 instead of R8. As far as I can tell the
> only semantic change in the final revision is the relaxed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118948
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #11 from Hongtao Liu ---
(In reply to Miao Wang from comment #10)
> (In reply to Hongtao Liu from comment #9)
> > >
> > > > Because I think the operands usage is broken.
> > >
> > > Additionally, by removing the do{ ... } while(0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #16 from Jeffrey A. Law ---
Even if it doesn't help this diagnostic, it would be a good thing to do since
it would make the second conditional statically computable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #10 from Miao Wang ---
(In reply to Hongtao Liu from comment #9)
> >
> > > Because I think the operands usage is broken.
> >
> > Additionally, by removing the do{ ... } while(0) wrap from
> > bigint_test_exec(), the issue disappear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #9 from Hongtao Liu ---
>
> > Because I think the operands usage is broken.
>
> Additionally, by removing the do{ ... } while(0) wrap from
> bigint_test_exec(), the issue disappears. I believe that if it is the
> operands usage is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118914
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110645
--- Comment #2 from Jeffrey A. Law ---
In the bowels of the relevant code, if we don't know the range of the source
size, then we set is to the range of the destination size. I vaguely recall
Martin doing this, but nothing about the reasoning b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
--- Comment #2 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:8543dc52d84662e3fc0b8b6ac5e98ce13ebe9ad9
commit r15-7632-g8543dc52d84662e3fc0b8b6ac5e98ce13ebe9ad9
Author: Patrick Palka
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118948
Andrew Pinski changed:
What|Removed |Added
Summary|[15 Regression] ICE: tree |[15 Regression] ICE: tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118948
--- Comment #1 from Andrew Pinski ---
Created attachment 60538
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60538&action=edit
Reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118948
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Summary|ICE: tree check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
--- Comment #6 from chenglulu ---
I have obtained the following information：
==
WARNING: ThreadSanitizer: data race (pid=2647316)
Read of size 8 at 0x7fffeb336f08 by thread T7 (mutexes: read M0):
#0 find_file0 (libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501
H.J. Lu changed:
What|Removed |Added
Attachment #53473|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 110764, which changed state.
Bug 110764 Summary: [12/13/14/15 Regression] False positive -Warray-bounds
warning swapping std::thread::id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111696
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #8 from Miao Wang ---
(In reply to Andrew Pinski from comment #5)
> Note I suspect using C with some (generic) builtins might be faster than
> what the inline-asm could provide these days than the inline-asm that was
> used. Plus I d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #7 from Miao Wang ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Miao Wang from comment #3)
> > (In reply to Andrew Pinski from comment #2)
> > > I am suspect the inline-asm is just broken rather than the compiler bei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #3 from Andrew Pinski ---
Note I think -O3 -fwhole-program is enough to reproduce it and you don't need
-flto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #2 from Andrew Pinski ---
_304 = _113 != 0;
_373 = _113 == 0;
_305 = _132 != 0;
_377 = _132 == 0;
_597 = () _377;
_598 = [vec_duplicate_expr] _597;
_599 = _359 + 20;
_602 = VIEW_CONVERT_EXPR(_305);
_603 = [vec_dupli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114360
Jeffrey A. Law changed:
What|Removed |Added
Summary|[12/13/14/15 regression]|[12/13/14 regression] Bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114592
Jeffrey A. Law changed:
What|Removed |Added
Summary|[12/13/14/15 regression]|[12/13/14 regression] Bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #1 from Andrew Pinski ---
Looks related to PR 116059 and the load mask issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117204
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 117204, which changed state.
Bug 117204 Summary: [12/13/14/15 regression] After r12-2132-ga1108556677, bogus
-Warray-bounds warnings in std::vector::back()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117204
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
Bug ID: 118950
Summary: [14/15 regression] RISC-V: rv64gcv runtime mismatch at
-O3 since r14-4038-gb975c0dc3be
Product: gcc
Version: 15.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
Bug ID: 118949
Summary: RISC-V: Extra FRM writes since GCC-14.2
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118948
Bug ID: 118948
Summary: ICE: tree check: expected class 'type', have
'exceptional' (error_mark) in
tree_single_nonnegative_warnv_p, at
fold-const.cc:14878
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117482
Jeffrey A. Law changed:
What|Removed |Added
Target Milestone|12.5|16.0
--- Comment #2 from Jeffrey A. La
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118914
--- Comment #3 from Andrew Pinski ---
Created attachment 60536
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60536&action=edit
patch under testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118914
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #4 from Vineet Gupta ---
The following hack does prevent the fusion
+ inline bool tail_policy_eq2_p (const vsetvl_info &prev,
+const vsetvl_info &next)
+ {
+return (((prev.get_policy_demand () =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #3 from Vineet Gupta ---
(In reply to JuzheZhong from comment #2)
> I have thought about this long time ago while I am working on supporting RVV
> on upstream GCC.
>
> https://github.com/riscv-non-isa/riscv-toolchain-conventions/iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118914
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #2 from JuzheZhong ---
I have thought about this long time ago while I am working on supporting RVV on
upstream GCC.
https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/37
I suggested we should have -mprefer-agnosti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118946
Bug ID: 118946
Summary: Missed optimization: GCC reserves stack space for
optimized-out variable
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118947
Bug ID: 118947
Summary: Missed optimization: GCC forgets stack buffer contents
across function call
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116623
Thiago Jung Bauermann changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116623
--- Comment #3 from Thiago Jung Bauermann
---
(In reply to Thiago Jung Bauermann from comment #2)
> I also checked the bfloat16_scalar_*.c failures, and they're still present.
I checked again today and now the bfloat16_scalar_*.c failures are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116604
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
--- Comment #9 from Andrew Pinski ---
The reason why it works with the C front-end is actaully because of
r9-6782-g2a82beaa820410. There C front-end explictly makes enum and the
underlying integer types have the same aliasing set.
So the questi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118932
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
--- Comment #8 from Andrew Pinski ---
https://lists.isocpp.org/std-discussion/2022/05/1656.php
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
--- Comment #14 from Iain Buclaw ---
(In reply to Sam James from comment #13)
> Thanks Iain.
>
> Building stage0 with STAGE1_C{,XX}FLAGS="-O0" works. I'll try reproduce
> manually next.
At the bottom of the conservative/gc.d module (well, almos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #6 from Andrew Pinski ---
(In reply to Miao Wang from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > I am suspect the inline-asm is just broken rather than the compiler being
> > broken ...
>
> However, by replacing t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #1 from Vineet Gupta ---
Looking at the VSETVL dumps:
Splitting with gen_split_2313 (vector.md:1777)
scanning new insn with uid = 70. # New VSETVL for vector load
deleting insn with uid = 16. # or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #5 from Andrew Pinski ---
Note I suspect using C with some (generic) builtins might be faster than what
the inline-asm could provide these days than the inline-asm that was used. Plus
I doubt the speed of big-int would ever be the bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
Bug ID: 118945
Summary: RISC-V: VSETL pass: Don't promote Vectors ops from
Tail agnostic to Tail Undisturbed
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
See Als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118944
Bug ID: 118944
Summary: deduced conflicting types for explicitly specified
(non-deduced) template parameter in explicit object
member function of struct template
Product: g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
Waldemar Brodkorb changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #7 from Waldemar Brodkorb ---
This code was the culprit:
https://cgit.openadk.org/cgi/cgit/openadk.git/tree/toolchain/gcc/Makefile#n327
I have once got it from simplelinux from Greg Ungerer for coldfire/m68k builds.
I don't remember
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
Matthias Klose changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118942
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117829
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #76 from Andrew Pinski ---
Note r14-7202-gc8ec3e1327cb1e added few more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118942
Andrew Pinski changed:
What|Removed |Added
CC||info at kleisauke dot nl
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118943
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #4 from Andrew Pinski ---
bigint_init_raw inline-asm is broken but I am not sure that is the issue
though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118943
Bug ID: 118943
Summary: [Arm][Neon] incorrect types for vld1q_[s8,s16]_[x3,x4]
intrinsics
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118942
Bug ID: 118942
Summary: [14/15 Regression] vld1q_s{8,16}_x{3,4} use incorrect
pointer type
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Keywords: rejects-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #11 from Andrew Pinski ---
Created attachment 60533
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60533&action=edit
Reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #2 from Andrew Pinski ---
I am suspect the inline-asm is just broken rather than the compiler being
broken ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #3 from Miao Wang ---
(In reply to Andrew Pinski from comment #2)
> I am suspect the inline-asm is just broken rather than the compiler being
> broken ...
However, by replacing the inline-asm with a simple nop, the issue persists. B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #5 from Waldemar Brodkorb ---
(In reply to Mikael Pettersson from comment #3)
> Is that before or after you built the target glibc?
It is after target glibc build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #12 from Andrew Pinski --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
Andrew Pinski changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118941
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
Sam James changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
Summ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
Sam James changed:
What|Removed |Added
Component|c |target
Keywords|
from their respective masters as of
19 February 2025 in one-tree style, a build targeting tic6x-elf fails if C++ is
enabled. When built for just C, gcc reports this as the version:
tic6x-elf-gcc (GCC) 15.0.1 20250219 (experimental)
After enabling C++, failure output is as follows:
libtool: compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
Sam James changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #13 from Sam James
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
Bug ID: 118940
Summary: [x86] inline assembly fails with 'asm' operand has
impossible constraints or there are not enough
registers
Product: gcc
Version: 15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118521
Jeffrey A. Law changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #4 from Andrew Pinski ---
--enable-cxx-flags=-fPIC
I am not sure why you are using that but this while building the -mcpu=68000
multi-lib.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
Bug ID: 118939
Summary: ada: executable segfaults on arm-linux-gnueabi when
assigning an access to controlled type
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #3 from Mikael Pettersson ---
Is that before or after you built the target glibc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #2 from Waldemar Brodkorb ---
with following command:
/home/wbx/openadk/toolchain_build_qemu-m68k-q800_glibc_68040/w-gcc-14.2.0-1/gcc-14.2.0/configure
--prefix=/home/wbx/openadk/toolchain_qemu-m68k-q800_glibc_68040/usr
--with-bugurl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118915
--- Comment #7 from Sam James ---
In some older testcases, you may see (__builtin_)exit(1) as well, but it's not
common. Thanks for looking!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118915
--- Comment #6 from Krister Walfridsson ---
(In reply to Andrew Pinski from comment #3)
> I am kinda of shock that smtgcc didn't find this earlier.
My guess is that the relevant testcases are written similarly to
```
int main() {
if (b(a + 21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118521
--- Comment #7 from Jeffrey A. Law ---
In the simplified testcase we have:
[local count: 131235111]:
MEM [(char * {ref-all})_53] = MEM [(char
* {ref-all})&C.0];
__result_46 = _53 + 2;
_150 = operator new (4);
goto ; [100.00%]
So _150 poin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118915
Sam James changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[12/13/14/15 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #14 from Sam James ---
(In reply to Jan Hubicka from comment #13)
> Thanks for running this through debugger
> Breakpoint 2.2, profile_count::operator+= (this=0x76e7e888, other=...)
> at
> /usr/src/debug/sys-devel/gcc-15.0./g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #1 from Mikael Pettersson ---
How did you configure this gcc?
1 - 100 of 141 matches
Mail list logo
