https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619
--- Comment #8 from Sergei Trofimovich ---
Looks like it's mainly -O0.
Why not try to use at least -O1 for bootstrap? Perhaps it was a safe default to
workaround host compiler bugs in C days.
But nowadays gcc uses -std=c++11 with quite a bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619
--- Comment #7 from Andrew Pinski ---
I am not sure there is not much to be done here really since the issue is
profilingbootstrap will use -O0 for stage1 to make sure we don't run into bugs
in host compiler (though we still run into issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619
--- Comment #6 from Sergei Trofimovich ---
And here is fomr completeness default checking with CC='gcc -g -O2' CXX='g++ -g
-O2':
$ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ 'CC=gcc
-g -O2' 'CXX=g++ -g -O2'
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619
--- Comment #5 from Sergei Trofimovich ---
(In reply to Andrew Pinski from comment #3)
> Note prev-gcc/cc1plus is compiled at -O0 also which definitely makes things
> worse here.
Also tried with: '--enable-checking=release -O2 -g' as:
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619
--- Comment #4 from Sergei Trofimovich ---
(In reply to Andrew Pinski from comment #2)
> Can you also try with --enable-checking=release to double check that it is
> not the extra compile time checks which is causing issues ...
Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111533
--- Comment #4 from CVS Commits ---
The master branch has been updated by Li Xu :
https://gcc.gnu.org/g:110ffb2d8d3a64b32dd56ac995c2e30e8f64d4dc
commit r14-4301-g110ffb2d8d3a64b32dd56ac995c2e30e8f64d4dc
Author: xuli
Date: Thu Sep 28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111466
--- Comment #1 from Vineet Gupta ---
So there are various aspects to tackling this issue.
#1. REE reports failure as "missing definition(s)".
This is because function args don't have an explicit def, they are just there.
Cannot eliminate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619
--- Comment #3 from Andrew Pinski ---
Note prev-gcc/cc1plus is compiled at -O0 also which definitely makes things
worse here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619
--- Comment #2 from Andrew Pinski ---
Can you also try with --enable-checking=release to double check that it is not
the extra compile time checks which is causing issues ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619
--- Comment #1 from Sergei Trofimovich ---
-ftime-report breakdown:
time /tmp/gb/./prev-gcc/cc1plus -quiet -nostdinc++ -I
/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111618
--- Comment #1 from Antoine Lemoine ---
Error message using gfortran 13.2 on Compiler Explorer:
f951: internal compiler error: Segmentation fault
0x1bec57e internal_error(char const*, ...)
???:0
0x7d4c85 gfc_expression_rank(gfc_expr*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619
Bug ID: 111619
Summary: [14 regression] 'make profiledbootstrap' makes 10+
minutes on insn-recog.cc (x86_64-linux)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111618
Bug ID: 111618
Summary: ICE in associate construction
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740
--- Comment #7 from anlauf at gcc dot gnu.org ---
The following snippet in gfc_trans_pointer_assignment looks suspicious:
if (expr1->ts.type == BT_CHARACTER
&& expr1->symtree->n.sym->ts.deferred
&&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109685
Markus Böck changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111617
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606
--- Comment #6 from Markus F.X.J. Oberhumer ---
@Andrew Pinksi Many thanks for cleaning up the bug case!
cvise (https://github.com/marxin/cvise) did correctly reduce the original from
~5 lines to 18 lines, but the result looked extremely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111617
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111617
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111617
Bug ID: 111617
Summary: Unnecessary instructions generated when comparing
mixed-sign small integers
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111614
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111614
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-checking,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606
--- Comment #5 from Andrew Pinski ---
Actually here is the full backtrace:
#2 0x03524383 in error_recursion (context=0x4d471a0
) at
/home/apinski/src/upstream-gcc/gcc/gcc/diagnostic.cc:2265
#3 0x035217be in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606
--- Comment #4 from Andrew Pinski ---
(In reply to Markus F.X.J. Oberhumer from comment #0)
> Test case has been reduced by cvise.
>
> Might be related to / duplicate of
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90747
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #8 from Andreas Schwab ---
Native on HiFive Unleashed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606
--- Comment #2 from Andrew Pinski ---
Created attachment 56005
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56005=edit
Reduced further
Attached is the testcase reduced further, and adding back to make it more valid
code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
palmer at gcc dot gnu.org changed:
What|Removed |Added
CC||palmer at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111609
Andrew Pinski changed:
What|Removed |Added
Known to fail||12.1.0, 4.5.4
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111511
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111511
--- Comment #9 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:97a33ab114187e7c6cd6c6c0f06cd8225e8aeef5
commit r11-11021-g97a33ab114187e7c6cd6c6c0f06cd8225e8aeef5
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111512
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:97a33ab114187e7c6cd6c6c0f06cd8225e8aeef5
commit r11-11021-g97a33ab114187e7c6cd6c6c0f06cd8225e8aeef5
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=02
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108046
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=02
--- Comment #4 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:9853ad876bd3d9d4685126466f74402e567664b3
commit r13-7918-g9853ad876bd3d9d4685126466f74402e567664b3
Author: Paul Dreik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59526
--- Comment #5 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:0547f663ee09aa5887dcd1bb0ea48eba24a30485
commit r13-7917-g0547f663ee09aa5887dcd1bb0ea48eba24a30485
Author: François
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=02
--- Comment #3 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:183eea6029be2f6c9f416d6ffe751c469237ff2d
commit r13-7916-g183eea6029be2f6c9f416d6ffe751c469237ff2d
Author: Paul Dreik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108046
--- Comment #5 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:da1ba03245c212ef1ba100e7806588802f3ad46f
commit r13-7914-gda1ba03245c212ef1ba100e7806588802f3ad46f
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111615
--- Comment #6 from Ben Gardner ---
(In reply to Andrew Pinski from comment #5)
> extern void *memmem (const void *__haystack, size_t __haystacklen,
>const void *__needle, size_t __needlelen)
> __attribute__ ((__nothrow__ ,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111615
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111615
--- Comment #4 from Jonathan Wakely ---
Anything passed to memmem (or memcmpy, or memcpy, etc.) is considered to be a
non-null pointer, because that's a requirement of those functions. And so if
it's a non-null pointer, any null checks for it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111615
--- Comment #3 from Ben Gardner ---
The issue isn't with memmem(). It is with the value passed into pr_str() from
the structure. I suspect memmem() is a distraction.
I'll try to further reduce the test case to eliminate memmem(), if possible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111615
--- Comment #2 from Andrew Pinski ---
I don't think this is a bug. memmem is defined such that a null pointer
argument is undefined even if the len is 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111616
Bug ID: 111616
Summary: On Zen2 7% 519.lbm_r regression between
g:1d17d58c284fa8c3 (2023-09-14 02:39) and
g:c8e9a75085f9725c (2023-09-18 13:09)
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111615
--- Comment #1 from Ben Gardner ---
Created attachment 56004
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56004=edit
Build script.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111615
Bug ID: 111615
Summary: NULL check incorrectly skipped at O2 and O3
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283
--- Comment #9 from Sergei Trofimovich ---
Proposed conservative fix as
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631526.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559
--- Comment #7 from Sergei Trofimovich ---
Proposed conservative fix as
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631526.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088
--- Comment #13 from JuzheZhong ---
Hi, Richi. This is my draft approach to enhance the finding more potential
condtional reduction.
diff --git a/gcc/tree-if-conv.cc b/gcc/tree-if-conv.cc
index a8c915913ae..c25d2038f16 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111613
--- Comment #2 from Richard Biener ---
It's the late IPA modref that mis-analyzes the store-merged sequence I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111589
--- Comment #2 from Jonathan Wakely ---
The interesting question is whether all of these can be relaxed or if we need
to stop using __atomic_add_dispatch for shared_ptr copies:
include/bits/cow_string.h:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111613
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85861
Albert Netymk changed:
What|Removed |Added
CC||albertnetymk at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610
--- Comment #4 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:2ecab2f32b9e9a75bf563f80752d5b44dcd26b98
commit r14-4298-g2ecab2f32b9e9a75bf563f80752d5b44dcd26b98
Author: Iain Sandoe
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111614
Bug ID: 111614
Summary: [14 Regression] ICE at -O2: verify_gimple failed since
r14-2282-gf703d2fd3f0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #6 from Andreas Schwab ---
$ wc -l gcc-*/Build/gcc/insn-opinit.cc
6996 gcc-20230714/Build/gcc/insn-opinit.cc
6591 gcc-20230722/Build/gcc/insn-opinit.cc
6809 gcc-20230728/Build/gcc/insn-opinit.cc
6967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610
--- Comment #3 from Iain Sandoe ---
(In reply to Martin Jambor from comment #2)
> (In reply to Iain Sandoe from comment #1)
> > As a matter of record, we do not really support cross-compilers targeting an
> > unknown Darwin version (the idea of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111611
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559
--- Comment #6 from Sergei Trofimovich ---
Uninitialized value comes from `ipa_merge_profiles()` for our `rule1_same()`
alias and `rule1()` functions:
// in gcc/ipa-icf.cc:
else if (create_alias)
{
alias->icf_merged = true;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111613
Bug ID: 111613
Summary: Bit field stores can be incorrectly optimized away
when -fstore-merging is in effect
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111612
Bug ID: 111612
Summary: GCC twice as slow as Clang for minisweep (SPEC HPC
2021)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111611
Bug ID: 111611
Summary: Auto-Vectorize Compiler Optimization Causing Exception
/ Crash
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111588
--- Comment #3 from Jonathan Wakely ---
If we do want to do it, I think we'd just need something like this (and docs):
--- a/libstdc++-v3/include/ext/atomicity.h
+++ b/libstdc++-v3/include/ext/atomicity.h
@@ -48,6 +48,8 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165
--- Comment #10 from Fedor Chelnokov ---
This issue happens in GCC 13.2 as well:
https://godbolt.org/z/TfGx3YccG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111589
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111608
--- Comment #3 from Jonathan Wakely ---
(In reply to Julien Bernard from comment #0)
> which seems incorrect since their have different levels of specialization.
But they're not the same thing. The first one is a specialization of the member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111608
--- Comment #2 from Jonathan Wakely ---
EDG rejects this too:
"spec.cc", line 13: error: this partial specialization would have been used to
instantiate class "X"
struct X {
^
1 error detected in the compilation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610
--- Comment #2 from Martin Jambor ---
(In reply to Iain Sandoe from comment #1)
> As a matter of record, we do not really support cross-compilers targeting an
> unknown Darwin version (the idea of xxx-apple-darwin [without a specific
> version]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111478
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2023-09-27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088
--- Comment #12 from JuzheZhong ---
(In reply to Richard Biener from comment #11)
> I don't think strip_nop_cond_scalar_reduction is the place to adjust here,
> maybe it's the caller. I don't have time to dig into the specific issue
> right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #14 from Richard Biener ---
(In reply to Kewen Lin from comment #13)
> Thanks again for the reduced test case and the information!
>
> I tried to bisect it but encountered some build failures on _Float32 error
> etc., through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610
Bug ID: 111610
Summary: Cannot build cross compiler to darwin targets after
r14-4108-g47346acb72b50d
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Kewen Lin changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605
--- Comment #12 from Rui Ueyama ---
> Hmm, if you configure the cross target with --with-ld=ld.mold does that then
> work (when not specifying -fuse-ld=mold)?
Sorry, I don't know, but in either case, that wouldn't solve the user-facing
problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088
--- Comment #11 from Richard Biener ---
I don't think strip_nop_cond_scalar_reduction is the place to adjust here,
maybe it's the caller. I don't have time to dig into the specific issue right
now but if we require scalar code adjustments then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111608
Richard Biener changed:
What|Removed |Added
Known to fail||13.2.0, 14.0, 7.5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605
Richard Biener changed:
What|Removed |Added
Version|unknown |14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105606
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3ba882c7b51ab1f14c62c748e989415834ccd9ce
commit r14-4293-g3ba882c7b51ab1f14c62c748e989415834ccd9ce
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111590
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111590
--- Comment #1 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:073849da3dfd5cabbfd4492a40a17b207b4a7630
commit r14-4291-g073849da3dfd5cabbfd4492a40a17b207b4a7630
Author: Juzhe-Zhong
Date: Wed Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111609
Bug ID: 111609
Summary: Zero shift in ARM NEON vshll_n_s8 intrinsic produces
an error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111608
Bug ID: 111608
Summary: Cannot declare partial specialization after full
specialization
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559
--- Comment #5 from Sergei Trofimovich ---
Slightly shorter example that does not rely on inline:
// $ cat bug.c
__attribute__((noipa)) static void edge(void) {}
int p = 0;
__attribute__((noinline))
static void rule1(void) { if (p) edge(); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559
--- Comment #4 from Sergei Trofimovich ---
Looks like identical code folding creates uninitialized profile counters if
there are any edges in folded functions.
I think cvise did a decent job extracting the reproducer below. Here is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #5 from Richard Biener ---
On x86_64-linux the compile-time of the same dwarf2out.ii the
slowdown between r14-2510-g3d0ca8b55b9a88 and r14-4258-gc9837443075277
is less than 2.5% (three runs, fastest vs slowest).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #4 from Andreas Schwab ---
Created attachment 56000
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56000=edit
dwarf2out.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #3 from Andreas Schwab ---
Here are the build times of the stage1 compiler:
2023071421573
2023072219932 -7.6%
2023072821608 +8.4%
2023080421841 +1.0%
2023081125016 +14.5%
20230818
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605
--- Comment #10 from Rui Ueyama ---
> This is only a problem when using a cross gcc, so why should mold proactively
> create symlinks for dozens of targets when mold is installed?
It's because there are too many and we don't have an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
Richard Biener changed:
What|Removed |Added
Summary|[14.0 regression] RISC-V|[14 Regression] RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088
--- Comment #10 from JuzheZhong ---
(In reply to Richard Biener from comment #9)
> (In reply to JuzheZhong from comment #8)
> > It's because the order of the operations we are doing:
> >
> > For code as follows:
> >
> > result += mask ? a[i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111607
Bug ID: 111607
Summary: False positive -Wdangling-reference
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605
--- Comment #9 from Jonathan Wakely ---
This is only a problem when using a cross gcc, so why should mold proactively
create symlinks for dozens of targets when mold is installed?
It seems to me that a single symlink only needs to be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088
Richard Biener changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606
--- Comment #1 from Markus F.X.J. Oberhumer ---
Created attachment 55999
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55999=edit
bug.cpp
Added attachment bug.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606
Bug ID: 111606
Summary: [ICE] internal compiler error: error reporting
routines re-entered.
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
99 matches
Mail list logo
