https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114389
Bug ID: 114389
Summary: internal compiler error when compiling nested
structure in gdb
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
Sam James changed:
What|Removed |Added
CC||amacleod at redhat dot com
Summa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383
Sam James changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114375
--- Comment #3 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:94c3508c5a14d1948fe3bffa9e16c6f3d9c2836a
commit r14-9533-g94c3508c5a14d1948fe3bffa9e16c6f3d9c2836a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114390
Bug ID: 114390
Summary: Missed SLP of permuted mask load
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114375
Richard Biener changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114364
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8959ab63f1881a8a4b1921b946d4ea3986bf1063
commit r14-9534-g8959ab63f1881a8a4b1921b946d4ea3986bf1063
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #33 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8f85b46337f90c3126b9cefd72ffd29eb9a4ebf3
commit r14-9535-g8f85b46337f90c3126b9cefd72ffd29eb9a4ebf3
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #34 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a185d8aeeed7a25a01505565aa61ccf8a876c6ff
commit r14-9536-ga185d8aeeed7a25a01505565aa61ccf8a876c6ff
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114391
Bug ID: 114391
Summary: catch() and immediate throw; could be optimized to
noop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
--- Comment #6 from GCC Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:167ec6df7fd8deb67759acd5dbe72c1982a55873
commit r14-9537-g167ec6df7fd8deb67759acd5dbe72c1982a55873
Author: Christophe Lyon
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114364
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
--- Comment #3 from Jiang An ---
(In reply to Richard Biener from comment #2)
> So you say GCC 9+ are wrong with -std=c++98 but OK with -std=c++11 or newer
> (the default)?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #35 from GCC Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:c1fd4589c2bf9fd8409d51b94df219cb75107762
commit r14-9538-gc1fd4589c2bf9fd8409d51b94df219cb75107762
Author: Xi Ruoyao
Date: Mon Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #36 from Xi Ruoyao ---
Do we need a backport to releases/gcc-13?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114392
Bug ID: 114392
Summary: Address of overloaded function with requires
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #37 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1f257714674cd8fd69db7367aecdd09b672d1db7
commit r14-9539-g1f257714674cd8fd69db7367aecdd09b672d1db7
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #38 from Jakub Jelinek ---
(In reply to Xi Ruoyao from comment #36)
> Do we need a backport to releases/gcc-13?
Yes, but I'd wait a little bit with that.
BTW, as expected, ia64 seems to be unaffected, and I don't have trees built f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Andrew Pinski ---
> Let me look into that for GCC 15. Note libobjc is not used by many folks even
> the GNUStep folks don't use it any more ...
Thanks. I only in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Iain Buclaw ---
> Fix to format hexstrings as big endian has been committed from upstream merge.
>
> r14-9505
>
> This should be resolved now.
It is. Thanks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from Jakub Jelinek ---
> Assuming fixed even on sparc*.
It is. I've missed this one when collecting instances of missing
vect_hw_misalign like PR tree-optimization/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96147
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
It seems the xfail can go completely now: the test PASSes on both
sparc-sun-solaris2.11 and i386-pc-solaris2.11 (32 and 64-bit) with
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-32.c
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114365
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109996
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626
--- Comment #11 from Matthias Klose ---
> Note libobjc is not used by many folks even
> the GNUStep folks don't use it any more ...
that's wrong, looking at least at GNUstep base 1.29.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
--- Comment #4 from Jonathan Wakely ---
This changed with r9-595-g955da5e5443724:
CWG 616, 1213 - value category of subobject references.
* tree.c (lvalue_kind): A reference to a subobject of a prvalue is
an xvalue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
Bug ID: 114393
Summary: over eager "invalid use of void expression" ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
--- Comment #5 from Jonathan Wakely ---
Prior to DR 616 the expression (true ? WrapB().b : WrapD().d) was a prvalue of
type B, created by copying the B (or slicing the D when the condition is
false). As an rvalue, it wasn't evaluated. That's tru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
--- Comment #22 from Richard Biener ---
Handling LHS sra_handled_bf_read_p the same as RHS also fixes the issue,
we then detect the partial overlap of the accesses without looking at
grp_partial_lhs.
I wonder if we run into the same issue for R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
--- Comment #1 from Jonathan Wakely ---
Created attachment 57736
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57736&action=edit
Gzipped preprocessed source
Bisecting ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> In C++98 the const B& is an lvalue, and in C++11 the B&& is an xvalue which
> is a glvalue. Either way, it's correct to treat it as a glvalue of
> polymorphi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
--- Comment #7 from Jiang An ---
(In reply to Jonathan Wakely from comment #5)
> Prior to DR 616 the expression (true ? WrapB().b : WrapD().d) was a prvalue
> of type B, created by copying the B (or slicing the D when the condition is
> false).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374
--- Comment #7 from Jakub Jelinek ---
Bisection shows that first in
r12-5014-g6b8b959675a3e14cfdd2145bd62e4260eb193765
we started to warn on both f and g in #c5 at -O0 -Wall, and then
since r12-7870-g28c5df79300ab354cbc381aab200f7c2bd0331ad it o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114368
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114392
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
--- Comment #8 from Jonathan Wakely ---
The change makes the value category clk_rvalueref but I don't know what that
means in C++98 mode:
op1_lvalue_kind = lvalue_kind (TREE_OPERAND (ref, 0));
+ if (op1_lvalue_kind == clk_class)
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
--- Comment #9 from Jonathan Wakely ---
If there's a bug here, it's the value category of the ternary expression, not a
problem with typeid. Whether there's a problem with the value category depends
on how the DR is interpreted to apply to C++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113505
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] ICE:|[14 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114391
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-03-19
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
--- Comment #8 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:e0e9499aeffdaca88f0f29334384aa5f710a81a4
commit r14-9540-ge0e9499aeffdaca88f0f29334384aa5f710a81a4
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322
--- Comment #2 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:e0e9499aeffdaca88f0f29334384aa5f710a81a4
commit r14-9540-ge0e9499aeffdaca88f0f29334384aa5f710a81a4
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #24 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:e0e9499aeffdaca88f0f29334384aa5f710a81a4
commit r14-9540-ge0e9499aeffdaca88f0f29334384aa5f710a81a4
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113505
--- Comment #3 from Jakub Jelinek ---
Seems this is because the analyzer creates invalid IL.
MEM_REF second argument should be always INTEGER_CST, with value which is the
offset from the base and pointer type used for TBAA purposes:
/* Memory ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
--- Comment #12 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:e0e9499aeffdaca88f0f29334384aa5f710a81a4
commit r14-9540-ge0e9499aeffdaca88f0f29334384aa5f710a81a4
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
Richard Biener changed:
What|Removed |Added
Summary|[11/12/13 Regression] wrong |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 114269, which changed state.
Bug 114269 Summary: [14 Regression] Multiple 3-6% exec time regressions of
434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
Bug 114074 depends on bug 114322, which changed state.
Bug 114322 Summary: [14 Regression] SCEV analysis failed for bases like
A[(i+x)*stride] since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
Bug 114074 depends on bug 114151, which changed state.
Bug 114151 Summary: [14 Regression] weird and inefficient codegen and
addressing modes since r14-9193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
Bug 114074 depends on bug 114269, which changed state.
Bug 114269 Summary: [14 Regression] Multiple 3-6% exec time regressions of
434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
What|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113505
--- Comment #4 from Jakub Jelinek ---
Created attachment 57737
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57737&action=edit
gcc14-pr113505.patch
Untested patch to do that. Fixes the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113390
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #9 from GCC Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:4adb1a5839e7a3310a127c1776f1f95d7edaa6ff
commit r14-9543-g4adb1a5839e7a3310a127c1776f1f95d7edaa6ff
Author: Iain Sandoe
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470
--- Comment #14 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #13)
> So, is there anything we should do about this PR, or just close it as
> necessary outcome of trying to be more secure when user asked for it?
At least it shouldn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113390
--- Comment #4 from Jeffrey A. Law ---
Made it a P1 simply because it was likely not RISC-V specific ICE. I don't
think we're at a point where it makes sense for RISC-V to be a primary
platform, though hopefully that'll change in the relatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114391
--- Comment #2 from Antony Polukhin ---
> Is there something to optimize when foo() cannot be tail-called?
Yes. Just `catch (...) { throw; }`, no more restrictions. I do not even think,
that it should be the outer most EH region:
void foo();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114286
--- Comment #6 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:c7a774edbf802d79b95871ede5b80f6e9adf8e88
commit r14-9544-gc7a774edbf802d79b95871ede5b80f6e9adf8e88
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114286
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #9 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
--- Comment #23 from Richard Biener ---
Note with the 2nd patch it's still broken when the BIT_FIELD_REFs in the IL are
not byte aligned.
Both patches passed bootstrap & regtest, there is unknown effect on
optimization of __imag / __real.
Look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114394
Bug ID: 114394
Summary: std::bind uses std::result_of which is deprecated
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114394
--- Comment #1 from Jonathan Wakely ---
Patches need to be sent to the mailing list not attached in bugzilla.
The patch is wrong though, it needs to use _Fn& as an lvalue, not an rvalue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114394
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #31 from Richard Biener ---
diff --git a/gcc/tree-dfa.cc b/gcc/tree-dfa.cc
index cbd3774b21f..1dbd9bd7a00 100644
--- a/gcc/tree-dfa.cc
+++ b/gcc/tree-dfa.cc
@@ -549,7 +549,8 @@ get_ref_base_and_extent (tree exp, poly_int64 *poffset,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395
Bug ID: 114395
Summary: std::is_constructible_v result of const reference
incorrect
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114367
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:16afbd9c9c4282d56062cef95e6eccfdcf3efe03
commit r14-9545-g16afbd9c9c4282d56062cef95e6eccfdcf3efe03
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #3 from Jakub Jelinek ---
Loooking at pr90716.c, that case seems like a clear wrong-debug.
Before r14-162 j was everywhere, "j\0" DW_TAG_variable didn't
have any DW_AT_location/DW_AT_const_value, optimized dump doesn't show any
DEBU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
Thomas Schwinge changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #4 from Jan Hubicka ---
The change makes loop iteration estimates more realistics, but does not
introduce any new code that actually changes the IL, so it seems this makes
existing problem more visible. I will try to debug what happ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113505
--- Comment #5 from David Malcolm ---
Thanks, am testing your patch now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
Bug ID: 114396
Summary: [14] RISC-V rv64gcv vector: Runtime mismatch at -O3
with -fwrapv
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #1 from Patrick O'Neill ---
Here's the result when running with -fwrapv on rv64gcv at O2:
> /scratch/tc-testing/tc-mar-18/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv -O2 red.c -o red.out -fwrapv
> /scratch/tc-t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #5 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #4)
> The change makes loop iteration estimates more realistics, but does not
> introduce any new code that actually changes the IL, so it seems this makes
> existing pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #6 from Jan Hubicka ---
On this testcase trunk does get same dump as gcc13 for pass just before ch2
with ch2 we get:
@@ -192,9 +236,8 @@
# DEBUG BEGIN_STMT
goto ; [100.00%]
- [local count: 954449105]:
+ [local count: 9544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #20 from GCC Commits ---
The releases/gcc-13 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:1a6d04fce7d78b9e5201333be0c0877390f81bc3
commit r13-8466-g1a6d04fce7d78b9e5201333be0c0877390f81bc3
Author: Uros Bizjak
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #21 from GCC Commits ---
The releases/gcc-12 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:f6ed0466d40de496b14225fae44acf618dac1fd2
commit r12-10284-gf6ed0466d40de496b14225fae44acf618dac1fd2
Author: Uros Bizjak
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228
--- Comment #17 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:c608b57f77a47179899666940c3b8b6a2e5435b2
commit r14-9550-gc608b57f77a47179899666940c3b8b6a2e5435b2
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:07e03761a7fc1626a6a74ed957e117f56981558c
commit r14-9551-g07e03761a7fc1626a6a74ed957e117f56981558c
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #22 from Uroš Bizjak ---
Fixed also for TImode STV.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |12.4
--- Comment #5 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Iain Sandoe changed:
What|Removed |Added
Target Milestone|14.0|11.5
--- Comment #10 from Iain Sandoe --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106295
--- Comment #6 from ghlixo at gmail dot com ---
One last comment about this issue.
I maintain and distribute a Fortran subroutine package to users. In my
experience, most of them are unaware that Fortran compilers evolve over time,
and that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395
Andrew Pinski changed:
What|Removed |Added
Summary|std::is_constructible_v |[c++20+]
|result of c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832
--- Comment #3 from Filip Kastl ---
It seems that the benchmark runtime returned to normal for a while but then
went back to 6% slowdown.
Somewhere between these two commits the benchmark sped up
g:eb7a8f213d59e0cf
g:15d1dae0d4d1be88
And betwe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #5 from Martin Jambor ---
I'd like to ping this, are there plans to implement this in the near-ish term?
1 - 100 of 179 matches
Mail list logo
